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

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.

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.

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.