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?

  • 2
    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. – Ryan Ries Jun 5 '13 at 20:27
  • 1
    Find the application's developer and have them fix it. – Michael Hampton Jun 5 '13 at 20:28
  • It's mostly for some legacy apps and old NAS boxes that we're not quite ready to replace yet. – Derrick Jun 5 '13 at 20:38

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.

| improve this answer | |
  • 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? – Dscoduc Aug 21 '17 at 21:05
  • @Dscoduc Get better applications. – Ryan Ries Mar 17 '18 at 13:24

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.

| improve this answer | |
  • 1
    "There are no best practices for bad practices." Quote of the day, sir. – mfinni Jun 5 '13 at 21:22

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.

| improve this answer | |
  • 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. – Dscoduc Jun 5 '19 at 19:41

An actual need for external "Load balancing" AD is rare, and it is difficult to do properly. A need for typical queries may work fine, however a typical Windows client and applications need to perform updates. A Windows client attempts to establish an affinity with a particular dc, so that if it updates something and immediately attempts a subsequent operation, it hits the same dc. Application developers do the same thing. If you write code that creates a user account, then attempt to change the password on that account 1 ms later, you need to hit the same dc.

If you were to front-end AD with some load balancer solution, you take ownership of ensuring those approaches and affinities dont break.

If the need is availability, as opposed to balancing load, clustering may be more appropriate (cluster can of worms aside).

In large AD implementations, a more traditional approach is to identify the majority consumers, and put them in a site with their own dc's. For example, if you have five Exchange servers, create a site for the subnets for those servers, and put dedicated GC's in that site. Same would apply for other servers such as SharePoint.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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