6

I am trying to provide Authentication as a Service to my customers. LDAP authentication is perfect for this however I am not a fan of clear text sessions.... enter LDAPS. Active Directory of course has LDAPS turned on however the certificate used is self or local domain signed. This becomes problematic for various reasons. I cannot require my customers to trust my self or locally signed certificate. A third party certificate that my customers do trust would work but unless I am going to create and purchase a new certificate each time I bring up a domain controller that isn't going to work. Ok... so a third party wildcard certificate SHOULD work, but how do you implement?

I have of course Google'd and have read: How to enable LDAP over SSL with a third-party certification authority and Enable LDAP over SSL - Using Wildcard Cert? and Wildcard Certificate on a DC for LDAPS.

All of those are great but I am still missing something...
What are the exact steps to follow?

Am I simply following the steps at How to enable LDAP over SSL with a third-party certification authority but using CN=*.domain.ext instead of CN=mydc.domain.ext ?

Improve this question
4
  • 3
    Are you exposing these DCs to the Internet? You shouldn't. AD DS isn't hardened for this. Use something like AD FS exposed to the Internet via the Web Application Proxy (WAP) role.
    – MDMarra
    Apr 10, 2014 at 23:03
  • How many DCs do you have? Do your external clients address your individual DCs? Can you just setup a proxy / load balancer on your border and apply a single generic certificate to that? Seems like this would be easy to do with something like stunnel.
    – Zoredache
    Apr 10, 2014 at 23:27
  • No DCs will be exposed to the open internet. No load balancer is available to "proxy" the certificate. Thank you both for your replies. Incidentally that is how I have solved for this problem in the past, so it is a good suggestion, just out of the scope of this problem.
    – Aaron Wurthmann
    Apr 14, 2014 at 16:42
  • As for AD DS being exposed to the internet, you can in fact harden a DC to such a level that the risk is mitigated, IDS, packet inspection, "only allowed hosts" or port knocking. It isn't for the faint of heart but it is dooable. I've done it in the past along with a load balancer, but that is out of scope for THIS problem. Thank you very much for the reply. :-)
    – Aaron Wurthmann
    Apr 14, 2014 at 16:52

2 Answers 2

Reset to default
2

Beside sense of exposing AD DS to internet - called KB 321051 says:

The Active Directory fully qualified domain name of the domain controller (for example, DC01.DOMAIN.COM) must appear in one of the following places:

The Common Name (CN) in the Subject field. DNS entry in the Subject Alternative Name extension.

FQDN requirement means wildcard will not work, or at least usually should not work (as always it depends on client code).

Improve this answer
0

Update: Using Windows Server 2016, I have no issue using a wildcard certificate for LDAPS. I am able to make a test connection using the ldp.exe utility on port 636 with "SSL" checked.

LDAPS works immediately after importing the wildcard cert into the Personal ("My") certificate store without any restart needed. I can confirm this is working because after making the connection with ldp.exe, I see the CA's root certificate has been downloaded to the Root certificate store.

My application which requires LDAPS (in this case, Tableau Server) also makes a successful test connection as part of its upgrade script.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.