@Ankita Ghate Can you post any relevant information from your ambari-server.log? One thing to check is to make sure that you are using the FQDN of the KDC when specifying the host in the KDC administrator host field. You should use the FQDN in the KDC hosts field as well, but that is not as important due to the way Ambari authenticates with the target KDC. ... View more

@Rohan Goel Active Directory is a Microsoft product that runs on a Microsoft Windows server. It provides a lot of services for a (Windows) network. In this case, it can also provide LDAP and KDC services for a your Hadoop cluster. If you do not already have an Active Directory set up, or if you do not wish to use your Active Directory as a KDC for Kerberos authentication, then you probably want to install an MIT KDC. However, if using Ambari 2.7.0 or above, you might consider IPA (or FreeIPA), since it is sort of similar to an Active Directory. An IPA server provides several services for a network like DNS, LDAP, and KCD; however, it will take some learning to get it all installed and working. That said, if you are already set on using OpenLDAP, you should use the MIT KDC option. See https://web.mit.edu/kerberos/krb5-1.12/doc/admin/install.html for information on installing this KDC. You can even configure it to use OpenLDAP as it's backend - see https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_ldap.html. I have a script that will install an MIT KDC using the most simple options (I use it for testing) - install-kdc-centossh.txt (I needed to add the .txt extension to the .sh file to upload it here). If you do not edit the script, it will create a KDC with the following properties: realm: EXAMPLE.COM administrator principal: admin/admin@EXAMPLE.COM administrator password: hadoop I hope this helps. ... View more

OpenLDAP? I thought this was Active Directory. If you are not using an Active Directory, you will need to choose a different KDC type when enabling Kerberos. Ambari does not generally create users in an LDAP directory. However when enabling Kerberos, it needs to create accounts in the KDC to store the principal names and password. This is done differently depending on the type of KDC you are using. For Active Directory, the method Ambari uses is to connect to its LDAP interface and create user accounts with the needed attributes. For MIT KDC, it uses the MIT kadmin utility to request the creation of new principals and export keytab files. And for IPA, it uses the ipa client utilities to request the creation of new principals and export keytab files. In each case, you tell Ambari what the administrator credentials are in the Enable Kerberos wizard - like you have in the screen shots above. ... View more

the container, 'dc=testhdp,dc=com', seems to be rather high up in the LDAP tree. Maybe your admin user credential does not have privs to write there. Usually a container is created for the hadoop principals... like 'ou=hadoop,dc=testhdp,dc=com' and a user in the AD is delegated administrative access to manage user accounts in that container (some times referred to as an "O U" - I prefer "container" though). Try to create a container and ensure the AD account that Ambari is using has privileges to create users in that container. ... View more

My suggestion to set kerberos.operation.verify.kdc.trust to true is a bit of a hack, but it may give you an idea of what the cause is. If this works, then there is something up with the Ambari trust store... like the needed CA certs have not been imported, or maybe Ambari is not really using the one you think it is. Once we figure out a solution to the issue, we can flip the flag back to true (or remove that property) and you will have SSL certificate trust validation turned on again. Looking at the log entries, the issue points to a lack of information in the trust store : sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Did you try adding all CA and intermediary CA certs into the trust store? ... View more

@Nico Jordaan Take a look at the Ambari server log (/var/log/ambari-server/ambari-server.log) to see what the complete issue is. It could be related to the SSL cert or maybe the truststore you think it being used by Ambari is not really the truststore that Ambari is using. One thing you can try is to disable certificate validation when connecting to the Active Directory while enabling Kerberos. This can be done by setting the following property in the ambari.properties file: kerberos.operation.verify.kdc.trust = true Then restart Ambari and try to re-enable Kerberos. ... View more

@fifi abd I didn't read through the entire error, but the last line indicates that there is an issue with XML in /home/v962173adm/nifi-1.8.0-bin/nifi-1.8.0/./conf/authorizers.xml. Take a look at row 159 and see if there is anything obvious. Maybe some copy/paste issue where an invalid or unicode character is there? Sometimes a forward or back quote gets in or that long dash character (Em Dash). If you attach that file, I can take a look and see if there is something obvious there. ... View more

@Rohan Goel If you are using Ambari before version 2.7.0, then you can do the following: delete from kerberos_principal_host where principal_name = 'THE PRINCIPAL NAME"; delete from kerberos_principal where principal_name = 'THE PRINCIPAL NAME"; If you are using Ambari, version 2.7.0 and above, then you have to do the following: delete from kerberos_keytab_principal where principal_name = 'THE PRINCIPAL NAME"; delete from kerberos_principal where principal_name = 'THE PRINCIPAL NAME"; Then restart Ambari. ... View more

@Ankita Ghate Can you post/attach the user-supplied Kerberos descriptor retrieved from GET /api/v1/clusters/CLUSTER_NAME/kerberos_descriptors/USER Replacing CLUSTER_NAME with the name or your cluster. I suspect the issue is related to Kerberos descriptor information supplied to Ambari ... View more