7 Reasons Why Load Balancers Don’t Belong Between Clients and Domain Controllers

If you’re considering adding a load balancer between your clients and domain controllers (DCs), stop right there! While load balancers can work wonders in many networking scenarios, Active Directory (AD) isn’t one of them. Here’s why this setup is more trouble than it’s worth. We’ll dive into five detailed reasons why you should let AD do its job without getting a load balancer involved.

1. Active Directory’s Built-In Load Balancing Is All You Need

Active Directory already comes with robust tools that handle load balancing across domain controllers—so why complicate things with a load balancer? Let’s break this down:

Sites and Services Snap-in: AD allows you to set up sites and assign DCs to each one. This lets you group your DCs based on geographical regions or network topology. You decide which DCs are responsible for which site, ensuring that users connect to the closest one for optimal performance. It’s like setting up traffic signs that direct users to the nearest gas station.
Subnets Linked to Sites: AD lets you map subnets to sites. This way, a client in New York won’t accidentally connect to a DC in California—unless you want it to. This is a seamless, automatic process that reduces latency and improves login speed for users.
DNS Priorities and Weights: When you have multiple DCs within a site, AD uses DNS records to balance the load. It assigns priorities and weights to each DC, distributing client connections evenly. It’s like having multiple checkout lines at a grocery store, and a store manager directs people to the least busy line. There’s no overcrowding, and everyone gets served efficiently.

Why add a load balancer? AD already handles the heavy lifting here. Adding an external load balancer just adds complexity and expense with no real benefit.

2. TCP Communication: Don’t Mess with the Three-Way Handshake

When it comes to TCP connections, load balancers can wreak havoc. Every TCP connection begins with a “three-way handshake,” and if the load balancer decides to switch servers mid-communication, things fall apart fast.

TCP Handshake Breakdown: TCP requires this handshake to establish a reliable connection. If your load balancer moves the client to a different DC halfway through, the new DC will not recognize the connection because it wasn’t part of the original handshake. This leads to dropped packets, timeouts, and user frustration. Imagine you’re ordering a pizza, and halfway through the call, your phone suddenly connects you to a completely different restaurant. You can’t expect them to know your order—they weren’t part of the conversation from the start!
TCP Reset Floods: Additionally, if the load balancer aggressively switches DCs, it can lead to TCP reset storms where one DC keeps closing connections that it didn’t start. This can overwhelm your DCs and affect network performance.

Takeaway: AD’s native site-based load balancing works with TCP’s needs, while a load balancer could disrupt the connection flow, causing delays and dropped communication.

3. Kerberos Doesn’t Like Load Balancers Either

Kerberos, AD’s go-to authentication protocol, is a sensitive beast. It doesn’t play well with load balancers for one simple reason: tickets. When a client authenticates, Kerberos gives it a ticket, which is essentially a “permission slip” to access resources via a specific DC. But if your load balancer reroutes the client to a different DC, that ticket becomes invalid.

Ticket Mismatch: Kerberos tickets are encrypted with the original DC’s key. When a client presents a ticket to a different DC, that DC will reject it because it can’t decrypt the ticket. It’s like showing up to a concert with a ticket for a completely different venue—the bouncer won’t let you in.
Sticky Sessions?: You could configure Sticky Sessions on the load balancer to ensure the client sticks to the same DC for the entire session. But this workaround only adds more complexity. If the sticky session fails, you’ll still have ticket decryption issues.
Performance Hits: Every time a Kerberos ticket is rejected due to mismatched DCs, the client has to request a new ticket from the Key Distribution Center (KDC). This adds overhead to both the client and DC, ultimately affecting performance.

Takeaway: Kerberos doesn’t like surprises. When you throw a load balancer into the mix, it becomes a guessing game of which DC holds the right ticket.

4. SSL/TLS Handshake for LDAPS: The Certificate Nightmare

If you’re using LDAPS (LDAP over SSL/TLS), things get even messier with a load balancer. Why? Because SSL/TLS handshakes depend on certificate matching, and your load balancer can break this chain of trust.

Certificate Subject Name Mismatch: SSL/TLS requires that the server’s certificate matches the hostname the client is trying to connect to. So, if your client is trying to connect to dc1.domain.com but your load balancer routes it to dc2.domain.com, the client will receive a certificate mismatch warning. The SSL handshake will fail, and the connection won’t be established.
Managing SAN Certificates: One workaround is to create a Subject Alternative Name (SAN) certificate, which lists all your DCs in the certificate’s SAN field. This works, but if you have many DCs, your certificate could end up with a dozen or more entries. Keeping this updated as DCs come and go can become a headache. It’s like trying to maintain a guest list for a wedding when people keep RSVPing at the last minute.
Wildcard Certificates: Not a Great Solution: Alternatively, you might consider using a wildcard certificate (*.domain.com), but this is a security risk. If that wildcard certificate is ever compromised, it could be used to impersonate any server in your domain—not just your DCs.

