Created 01-11-2017 05:39 PM
Hello, I'm receiving this error:
Failed to connect to KDC - Failed to communicate with the Active Directory at LDAP://hq.domain.com/OU=Production,OU=domain,DC=hq,DC=domain,DC=com: simple bind failed: hq.domain.com:389 Update the KDC settings in krb5-conf and kerberos-env configurations to correct this issue.
I've been following this guide: https://www.ibm.com/support/knowledgecenter/SSPT3X_4.2.0/com.ibm.swg.im.infosphere.biginsights.admin... as well as the HDP documentation on this. I'm doing the automated kerberos wizard.
JCE has been distributed to all of the nodes, I'm using Oracle JDK 1.8.
Attached is the full stack trace: kerberos-stack.txt
The KDC Test Connection passes just fine, I can see expected network traffic between my domain controller and the Ambari server. The only main difference is that I'm not using SSL on AD. I figure this should be fine and Ambari can just use the plaintext 389 port. I realize this is a security concern but I have no way around this right now. I don't have control over this area of our domain setup. Could this be my issue?
Any help appreciated. Thanks. EDIT: I was able to successfully parse AD using the ldapsearch tool using the same DN and LDAP url that I'm specifying. Also with the same admin user.
Created 01-17-2017 12:31 PM
I suffered the exact same issue of:
Caused by: java.net.SocketException: Connection reset
Logs giving nothing away, just constant refusal to connect to ldap://ad.mydomain.com:389 despite confirming LDAP was working on the same host using ldapsearch.
Anyway, I decided to test with LDAPS (following https://community.hortonworks.com/articles/60186/hdf-20-use-ambari-to-enable-kerberos-for-hdf-clust-..., and using exactly the same values for my config it worked.
Created 01-11-2017 05:49 PM
Problem seems to be with the ldap URL or the DN. And the error in the log shows "Root exception is java.net.SocketException: Connection reset"
It could be that Active directory is set to accept connections over SSL. You may try using ldaps:// instead of ldap:// (this needs active directory cert to be imported to java cacerts)
Created 01-11-2017 06:03 PM
Hi @rguruvannagari thanks for the reply. I just confirmed with my AD guy that our AD is not set up for SSL at all. I was able to parse AD using the ldapsearch tool using the same DN and ldap url I'm specifying. I'll keep trying different DN's
Created 01-11-2017 06:01 PM
The error you are getting is :
Caused by: java.net.SocketException: Connection reset
Failed to connect to KDC - Failed to communicate with the Active Directory at LDAP://hq.domain.com/OU=Production,OU=domain,DC=hq,DC=domain,DC=com: simple bind failed: hq.domain.com:389
Above error indicates communication failure with AD, but you mentioned KDC test passes? Can you make sure you are using correct communication string? Can you run ldapsearch with it?
Also, Have you followed below doc:
Can you upload your krb5.conf?
Created 01-11-2017 06:26 PM
@lraheja I did not go through the ambari-server setup-ldap steps, I must've gone past this some how. After configuring this and restarting Ambari the LDAP tests seem to be getting further but are now just timing out. My krb5.conf is not configured at all, it's the default conf file. I assumed Ambari was going to configure this through the wizard, is that not the case?
Created 01-11-2017 07:01 PM
@Dezka Dex Can you upload new stack trace?
Created 01-11-2017 07:38 PM
@lraheja Sure, it's no longer timing out, it's just back to what it was doing before. kerberos-stack-2.txt
Created 01-17-2017 12:31 PM
I suffered the exact same issue of:
Caused by: java.net.SocketException: Connection reset
Logs giving nothing away, just constant refusal to connect to ldap://ad.mydomain.com:389 despite confirming LDAP was working on the same host using ldapsearch.
Anyway, I decided to test with LDAPS (following https://community.hortonworks.com/articles/60186/hdf-20-use-ambari-to-enable-kerberos-for-hdf-clust-..., and using exactly the same values for my config it worked.
Created 01-17-2017 03:02 PM
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.
Created 01-19-2017 03:33 PM
Yup, this was the issue. I enabled LDAPS on our domain and it works now.