Member since
09-29-2015
362
Posts
242
Kudos Received
63
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1252 | 03-14-2019 01:00 PM | |
1499 | 01-23-2019 04:19 PM | |
6955 | 01-15-2019 01:59 PM | |
4245 | 01-15-2019 01:57 PM | |
9912 | 12-06-2018 02:01 PM |
09-19-2018
08:15 AM
Thanks for the detailed answer, it is very helpful! BR//Gagan
... View more
09-14-2018
03:32 PM
@Lija Mohan Key type 3 is DES_CBC_MD5, which is pretty much deprecated (see https://www.opencore.com/blog/2017/3/kerberos-encryption-types/), but by default Ambari requests/creates keytab entries using this type for backwards compatibility. Your KDC is probably rejecting keys encrypted with this type. To fix this, you should go into the Kerberos service settings and edit the "Encryption Type" value under the "Advanced kerberos-env" section. The default value is "aes des3-cbc-sha1 rc4 des-cbc-md5". Change it to "aes des3-cbc-sha1 rc4". You will also want to update the "krb5-conf template" value under "Advanced krb5-conf" to add the following under the "[libdefaults]" section: allow_weak_crypto = false After saving the changes and restarting the Kerberos service (which ensure the krb5.conf file is synced up), you should restart all of the services. If you still see issues, maybe regenerate all keytab files (Admin->Kerberos) and then restart all services. However depending on the KDC implementation you may or may not see a change in the generated keytab files. By default they will look like [root@c7401 ~]# klist -kte /etc/security/keytabs/spnego.service.keytab
Keytab name: FILE:/etc/security/keytabs/spnego.service.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
2 09/14/2018 15:06:22 HTTP/c7401.ambari.apache.org@EXAMPLE.COM (des3-cbc-sha1)
2 09/14/2018 15:06:22 HTTP/c7401.ambari.apache.org@EXAMPLE.COM (des-cbc-md5)
2 09/14/2018 15:06:22 HTTP/c7401.ambari.apache.org@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
2 09/14/2018 15:06:22 HTTP/c7401.ambari.apache.org@EXAMPLE.COM (arcfour-hmac)
2 09/14/2018 15:06:22 HTTP/c7401.ambari.apache.org@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
... View more
10-03-2018
08:42 AM
@Robert Levas : Thanks a lot for the solution, 'unsupported type' issue has been resolved after kerberose config changes. I have raised another issue for storm spenago load balancer related here.
... View more
05-16-2019
06:46 AM
@Geoffrey Shelton Okot Please find the link for new thread https://community.hortonworks.com/questions/246319/failed-to-connect-to-kdc-failed-to-communicate-wit.html Please guide me on this its really critical for me.
... View more
04-27-2018
12:24 PM
You appear to be using an Active Directory. In this case, you still want to use port 389 for LDAP and 636 for LDAPS unless there is a firewall in the way or the ports were changed on the Active Directory for some reason. That said, it is possible that SSL was not set up for your Active Directory and therefore it is not listening for LDAPS requests on port 636. Make sure that LDAPS is enabled on your Active Directory.
... View more
02-13-2018
09:11 PM
Usually by default the ticket expires 24 hours and cache expires 7 days. Depends on your directory services policies. Within 7 days you can do kinit -R for users. klist will show ticket and cache expiry time. Or you can use keytabs to automate ticket renewal. You don't have to kinit for hadoop services (ever), ticket renewal is managed automatically.
... View more
02-01-2018
04:17 PM
Can you check you hadoop.kms.authentication.kerberos.name.rules settings from kms-site.xml? Try "DEFAULT" if you have a customized setting that is invalid. You mentioned that the kms principle is changed. Can you also post your hadoop.kms.authentication.kerberos.principal and hadoop.security.auth_to_local settings from core-site.xml?
... View more
10-27-2017
04:55 PM
@Robert Levas Thank you for your detailed explanation. With these details, i've resolved my issue. It was a problem in my kadm5.acl.
... View more