Active Directory authentication load balancing and failover

Question

For applications that authenticate against an Active Directory DC, obviously it would be best to just point them to the main domain DNS record rather than a specific DC for failover, load balancing, etc.

What are best practices for those applications that force you to hardcode a DC's IP? We could hard code a load balancer's IP address instead so if one DC went down that application would still be able to authenticate. Are there any better alternatives?

Solution 1

Active Directory already has load balancing techniques built into it. Your Windows client knows how to locate the redundant domain controllers in its own site, and how to use another one if the first one is unavailable. There's no need to perform additional load balancing, like "clustered" DCs, etc. as long as you have redundant DCs.

In a way, you can think of an Active Directory Site as a "load balancer," because clients in that site will randomly pick one of the DCs in the same site. If all the DCs in a site fail or if the site has no DCs, then the clients will pick another site (either next-closest site or at random.)

You can load balance Active Directory-provided DNS service for domain-joined clients by putting a VIP on a hardware load balancer, and having that VIP load balance between several of the domain controllers. Then on your clients, put that VIP as the preferred DNS server in the TCP/IP configuration.

I'm doing that right now for a global infrastructure and it's working great.

But that only applies to DNS service.

Don't try to load balance your domain controllers for authentication. It's asking for trouble. You would at the least have to do a lot of complex custom SPN work and you'd be throwing yourself way out of Microsoft support boundaries. From this blog, which you should read, I will quote him:

Go back to the vendors and tell them you don’t consider them to be AD Integrated and you will find a different solution.

Now as for applications that ask you to type in the IP address of a domain controller? Well, I'll just reiterate my comment:

Whoever wrote an application that forces you to hardcode the IP address of a domain controller into it doesn't know what he or she is doing.

Solution 2

there has never been a good reason to hardcode an IP or use an IP to resolve AD queries. There are no best practices for bad practices.

Solution 3

Several of the other answers to this question seem to assume there is no other world than Microsoft aware applications. Unfortunately this isn't the case, as evidence by the original question:

What are best practices for those applications that force you to hardcode a DC's IP?

While Microsoft does not support or recommend using a NLB solution in front of Active Directory there does indeed appear to be some options for authenticating non-Microsoft AD aware applications.

• Understanding Proxy Authentication in AD LDS
• F5 Certified iApp for load balancing LDAP
• Pass-Trough authentication with SASL

Comments

[Michael Hampton]

Find the application's developer and have them fix it.

[Derrick]

It's mostly for some legacy apps and old NAS boxes that we're not quite ready to replace yet.

[mfinni]

"There are no best practices for bad practices." Quote of the day, sir.

[Dscoduc]

The original question was "What are best practices for those applications that force you to hardcode a DC's IP?". To suppose there are no legitimate apps out there that don't support dynamic discovery is a bad assumption. Plenty of non-Windows applications exist that would like to auth against Active Directory. So what is the best way to make these applications work where dynamic DC discovery isn't an option?

[Ryan Ries]

@Dscoduc Get better applications.

[Dscoduc]

To follow up on this qyestion and my posted answer - my company has implemented a robust F5 LDAP Local Traffic Manager solution that successfully fronts Active Directory for non-Windows systems incapable of leveraging the DCLocator service. We have six LTM's handling traffic all over the world without any issues.