PWM LDAPS Cert Clarification for Domain Controllers

[Adrian Puryear]

Looking for which domains need to be in the SANs for the LDAPs server as I have researched here and it is not exactly clear.

For each LDAPS DC that will serve as connection host for PWM I understand that a self-signed from AD CA or 3rd party CA that has a custom kerberos templated cert that auto-renews.  The question I have is what domain names need to be in there:

Server A - LDAPS DC - ServerA.example.com

Server B - LDAPS DC - ServerB.example.com

Server C - DC Only - ServerC.example.com

Root Domain Name - example.com

Config shows both certs valid for Server A and Server B with only Server A listed in the LDAP URL section and listing both there (made zero difference if 1 LDAPS DC server was used or 2)

Option 1 - Server A and B DNS Listed only in their own certificates

Option 2 - Server A and B DNS Listed in Each Server's Certificate in the SAN section

Option 3 - Server A and B and C DNS Listed only in their own certificates

Option 4 - Server A and B and C DNS Listed in Each Server's Certificate in the SAN section

Option 5  - Server A and B and Root DNS Listed only in their own certificates

Option 6  - Server A and B and DNS Root Listed in Each Server's Certificate in the SAN section

Option 7 - Server A and B and C and Root DNS Listed only in their own certificates

Option 8 - Server A and B and C and Root DNS Listed in Each Server's Certificate in the SAN section

Having this error when trying to log in with any AD user account and everything tests fine in the config section and the Subject Name for the certificate on the LDAPS/DC servers match the server correctly but do not contain each other's domain name nor the root so trying to understand this requirement as it is not clear to me.

--------------------------------

An error has occurred. If this error occurs repeatedly please contact your help desk.

5015 ERROR_INTERNAL (unexpected error during ldap search (profile=default), error: 5015 ERROR_INTERNAL (ldap error during searchID=2, context=DC=example,DC=com, error=javax.naming.PartialResultException, cause:javax.naming.CommunicationException: example.com:636, cause:javax.net.ssl.SSLHandshakeException: server certificate {subject=CN=ServerB.example.com} does not match a certificate in the PWM configuration trust store., cause:java.security.cert.CertificateException: server certificate {subject=CN=ServerB.example.com} does not match a certificate in the PWM configuration trust store.))

[Adrian Puryear]

Sorry second part of error if Server A and Server B are listed in the LDAP URL section of the config

Error 5017
Directory unavailable. If this error occurs repeatedly please contact your help desk.

5017 ERROR_DIRECTORY_UNAVAILABLE (unexpected error during ldap search (profile=default), error: 5017 ERROR_DIRECTORY_UNAVAILABLE (unable to reach any configured server, maximum retries exceeded))

[Adrian Puryear]

Test Result From Config Page:

[Adrian Puryear]

Imported CA and both Server A and B certs that were issued by AD CA into Java keystore just to see but everything I read is if the config has imported the certs directly, it uses them.  At an absolute loss as to why it all configs out correctly but every user I try fails the login with this 5017 error saying it cannot connect.

[Adrian Puryear]

ANSWER IS ...

There are 2 SOLUTIONS to this very common problem but I wanted to document them for the next person who struggles and spends hours going down the rabbit hole here with a very simplistic and easy to understand answer to this problem.

First off, thank you to @Jason Rivard for all the replies in other posts that helped to paint the full picture here and forgive me if I simplify things a bit or not have the exact concept down. I hope you can PIN this or another like it to the Wiki or update the Wiki with this information.

NOTE: Java Keystore Certs DO NOT MATTER if certs were imported into the Config via the Config Editor GUI web page as those override the Java Keystore ones so don't bother with that mess as that was coded into version 1.9+ (not exactly sure what version as I didn't want to go back and look while posting this), safe to say, you use the newest version than this is a non-issue.

Basically, it comes down to this question, do you need to be able to do perform lookups at the Root level INCLUDING the CN=Users container?  If the answer is YES = SOLUTION 1, if the answer is NO = Solution 2

SOLUTION 1: Custom Certs For Domain Controllers in Active Directory - This is the only method that allows for Root level Domain lookups to be performed.  Simple explanation, the root domain (example.com) must be in the SAN portion of the Certificate that is issued by your CA for EACH domain controller you want to use for LDAPS connections but specifically for lookups.  Not going to dive into why but the helpful link to do this below explains a lot and definitely the previous posts on this do as well.

https://learn.microsoft.com/en-us/archive/blogs/russellt/custom-ldap-certs - My person reference for steps to create custom cert with root domain in Subject Alternative Name field if you wanted a step-by-step guide that was for me easy to follow and understand (READ IT FULLY FIRST just so you can understand the concepts before stepping into this as a wrong move on a cert for a DC could create havok in your environment while trying to replace/fix it. You are so duly warned LOL.

SOLUTION 2: Declare lookups to start in OUs inside the root-level domain and you have no issues because there will not be any cert conflicts with the root domain missing in SAN as the lookup does not start at the root level. Personally, I think this is the better solution anyway, for a couple reasons... 1, simple and easy fix assuming you used AD like most and created OUs for users especially those across multiple domains/forests and none of your non-admin users are stored in the default "Users" container. 2, this is a huge security benefit as you can limit exposure to admin accounts which are typically stored in the "Users" container OR stored in a special OU anyway which does not have to be listed in your lookup in the Config section called "LDAP Contextless Login Roots".  My only suggestion here knowing now would be to implement an option that allows an exclusion list where you want to exclude a lookup in say a child OU of a parent OU that you need to have lookups for.

I hope this helps someone!

[Jason Rivard]

Thanks for this write up, I feel like I've answered this topic a thousand times in my life :)  Feel free to add it to any of the wiki pages on github.