@huzaira bashir It seems like there may be an issue exporting keytab files from the KDC. Can you try to do this manually using the admin user you configured in Ambari? /bin/kinit -c /tmp/my_cc -S kadmin/<KDC Admin Server Host> <KDC Admin Principal Name> /bin/kadmin -c /tmp/my_cc -s <KDC Admin Server Host> -r <Realm> -q "xst -k /tmp/ambari_tmp.keytab -e des3-cbc-sha1-kd:normal,rc4-hmac:normal,des-cbc-md5:normal,aes128-cts-hmac-sha1-96:normal,aes256-cts-hmac-sha1-96:normal ambari-qa-<Cluster Name>@<Realm>" /bin/klist -kte /tmp/ambari_tmp.keytab You will need to change the specifics to match your cluster. For my cluster I am using: KDC Admin Server Host: c7402.ambari.apache.org KDC Admin Principal Name: admin/admin!@EXAMPLE.COM Realm: EXAMPLE.COM Cluster Name: c1 Also, I assume that you haven't changed: The default temporary directory: /tmp The kadmin principal name: kadmin/<KDC Admin Server Host> The format of the Ambari smoke user principal name: ambari-qa-<Cluster Name>@<Realm> The default encryption types: aes des3-cbc-sha1 rc4 des-cbc-md5 Using the commands from above, I get the following: [root@c7402 ~]# /bin/kinit -c /tmp/my_cc -S kadmin/c7402.ambari.apache.org admin/admin@EXAMPLE.COM Password for admin/admin@EXAMPLE.COM:<br>[root@c7402 ~]# /bin/kadmin -c /tmp/my_cc -s c7402.ambari.apache.org -r EXAMPLE.COM -q "xst -k "/tmp/ambari_tmp.keytab" -e des3-cbc-sha1-kd:normal,rc4-hmac:normal,des-cbc-md5:normal,aes128-cts-hmac-sha1-96:normal,aes256-cts-hmac-sha1-96:normal ambari-server-c1@EXAMPLE.COM" Authenticating as principal admin/admin@EXAMPLE.COM with existing credentials. Entry for principal ambari-server-c1@EXAMPLE.COM with kvno 4, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/ambari_tmp.keytab. Entry for principal ambari-server-c1@EXAMPLE.COM with kvno 4, encryption type arcfour-hmac added to keytab WRFILE:/tmp/ambari_tmp.keytab. Entry for principal ambari-server-c1@EXAMPLE.COM with kvno 4, encryption type des-cbc-md5 added to keytab WRFILE:/tmp/ambari_tmp.keytab. Entry for principal ambari-server-c1@EXAMPLE.COM with kvno 4, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/ambari_tmp.keytab. Entry for principal ambari-server-c1@EXAMPLE.COM with kvno 4, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/ambari_tmp.keytab. Administration credentials NOT DESTROYED.<br>[root@c7402 ~]# /bin/klist -kte /tmp/ambari_tmp.keytab Keytab name: FILE:/tmp/ambari_tmp.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 4 01/09/2019 15:31:29 ambari-server-c1@EXAMPLE.COM (des3-cbc-sha1) 4 01/09/2019 15:31:29 ambari-server-c1@EXAMPLE.COM (arcfour-hmac) 4 01/09/2019 15:31:29 ambari-server-c1@EXAMPLE.COM (des-cbc-md5) 4 01/09/2019 15:31:29 ambari-server-c1@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 4 01/09/2019 15:31:29 ambari-server-c1@EXAMPLE.COM (aes256-cts-hmac-sha1-96) Can you try this to see if you get any errors? ... View more

@huzaira bashir Is the Ambari server on a host that is registered with the cluster? If not, I was recently alerted to an issue where this case was causing an error. But enabling Kerberos would have failed for you... unless you had enabled Kerberos before upgrading to Ambari 2.7.1. See AMBARI-25088 - Enable Kerberos fails when Ambari server is not on a registered host. ... View more

@huzaira bashir Can you take a look at your Ambari server log (/var/log/ambari-server/ambari-server.log) and see if there are any interesting error messages? ... View more

I am not exactly sure all of the tasks that the Ambari agent reset operation performs. It seems like it will do a lot more than just clean up the existing certs - if it does that at all. However, it will not perform any of the Ambari server-side tasks. So at lest the Ambari server steps from the article need to take place manually. ... View more

@Anant Aneja You probably should have posed this as a question in the form, rather than a comment to this article. It may have gotten answered quicker. The rule you are using will not perform the translation you want. The regular expression syntax to match using case-insensitivity is not supported as you have specified it and the translation will not generate local names with all lower-case characters. The rule you want is more like RULE:[1:$1@$0](.*@FOO.COM)s////L With this rule, the Hadoop UGI class will translate user@FOO.COM to user@foo.com [root@c7401 ~]# hadoop org.apache.hadoop.security.HadoopKerberosName joe_user@FOO.COM 18/08/27 15:57:07 INFO util.KerberosName: Non-simple name joe_user@FOO.COM after auth_to_local rule RULE:[1:$1@$0](.*@FOO.COM)s////L Name: joe_user@FOO.COM to joe_user@foo.com As for the other principal names, they will technically be invalid since the realm name needs to always be in all upper-case characters. user1@FOO.COM - legal user2@foo.com - illegal user3@Foo.com - illegal ... View more

I am glad you found this useful. Thanks for the note. ... View more

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

I just tried this and had no issues. Ambari 2.4.2/HDP 2.4 curl command worked fine Express upgrade to HDP 2.5 (Ambari 2.4.2/HDP 2.5) curl command worked fine Check your ambari.log file to see if there are any interesting errors. ... View more