About rlevas

rlevas · ‎01-13-2016

It seems like something may be wrong with the Kerberos Descriptor. Did you edit any of the principal names on the Configure Identities page of the Enable Kerberos Wizard or did you not set the realm name on the Configure Kerberos page of the Enable Kerberos Wizard? Can you post or attach the response to http://AMBARI_SERVER:8080/api/v1/clusters/CLUSTER_NAME/artifacts/kerberos_descriptor Replacing AMBARI_SERVER with the hostname of your Ambari server Replace CLUSTER_NAME with the name of your cluster

rlevas · ‎01-12-2016

That response does not look like an error. You are getting back a success code: HTTP/1.1 200 OK The "deny" header value you see is for web clients to indicate that the response is not to be displayed in a browser frame. In this context, the header does not apply. Due to the way Ambari is structured, it does not particularly know what the expected destination of the response is, so the header is sent no matter what. This goes for the X-XSS-Protection header as well. X-Frame-Options: DENY X-XSS-Protection: 1; mode=block

rlevas · ‎01-11-2016

@Vincent Jiang, What is confusing... the fact that a keytab is being used or that a headless principal is being used?

rlevas · ‎12-21-2015

Try doing a search for the principal you are using to make sure it's record has the same DN as the one you are using as the Kerberos identity. ldapsearch -h 10.0.2.10 -D darpan@TEST.COM -W -b CN=Users,DC=test,DC=com '(userPrincipalName=darpan@TEST.COM)' dn Also, I noticed that your distinguished name attribute is still incorrect: Is: authentication.ldap.dnAttribute=CN=Users,DC=test,DC=com Should Be: authentication.ldap.dnAttribute=distinguishedName

rlevas · ‎12-15-2015

It appears that the UI stores the realm in the user-specified Kerberos descriptor artifact and that at some point the lowercase form of the realm was specified. However when the case of the realm was corrected, the user-specified Kerberos descriptor artifact was not updated and therefore the test Kerberos identity was created incorrectly. I think this would have corrected itself if the test was skipped, but rather than take a chance on that, it is best to back out of the Kerberos Wizard (to the first page of it) and then exit - this makes sure the Kerberos service is cleaned up properly. Then the user-specified Kerberos descriptor artifact needs to be deleted using DELETE /api/v1/clusters/CLUSTER_NAME/artifacts/kerberos_descriptor Note: replace CLUSTER_NAME with the name of the cluster. For example: curl -H "X-Requested-By:ambari" -u admin:admin -i -X DELETE http://AMBARI_SERVER:8080/api/v1/clusters/CLUSTER_NAME/artifacts/kerberos_descriptor Then restart the Enable Kerberos Wizard, making sure to set the realm with the proper case.

rlevas · ‎12-15-2015

On the host where the service check was executed, can you find the command.JSON file that was use to execute the command and post the contents of the "commandParams" block? To find the correct command.json file do: grep KERBEROS_SERVICE_CHECK /var/lib/ambari-agent/data/command-*.json One or more files may be listed... any will be fine. The commandParams from my cluster looks like: "commandParams": { ... "principal_name": "c1-121515@EXAMPLE.COM", ... }

rlevas · ‎12-15-2015

Can you post the results of the following API call? GET /api/v1/clusters/CLUSTER_NAME/configurations?type=kerberos-env&fields=properties/* Note: you will need to change CLUSTER_NAME to the name of your cluster. For example: http://ambari-server-host:8080/api/v1/clusters/MyCluster/configurations?type=kerberos-env&fields=properties/* Basically, I am interested in the realm property. So you can just post that if the other information may be sensitive.

rlevas · ‎12-14-2015

Is Ambari running as non-root? If so, make sure the user that Ambari runs as, has authorization to write to /var/lib/ambari-server/tmp. Also, did you change the value of the encryption types field? I think that it is under Advanced Kerberos-env section when on the Configure Kerberos page of the wizard. If this field is blank, then no encryption types will be specified and thus no keytab entries for the keytab files will be generated. If you edited the field, try setting it back to aes des3-cbc-sha1 rc4 des-cbc-md5 when you enable Kerberos again.

rlevas · ‎12-11-2015

It seems like you found a limitation for which I am not sure there is an easy solution. I believe this is fixable, but the places where the krb5.conf file is used spans more than just the calls to kinit and klist. We need to make sure that the services that have built-in support for Kerberos can check alternate paths for the krb5.conf file.

rlevas · ‎12-11-2015

Was Kerberos enabled using Ambari's automation, or was this done manually?

Online	Offline
Last Visited	‎08-09-2019 12:22 AM

Member Since	‎09-29-2015 12:39 AM
Last Visited	‎08-09-2019 12:22 AM
Posts	362
Kudos received	242

Cloudera Community

Re: Ambari createKeytabFileCommand with IPA does n...

Re: invalid KDC administrator credentials after up...

Re: Unexpected error condition executing the kadmi...

Re: .KerberosOperationException: Unexpected error ...

Re: Kerberos and LDAP integration

Re: Error: Attempted to add a rule for a principal...

Re: Ambari REST API request not appearing in "Back...

Re: Why does Ambari use headless keytab for Spark ...

Re: Not able to sync users of Active Directory in ...

Re: When Kerberizing via Ambari against an AD the ...

Re: When Kerberizing via Ambari against an AD the ...

Re: When Kerberizing via Ambari against an AD the ...

Re: Ambari enable Kerberos does not create princip...

Re: How to use Kerberos Wizard changed “krb5-conf ...

Re: Services failing to restart after kerberizing ...