asked on
LDAPS Server 2012 R2 Error 0
Good morning,
We're trying to get information from our DC via LDAPS and have hit a wall, so we are reaching out for some help from all you lovely people!
When trying to connect, we keep getting Error 0 messages (we are using ldp.exe to test connection):
We have also checked that there is no certificate in the Service, Active Directory Domain Services Personal Store (as there have been references that we have come across where people simply had to remove a certificate from there to get things working); there is no certificate there.
We have tried creating the UseHostnameAsAlias registry key (HKEY_LOCAL_MACHINE\SYSTEM
Any help on this would be greatly appreciated.
Kind regards,
Kyle
We're trying to get information from our DC via LDAPS and have hit a wall, so we are reaching out for some help from all you lovely people!
When trying to connect, we keep getting Error 0 messages (we are using ldp.exe to test connection):
ld = ldap_sslinit("dc1.domain.local", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 256 bits
Established connection to dc1.domain.local.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
<blarb from here removed>
-----------
We have also checked that there is no certificate in the Service, Active Directory Domain Services Personal Store (as there have been references that we have come across where people simply had to remove a certificate from there to get things working); there is no certificate there.
We have tried creating the UseHostnameAsAlias registry key (HKEY_LOCAL_MACHINE\SYSTEM
ld = ldap_sslinit("dc1", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to dc1.
Any help on this would be greatly appreciated.
Kind regards,
Kyle
* LDAPSActive Directory
Last Comment
Kyle Aquini
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Also, one way you can always verify if you don't completely trust what the application is telling you is to do a network capture.
ASKER
I think I'll be trying that now as we are getting an issue when using a custom Java Application:
Logging in using ldap on port 389 works fine and returns a successful verification with a domain user account.
Logging in using ldaps on port 636 results in an SSLHandShakeException because the certificate cannot be verified. This is when using a certificate generated by the process noted in my original post.
Is there a way that you can force ldap to use a specific certificate for server authentication or does it select one from what is available (each of the DCs have several certificate, several either including or specifically for server Authentication)?
Logging in using ldap on port 389 works fine and returns a successful verification with a domain user account.
Logging in using ldaps on port 636 results in an SSLHandShakeException because the certificate cannot be verified. This is when using a certificate generated by the process noted in my original post.
Is there a way that you can force ldap to use a specific certificate for server authentication or does it select one from what is available (each of the DCs have several certificate, several either including or specifically for server Authentication)?
If you're using a self-signed certificate, then it has to be installed on the client trusted root certification authorities store as well. I can't remember if Java uses it's own store or not.
If you have the certificate in the NTDS certificate store, it should be used over any other certificates (with server authentication purpose) in the Local Machine store.
Here's how to put certificate in the NTDS (AD DS) store (copied from https://technet.microsoft.com/en-us/library/dd941846(WS.10).aspx):
If you have the certificate in the NTDS certificate store, it should be used over any other certificates (with server authentication purpose) in the Local Machine store.
Here's how to put certificate in the NTDS (AD DS) store (copied from https://technet.microsoft.com/en-us/library/dd941846(WS.10).aspx):
To import a certificate into the AD DS personal store
1.Open a command prompt as an administrator. To open a command prompt as an administrator, click Start. In Start Search, type Command Prompt. At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
2.To open Microsoft Management Console (MMC), type mmc, and then press ENTER.
3.Click File, click Add/Remove Snap-in, select Certificates from the available snap-ins, and then click Add.
4.In Add or Remove Snap-ins, click Service account to view the certificates that are stored in the service's personal store, and then click Next.
5.In Add or Remove Snap-ins, click Local computer, and then click Next.
6.In Add or Remove Snap-ins, click Active Directory Domain Services, click Finish, and then click OK.
7.In the console tree, expand Certificates - Service (Active Directory Domain Services), expand Personal, and then expand Certificates.
8.To import a certificate, right-click the NTDS\Personal folder, click All Tasks, and then click Import. When the certificate is imported, client computers should be able to make SSL connections to all domain controllers in the forest.
ASKER
Hi footech,
Just to update; we have it all working now (it broke briefly after a while and then removed the cert from the ADDS store and it jumped back into life!)
Thanks for all the help with this,
Just to update; we have it all working now (it broke briefly after a while and then removed the cert from the ADDS store and it jumped back into life!)
Thanks for all the help with this,
Fantastic; I feel like a tit now!
Thank you very much,
Kyle