Takeaway: SSL/TLS handshakes require exact matching between the certificate and the hostname. A load balancer just complicates this, and the alternatives aren’t much better.

5. LDAP Channel Binding: Don’t Let Your Load Balancer Break the Chain

LDAP channel binding is a security feature that was designed to prevent man-in-the-middle attacks, and guess what? Your load balancer can mess this up too, especially if it’s doing SSL offloading.

SSL Offloading Breaks Binding: With SSL offloading, the load balancer terminates the SSL connection and then re-establishes it with the DC. While this might improve performance, it also breaks the integrity of the SSL session, effectively negating channel binding. The client and DC are no longer directly communicating, which opens up the possibility for tampering.
Security Risk: The whole point of LDAP channel binding is to ensure that the client and DC have a direct, secure connection. By offloading SSL, the load balancer inserts itself in the middle, which is exactly what channel binding is supposed to prevent.
Troubleshooting Pain: Once SSL offloading breaks channel binding, tracking down the issue can be a nightmare. You might be scratching your head wondering why perfectly valid SSL certificates are failing, only to realize that your load balancer is breaking the chain.

Takeaway: SSL offloading may seem like a good idea to reduce load on your DCs, but it breaks a crucial security mechanism—LDAP channel binding.

6. Account Lockouts: The Detective’s Nightmare

One of the biggest challenges with load balancers is account lockouts. Specifically, troubleshooting them becomes incredibly difficult when your load balancer doesn’t preserve the client’s IP address.

No IP Preservation, No Clues: Without IP preservation, all your DCs see is the load balancer’s IP address. So, when a client is repeatedly sending bad login attempts, you have no idea where those attempts are really coming from. It’s like trying to solve a crime when all the witnesses give you the wrong description of the suspect.
Bad Logon Attempts: Imagine a user typing the wrong password several times and getting locked out. With no IP preservation, all you see is the load balancer’s IP, so you’re stuck playing detective to figure out which user is at fault. This can be especially tricky if the bad logon attempts are coming from multiple devices or locations.
Best Practice: If you must use a load balancer, at least configure IP preservation. This ensures that each DC sees the client’s actual IP address, making troubleshooting much easier.

Takeaway: Account lockouts are hard enough to troubleshoot without a load balancer getting in the way. If you’re not preserving IP addresses, you’re adding unnecessary complexity to an already frustrating process.

7. If Your Application Needs a Load Balancer to Communicate with Active Directory, It Wasn’t Built for AD

Let’s be real—if your application requires a load balancer to talk to Active Directory, then it probably wasn’t designed with AD in mind. And that’s a red flag! Here’s why:

AD-Aware Applications Don’t Need Load Balancers: Any well-designed application that integrates with Active Directory should already know how to leverage AD’s built-in load balancing mechanisms. AD’s DCLocator function does this heavy lifting automatically. DCLocator ensures that your application finds the most appropriate domain controller based on the client’s location and network configuration. It’s like having a built-in GPS that always directs you to the nearest and least busy DC.
Developer Oversight: If the application’s developers didn’t consider DCLocator when building the app, then it’s likely they also missed other important Active Directory best practices. This could lead to more issues down the road, such as poor performance, security vulnerabilities, or broken authentication flows.
Microsoft’s Stance: Here’s the kicker—Microsoft doesn’t officially support load balancers between clients and domain controllers. This should be a clear sign that it’s not a recommended practice. When something breaks (and it will), you might find yourself in a support dead-end, as Microsoft won’t offer assistance for a setup that includes load balancers in the middle of AD traffic.

Takeaway: If your application relies on a load balancer to communicate with AD, it wasn’t built with AD in mind. You’re better off finding or developing applications that natively support Active Directory’s load balancing and fault tolerance features.

Final Thoughts: Let Active Directory Do Its Thing

In conclusion, while it may be tempting to introduce a load balancer into your AD infrastructure, it’s often more trouble than it’s worth. AD has built-in mechanisms like Sites and Services, DNS priorities, and the DCLocator function to handle traffic distribution and fault tolerance. Introducing a load balancer can disrupt TCP communication, Kerberos authentication, SSL/TLS handshakes, and LDAP channel binding, and make troubleshooting account lockouts a nightmare. And let’s not forget—if your app needs a load balancer to talk to AD, it’s probably not built with AD best practices in mind.

Call to Action: Have any stories of load balancers causing havoc in your AD environment? Drop them in the comments below, or feel free to reach out for help optimizing your AD infrastructure. Let’s keep it simple—let AD do the job it was designed to do!

Master in Progress IT blog