While working with customers to enable LDAPS for their Azure AD Domain Services managed domain, we often have trouble performing a successful LDAPS Bind using the tool LDP.exe. Below are the troubleshooting steps to determine root cause.
Verify Network Connectivity
Always verify that the network connectivity to port 636 exists via DNS name and IP address before troubleshooting further.
1. Browse to https://portal.azure.com -> All Services (top left) -> Azure AD Domain Services -> <managed domain name> -> Properties blade. And verify the following attributes:
- Secure LDAP = Enabled
- Secure LDAP certificate thumbprint (copy and save for later)
- Secure LDAP certificate = Not Expired
- Secure LDAP external IP address
3. Open PortQry UI and perform a verification on the Secure LDAP external IP address on TCP port 636 to verify you see the port LISTENING.
If network connectivity doesnt exist, verify that the AAD DS Network Security Group (NSG) is allowing inbound traffic from client workstation to AAD DS subnet on TCP\636
4. Once network connectivity to the public IP of LDAPS on TCP\636 has been confirmed. Perform the same test, but use any DNS name you have registered for this public IP. Example: ldapstest.jasonfritts.me.
NOTE: The domain name will not necessarily resolve for an external client machine unless it has been registered by you or an admin manually. Example: jasonfritts.onmicrosoft.com will not resolve to my LDAPS public IP. I would need to manually register a record for ldapstest.jasonfritts.me to point to 18.104.22.168. For testing purposes in this example, I have updated my Windows HOSTS file to point jasonfritts.onmicrosoft.com to 22.214.171.124
5. Next verify that this certificate has been imported in the following locations on your workstation’s Computer certificate store
- Open the certificates MMC snap-in to your Local Computer certificate store per instructions found here
- Browse to the Trusted Root Certification Authorities\Certificates store and verify certificate with ”
<aad ds domain name> ” is found listed.
You can also verify this via an administrative PowerShell cmd prompt and cmds like:
PS C:\ cd cert:\\
PS Cert:\> get-childitem -Path ’53F65017E5614959824FA5147A8173CAF8662D73′ -Recurse
If this certificate is not found in this location, please use the More actions -> Import action to import your self-signed AAD DS LDAPS certificate into the Trusted Root Certificate store of your Computer cert store and then retry your LDP.exe connection.
Until the self-signed certificate is trusted by your local computer, LDP.EXE will result in the error “Error: <0x51>: Fail to connect to jasonfritts.onmicrosoft.com”.
You can then check the Windows Event Log on the client machine and you will find a Event in System log with Source = Schannel and EventID 36882 complaining about Certificate received from the remote server was issued by an untrusted certificate authority.
6. Once the self-signed certificate has been added to your Computer’s Trusted Root Certificate Store, you will be able to
Hope this helps someone!