Load balancing LDAP from a Domain Controller via F5
I know that load balancing or fail over of LDAP on a Windows domain controller is generally not a good idea due to the Kerberos and SPN issues.
BUT, I have lots of non-windows applications that use LDAP for authentication and authorization. They are just pointed to a single domain controller right now, would be nice to have a VIP and a pool with all my DC's behind it.
So whats the deal here when I see this?:
https://devcentral.f5.com/questions/ad-dcs-behind-f5
Does the F5 do something special? Does it just fall back to NTLM? Or does it just use a simple LDAP bind to AD? (or SLDAP bind).
Whats the best way for non-windows clients to utilize LDAP? Should they just be designed out of the box to use the DNS locator SRV records? Should AD-LDS be deployed and load balance that?
Is there something I am missing?
Solution 1:
Yes, applications who want to interact with Active Directory really should be designed to use proper DC location procedures (which are well documented); unfortunately, quite often they aren't.
You can usually work around this by pointing your LDAP application to the Active Directory domain name instead of a specific DC, because each DC automatically registers AN A record for the domain name pointing to its IP address, so this will work as a DNS round robin; however, this can and will cause two significant issues:
- If a DC is down, it will still be included in the DNS answer; this could cause LDAP failures if the application isn't smart enough to try another one.
- This will not take into any account the Active Directory site topology; if you have a geographically distributed environment, you could end up with an application in London authenticating against a DC in Australia over a slow and/or unreliable WAN link.
A slightly better solution is to create your own DNS record for LDAP applications as a CNAME record pointing to a specific DC, such as ldap.example.com pointing to dc1.example.com, and set a slow TTL on it (f.e. 60 seconds); you can then configure your application to use ldap.example.com for all its LDAP needs. If/when DC1 goes down, you can then remap ldap.example.com to dc2.example.com, and the slow TTL will ensure the application becomes aware of the change as soon as possible, thus minimizing downtime.
In any case, it's really better to avoid load balancing solution, because LDAP is simply not designed to work with them and they could load to any sort of issues.
Solution 2:
Almost all of the non windows LDAP authentication products I've seen are capable of using a DNS entry. Instead of pointing to a specific server you can point to the root of your domain. This should work in the vast majority of situations.
This is teh case because if you do a lookup at the root of your domain e.g. example.com it should come back with all of the IPs of your domain controllers. This allows for standard round robin DNS to take over, without needing any kind of specialised setup.
Solution 3:
One challenge with using a load balancer is, depending on the activity, some applications may request a handle to a DirectoryEntry. The DirectoryEntry includes the server name. This is more common for updates, but may also occur for reads/queries. Obviously you are not going through the load balancer in that case. Would it be good enough for authentication? Maybe.
I have learned that if you make a service available, people may use it for other than what you intend. So that "authentication only" VIP you setup? Maybe someone decides to use it for something else. That is really important. What happens if it blows up?
Another issue is what are the health checks? It isn't uncommon for a domain controller to be up on port 389/636 but not functioning correctly. So a straight up port check may not be good enough.
Traditionally, Active Directory connection resiliency (the DC Locator process) is pushed down to the client. When you start tinkering with it to make it "highly available", you take ownership of issues. And some of those issues may be difficult and elusive to diagnose and resolve. Who will support you? F5? Microsoft? Good luck with that.
Solution 4:
Is this more about high availability or performance?
For performance, I want to highlight this:
I have lots of non-windows applications that use LDAP for authentication and authorization. They are just pointed to a single domain controller right now.
The obvious quick solution here is to point some of your applications at your additional DCs. Of course, this isn't ideal because it leaves applications vulnerable if a DC goes down, but it is any easy way to help spread out your load right away.
For high availability, you can point applications at the domain name or (even better) a cname of the domain name. It's not great, because it means a manual dns adjustment if something goes wrong, but it will make it easier to respond.
You can combine these techniques by using cname records to multiple DCs. The load is spread out, and you can easily adjust a cname record for an individual DC in the event of an outage.
Solution 5:
I have 3 servers in a VIP for that circumstance.
Also, using the domain name is often bad because it will hit the first DC in the list returned, if the application is not site aware (most are not). That could be anywhere in the country and that would be bad for WAN load and latency.