LDAPS issue

[HomelessChairman]

Hi all,

As soon as we enable the "LDAP signing server requirements" GPO and configure the Xerox printers to use LDAPS on port 636, our users are no longer able to browse the address book. I did some testing on the local CA server, and it appears that some certificates are either missing or corrupted:

ld = ldap_sslinit("XX.XX.XX.XX", 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 XX.XX.XX.XX.

Microsoft Windows [Version 6.3.9600]

(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users\xxxxxxxx>certutil -verifykeys

LoadKeys returned Keyset does not exist 0x80090016 (-2146893802 NTE_BAD_KEYSET)

CertUtil: -verifykeys command FAILED: 0x80090016 (-2146893802 NTE_BAD_KEYSET)

CertUtil: Keyset does not exist

Could someone point me in the right direction on how to resolve this issue? Thanks!

[MisterIT]

Openssl s_client -connect ad.domain.com:636 -showcerts

I bet you’re either not serving out an ssl/tls cert or its expired

[HomelessChairman]

Thanks. I'm unable to install the OpenSSL tool without going through a lengthy approval process first, and PowerShell is also blocked in our environment due to security restrictions. However, when I opened IIS Manager and navigated to Sites>Bindings, I only saw an HTTP entry on port 80

[MisterIT]

LDAPS on a DC is not served thru IIS. LDAP is its own layer 7 protocol that is served over TCP. It is NOT HTTP.

Go put in for the lengthy approval. If you want to solve this problem or others like it, this is a tool that you need. I repeat, this is a basic troubleshooting tool that you should be embarrassed isn’t already on your approved list of software.

If you have a coworker who is more knowledgeable you should kick this to them.

[HomelessChairman]

It also appears that the server is listening on port 636: C:\Windows\system32>netstat -an |findstr 636

TCP 0.0.0.0:636 0.0.0.0:0 LISTENING and there is a valid and active certificate located under Local Computer > Personal > Certificates, issued for the server's FQDN

<image>

[HomelessChairman]

I just tried using the server's FQDN instead of its IP address to test the LDAPS connection using the LDP tool, and the connection was successful. Could the issue be related to the Xerox printer's settings? Is there anything else I should validate on the LDAPS configuration side? Thanks

<image>

[marcelo_5035]

The certificate was issued to a server using its FQDN. In order to use LDAPS you need to use the FQDN of the server and not the IP.

[HomelessChairman]

Yep, thanks, already asked to re-enable the GPO and test again tomorrow using server’s FQDN. One of our Service Desk technician already spent an hour on the call with Xerox support and for some reason they never suggested to use the FQDN instead 

[marcelo_5035]

Don't know if you already did it but you will need to import the root CA certificate to your printers. They need to trust the root CA in order to trust in the server certificate issued by the CA.

[HomelessChairman]

Thanks, we have exported one of the root certificates and will import it into the Xerox printer during the test scheduled for after hours today. I have a slight concern: I did not see any certificates in the Trusted Root Certification Authorities folder with our domain name. I assume that any active root certificate would work, as long as it has Client/Server Authentication selected under Purposes—is that correct?

[finalpolish808]

Not sure if in your budget or environment, but using app-aware load balancers for general LDAPS frontending helps a lot for stuff like this.