In addition to this, when enabling Kerberos against an Active Directory, LDAPS must be used rather than LDAP since Active Directory requires a secure connection to set or update account password - and Ambari needs to set or update the passwords for the Kerberos identity accounts it manages. ... View more

@Kuldeep Kulkarni I am not familiar enough with Blueprints to be able to comment on this. Maybe @rnettleton can comment on hiding passwords in Blueprints. ... View more

A special character should not really affect this, however it may depend on how special that character is. If it is just a normal ASCII letter, number, or punctuation, it will be fine. However if the character is not in the western latin character set, it may not have a valid translation. But I do not think that you would see the error message you posted. That said, it is possible that your key did not make it into the Ambari credential store. Yo can check that by listing the keys in the credential store: $JAVA_HOME/bin/keytool -list -keystore /var/lib/ambari-server/keys/credentials.jceks -storetype JCEKS In my case $JAVA_HOME is /usr/jdk64/jdk1.8.0_77, so you might want to call the command using something like /usr/jdk64/jdk1.8.0_77/bin/keytool -list -keystore /var/lib/ambari-server/keys/credentials.jceks -storetype JCEKS After running this command, you will be prompted for a password. That password is the master password you set when enabling this feature. Example: # /usr/jdk64/jdk1.8.0_77/bin/keytool -list -keystore /var/lib/ambari-server/keys/credentials.jceks -storetype JCEKS Enter keystore password: Keystore type: JCEKS Keystore provider: SunJCE Your keystore contains 2 entries ambari.ldap.manager.password, Jan 4, 2017, SecretKeyEntry, ambari.db.password, Jan 4, 2017, SecretKeyEntry, Here we see that the ambari.ldap.manager.password alias exists. In my ambari.properties, we see that the ambari.ldap.manager.password alias is assigned to the LDAP manager password property: authentication.ldap.managerPassword=${alias=ambari.ldap.manager.password} If your credential store does not have the ambari.ldap.manager.password entry, then we should be able to add it by rerunning the ambari-server setup-ldap command. Or you can try to manually add the password to the credential store using the keytool command like: $JAVA_HOME/bin/keytool -importpass -alias ambari.ldap.manager.password -keystore /var/lib/ambari-server/keys/credentials.jceks -storetype JCEKS For example, /usr/jdk64/jdk1.8.0_77/bin/keytool -importpass -alias ambari.ldap.manager.password -keystore /var/lib/ambari-server/keys/credentials.jceks -storetype JCEKS Enter keystore password: Enter the password to be stored: Re-enter password: Enter key password for <ambari.ldap.manager.password> (RETURN if same as keystore password): I entered the master password at the first prompt and the LDAP manager password for the next 2 prompts. I simply hit the return key for the last prompt. Maybe this will help. ... View more

Added, thanks for the suggestion. ... View more

Added, thanks for the suggestion. ... View more

@Jasper It seems like you have taken many of the steps that I would have. Normally I would have pointed you to a site like https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM to verify that your web browser was configured properly. If that didn't have any success, I would have had you execute curl to see if there are any interesting messages. In fact, in your case there are... or rather there is a lack of interesting messages. I would have expected to see curl send back a new request containing an "Authorization" header after receiving the 401 error and the "WWW-Authenticate: Negotiate" response header. However this is not happening. On top of this, the error that curl shows you is interesting gss_init_sec_context() failed: An unsupported mechanism was requested. unknown mech-code 0 for mech unknown I typically see "unknown mech-code 0 for mech unknown" on successful calls, but I haven't seen "An unsupported mechanism was requested.", so maybe a feature of curl has not been turned on. Execute "curl --version" to ensure that Kerberos authentication is enabled. On my workstation I get: $curl --version curl 7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets Notice in the "features" section we see "GSS-API Kerberos SPNEGO". If you do not see this, your version of curl does not support this type of authentication. This may or may not affect how FireFox works. ... View more

The Ambari agent handles the other keytab files. If this is working, then it is either running at root or sudo has been properly set up for it. ... View more

@Qi Wang Since Ambari is running a non-privileged user, it is possible that the keytab file failed to be moved into place due to permission issues. Make sure that the sudoers file is setup properly - for example, see http://docs.hortonworks.com/HDPDocuments/Ambari-2.4.2.0/bk_ambari-security/content/sudoer_configuration_server.html This is needed due to a change made for Ambari 2.4.0 where Ambari, by default, creates it own Kerberos identity and distribute its keytab file to itself. Sudo is needed to this due to permission issues writing to /etc/security/keytabs. To confirm this is the issue, you might want to take a look at the ambari-server.log to see if there are any relevant error posted. I, unfortunately, do know the exact wording to look for off the top of my head. ... View more