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

@Sudheer Velagapudi What version of Ambari are you using and did you turn on the Kerberos authentication feature of Ambari? Have you looked at the Ambari server log (/var/log/ambari-server/ambari-server.log) to see if there is anything interesting (and related) in there? Did you successfully kinit using a principal from a trusted KDC before issuing the curl command? ... View more

There is a workaround for this issue. However the results may not be desired since the CN will be a set of seemingly random characters. The CN is set using the value calculated using the Velocity template specified in the kerberos-env/ad_create_attributes_template configuration. The default value of the template is { "objectClass": ["top", "person", "organizationalPerson", "user"], "cn": "$principal_name", #if( $is_service ) "servicePrincipalName": "$principal_name", #end "userPrincipalName": "$normalized_principal", "unicodePwd": "$password", "accountExpires": "0", "userAccountControl": "66048" } As you can see, the CN value is set to the identity's principal name. This can be changed, but we need to make sure the value will be unique. There are several variables available to use in this template. See https://docs.hortonworks.com/HDPDocuments/Ambari-2.6.1.5/bk_ambari-security/content/customizing_the_attribute_template.html. You can use one of the hashes to limit the size of the value and provide a reasonable probability of uniqueness: principal_digest (SHA1) - 40 characters principal_digest_256 (SHA256) - 64 characters principal_digest_512 (SHA512) - 128 characters Since the maximum length for the CN attribute in an Active Directory is 64 characters, I would suggest using principal_digest_256. For example, { "objectClass": ["top", "person", "organizationalPerson", "user"], "cn": "$principal_digest_256", #if( $is_service ) "servicePrincipalName": "$principal_name", #end "userPrincipalName": "$normalized_principal", "unicodePwd": "$password", "accountExpires": "0", "userAccountControl": "66048" } Notice the "cn" line was changed from "cn": "$principal_name" to "cn": "$principal_digest_256". You can change this templet from the Enable Kerberos Wizard if you open the Advanced kerberos-env tab on the Configure Kerberos page and look for the Account Attribute Template property. ... View more