How to make AD highly available for applications that use it as an LDAP service

Question

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.

Questions

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?

Update

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.

Solution 1

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.

Solution 2

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:

dc1.example.com

dc2.example.com

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.

Solution 3

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.

Solution 4

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.

Solution 5

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

View more solutions

Comments

[AdmiralNemo]

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.

[NukaRakuForgotEmail]

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.

[NukaRakuForgotEmail]

` 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.

[ravi yarlagadda]

@AdmiralNemo That's why domain controller certificates using modern templates have the domain's FQDN in the subjectAlternateNames property of the certificate.

[Spence]

+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.

[NukaRakuForgotEmail]

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.

[NukaRakuForgotEmail]

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.

[NukaRakuForgotEmail]

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.

[Joel Coel]

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.