Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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
Understood and this works well for AD-aware applications but not for LDAP-authenticating applications. – Belmin Fernandez Mar 28 '12 at 10:28
up vote 1 down vote accepted

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.

share|improve this answer

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 (try telnetting to 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.

share|improve this answer
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
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
@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

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.

share|improve this answer
` 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 - The Domain Controller Locator protocol is exactly what you want: 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.

share|improve this answer
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 - 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

share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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