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.

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

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

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

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

Answer 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

Answer 6

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.

Answer 7

I guess why Windows do not have simple analogue of HSRP or VRR.

LDAP proxy is a solution but it is extra complexity.

I plan to try one other thing.

• take 2 DC
• run OSPF on both
• create loopback with the same IP (not 127.0.0.1) and add into OSPF

Then use this IP for LDAP. OSPF will route it to the nearest host (and we can balance weights so that it will go to the one host always). If host (DC) fail then OSPF will have it from other DC.

This is not perfect as I can not link it to the service (so only if LDAP is active it is announced) But it is a very simple and easy solution

Answer 8

You need to have at least two domain controllers, preferably spread across multiple locations.

And then you cam use a network load balancer for example a Linux server with HAProxy. HAProxy is a open-source load balancer and is capable of load balancing ldap traffic. Of course the applications need to use the load balancing endpoint of HAProxy

https://tylersguides.com/guides/haproxy-ldap-backend/

F5-Bigip is a market leading hardware appliance which can act as a load balancer, but that does require a investment, so then you need to have more services which require to be high available

If you need to load balance LDAPS (LDAP over SSL/TLS) traffic for multiple Active Directory servers using HAProxy, you can modify the HAProxy configuration to accommodate LDAPS. LDAPS typically runs on port 636, and SSL/TLS encryption is involved. Here's how you can configure HAProxy for LDAPS load balancing:

1. Install HAProxy:

• Install HAProxy on a dedicated server or VM as mentioned earlier.

2. Configuration File:

• Edit the HAProxy configuration file, typically located at /etc/haproxy/haproxy.cfg. Open it in your preferred text editor.

3. Configure HAProxy for LDAPS:

Here's an example of the configuration file to load balance LDAPS traffic for multiple Active Directory servers:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode tcp
    option tcplog
    timeout connect 5s
    timeout client 1m
    timeout server 1m

frontend ldaps-frontend
    bind *:636 ssl crt /etc/haproxy/server.pem
    mode tcp
    default_backend ldaps-backend

backend ldaps-backend
    mode tcp
    balance roundrobin
    option tcp-check
    server dc1 192.168.1.10:636 check
    server dc2 192.168.1.11:636 check
    server dc3 192.168.1.12:636 check

In this configuration, the front end listens on port 636 (the standard LDAPS port) and specifies an SSL certificate (crt /etc/haproxy/server.pem). The backend section specifies three LDAPS servers, and HAProxy will distribute incoming LDAPS traffic in a round-robin fashion to these servers. Replace the IP addresses and ports with the actual addresses of your Active Directory LDAPS servers.

4. SSL Certificate:

• Make sure you have an SSL certificate (server.pem) for LDAPS. You need to provide this certificate in the HAProxy configuration.

5. Save and Restart:

• Save the configuration file and restart HAProxy:

sudo service haproxy restart

6. Update LDAP Client Configuration:

• Ensure that the LDAP clients are configured to connect to the HAProxy server's IP address and port 636 for LDAPS.

7. Testing and Monitoring:

• Test the configuration to verify that HAProxy is correctly balancing LDAPS traffic across your Active Directory servers. Implement monitoring and alerting for HAProxy to monitor the health of your LDAPS servers.