Our situation

We currently have many web applications that use LDAP for authentication. For this, we point the web application to one of our AD domain controllers using the LDAPS port (636).

When we have to update the Domain Controller, this has caused us issues because one more web application could depend on any DC.

What we want

We would like to point our web applications to a cluster "virtual" IP. This cluster will consist of at least two servers (so that each cluster server could be rotated out and updated). The cluster servers would then proxy LDAPS connections to the DCs and be able to figure out which one is available.


For anyone that has had experience with creating an HA cluster for AD's LDAP interface:

  1. What software did you use for the cluster?
  2. Any caveats?
  3. Or perhaps a completely different architecture to accomplish something similar?


Perhaps my question wasn't initially clear enough. My apologies for that.

These web applications are not developed by us and are not AD-aware. They only ask for an LDAP server's hostname/IP address. Unfortunately, we have to work with that restriction. I understand how SRV records work but, being these are not our applications, doesn't help us in this case.

It is also not realistic for us to force the developers to modify their applications to be AD aware.

The only option is to address this issue within the infrastructure as oppose to the software. My questions are directed toward anyone that has done that specifically.

  • AD clusters well out of the box-- there's nothing special you need to do aside from promoting additional DCs in the domain. – Joel Coel Mar 28 '12 at 1:59
  • 1
    Understood and this works well for AD-aware applications but not for LDAP-authenticating applications. – Belmin Fernandez Mar 28 '12 at 10:28

We use Cisco IOS's Server Load Balancer (SLB) for this against our OpenLDAP servers.
LDAP being LDAP it should work for Microsoft's Active Directory as well.
Other manufactures offer similar products/capabilities. Balancing tcp 389/636 is the same as balancing tcp 80/443 (or any other tcp for that matter).

You may have some certificate issues to work though. You might be able to tell the application to be less vigilant. (It may already be, not sure how your AD's certs are signed or what CAs you trust.) Or have your AD servers use certs with appropriate subjectAlternativeName fields.


You should be able to just point your web app servers at the FQDN of the Active Directory domain. This should connect them to an available DC.

For example, your domain might have a couple of DCs:



Rather than pointing your web servers at dc1 or dc2 explicitly, just point them at example.com (try telnetting to example.com on port 636 - you'll get a connection to a DC). I think it's basically round robin DNS.

I must admit I don't know what would happen if a DC was offline. It might take a while for the DNS records to reflect that, if indeed they would at all. It might be worth testing instead of putting a load balancer in between.

  • We tried this before but it does not address a server being down unfortunately. Our in-house developed applications actually perform a DNS lookup for the A record and tries each IP until one works. However, this is not how other web applications work unfortunately. – Belmin Fernandez Mar 27 '12 at 23:10
  • 1
    The problem with this approach, when using LDAP over SSL or with STARTTLS is that the domain controller will use its own server certificate to encrypt the connection, so the CN will not match, causing applications that do correct certificate validation to fail. – AdmiralNemo Mar 27 '12 at 23:41
  • I suppose we could just do straight LDAP from the cluster to the LDAP servers. Then LDAPS from the webapp to the cluster. It is certainly not a deal breaker. – Belmin Fernandez Mar 27 '12 at 23:45
  • 2
    @AdmiralNemo That's why domain controller certificates using modern templates have the domain's FQDN in the subjectAlternateNames property of the certificate. – Shane Madden Mar 28 '12 at 0:51
  • This is correct, with the addition that you have to have the certificates on the AD servers just right so no matter which server responds it uses a name that the certificate. – Joel Coel Nov 29 '17 at 21:43

The correct way to do this is to use the DNS SRV records to look up the domain controller names and ports, as well as ascertain which servers to use in what order. Unfortunately, not many LDAP applications seem to support SRV record lookups.

The SRV record for Active Directory domain controllers is _ldap._tcp.domain.tld. This will return a list of hosts and ports, as well as a priority and weight for each (these values can be set using Group Policy) that together indicate which server to use.

  • ` Unfortunately, not many LDAP applications seem to support SRV record lookups.` Yup. Because of that, we need to figure out a way to make our infrastructure HA. – Belmin Fernandez Mar 27 '12 at 23:46
  • 1
    +1 - The Domain Controller Locator protocol is exactly what you want: technet.microsoft.com/en-us/library/cc961830.aspx Implementing that protocol would assure you the best compatibility w/ Microsoft. – Evan Anderson Mar 28 '12 at 1:40
  • Thank you but we did not develop the web applications so this is not helpful for us. I have updated the question to clarify that point. – Belmin Fernandez Mar 28 '12 at 10:28

The application needs to be robust enough to do what Windows clients do internally if one domain controller is unavailable - it attempts to connect to another domain controller.

The way this would work is when the application starts, the Directory Service access component of the application would do the following:

  • Build a list of all domain controllers in the site (and any adjacent sites, if preferred)
  • Perform a series of tests to validate connectivity (ping, 389/3268/636 test). This would also confirm if it is a DC, GC, or RODC.
  • Perform a simple query to validate the directory service is functional and authentication is working.
  • Save a list of the known good domain controllers, and also a list of the offline domain controllers.

You then use these known good servers when performing a bind, embedding the server in the bind path. If an exception occurs and is one of the types that would indicate a problem with the dc (server not operational, busy, timeout, etc), you add that dc to the offline list and attempt the operation using one of the other dc's.

  • Thank you Greg but in this scenario we did not develop the web applications so we cannot implement this. I have updated the question to clarify that point. – Belmin Fernandez Mar 28 '12 at 10:30

A possible solution is an LDAP Proxy Server. There aren't many out there but will definitely do the trick. Here is one, a bit of an overkill - http://www.unboundid.com/products/directory-proxy-server.php. Am sure there are much more cheaper open source alternatives to this LDAP proxy server.

EDIT: just a thought, within your application do you have a location to enter the LDAP URI? If so, can you not enter a sequence of servers separated by space like: ldap://123..456.789.111 ldap://123.456.789.222 ldap://123.456.789.444

  • I like your first solution a lot. Have you done this in the past? W.r.t. entering multiple LDAP servers: That is kind of what we do now but it is a pain to keep up. – Belmin Fernandez Mar 28 '12 at 15:34

As certificates will become the major problem after you've either decided to use a load balancer or to rely on DNS round-robin (i.e. ldap.contoso.com will resolve to multiple IPs), Russell Tomkins (MSFT) has published a guide for those use-cases here: Creating Custom Secure LDAP Certificates for Domain Controllers with Auto Renewal

He also notes that this is not a supported configuration. As other answers note, applications should use the SRV records, but often aren't.

You essentially have to add a new template for issuing certificates in which you switch to "Supply in request" in the properties tab "Subject Name". You'll have to issue the first certificate yourself by supplying your load balancer's name (ldap.contoso.com) as an additional SN, and from then on, auto-enrollment will take over.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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