Active Directory: Loadbalancer davor?
Häufig werde ich bei Kundenterminen gefragt, ob es nicht sinnvoller ist, einen Loadbalancer vor die Domain-Controller zu setzen, um bei Ausfall einer dieser DCs dann automatisch auf einen anderen zu schwenken. Eine echte Erfahrung habe ich in dem Bereich nicht, ich weiß nur, dass es zumindest nicht notwendig ist, denn – sofern möglich – sollten in Systemen bzw. Applikationen niemals die Domain-Controller fest eingetragen werden, sondern immer der Name der Domäne verwendet werden. Dadurch gibt es dann quasi eine Art Loadbalancing automatisch mit. Es gibt Kunden, die das trotzdem machen bzw. für einen Teil der Services, die auf einem DC laufen; bspw. DNS-Dienst.
Bei einer kürzlich durchgeführten Rechnerche zu einem anderen Thema bin ich aber auf den Artikel “Active Directory Hardening Series – Part 3 – Enforcing LDAP Signing – TheWindowsUpdate.com” gestoßen, in dem auch das “Load balancing LDAP” angesprochen wurde. Hier wird auch recht logisch erklärt, warum der LDAP-Dienst besser nicht per Loadbalancer bereitgestellt werden sollte.
Obwohl manche den Einsatz von Load Balancern für LDAP als Best Practice ansehen, führt dies in der Praxis häufig zu eingeschränkter Sicherheit. Folgende Punkte sollten beachtet werden:
- TLS-Offloading:
Wenn der Load Balancer TLS-Verbindungen beendet (Offloading), werden die Daten anschließend unverschlüsselt zwischen dem Load Balancer und dem Domänencontroller übertragen. Dadurch entsteht ein Sicherheitsrisiko. - TLS-Neuaufbau:
Wenn der Load Balancer die TLS-Sitzung beendet und eine neue TLS-Verbindung zum Domänencontroller aufbaut, kann auf dem Domänencontroller LDAP Channel Binding nicht mehr erzwungen werden. Das schwächt die Authentifizierungssicherheit. - Kerberos-Probleme:
Kerberos-Authentifizierung schlägt fehl, wenn ein Alias- oder VIP-Name (Virtual IP) verwendet wird. Der entsprechende SPN (Service Principal Name) kann nämlich nicht mehreren Domänencontrollern zugewiesen werden. Dasselbe Problem tritt auch bei einer Round-Robin-DNS-Konfiguration ohne Load Balancer auf. Weitere Details dazu finden sich in diesem Artikel: Warum Active Directory und Load Balancer nicht gut zusammenpassen. - Einschränkungen bei Anwendungen:
Häufig werden Load Balancer nur eingesetzt, weil eine Anwendung nur einen Zielnamen oder eine IP-Adresse akzeptiert und keine integrierten Mechanismen für Ausfallsicherheit unterstützt (wie sie der DC Locator bietet). Der Load Balancer übernimmt dann das Umschalten auf einen anderen Domänencontroller, wenn eine Verbindung fehlschlägt.
Wird jedoch eine LDAP-Anwendung verwendet, die die DNS-Einträge des DC Locator versteht, ist kein Load Balancer nötig. Diese Methode bietet Redundanz, ohne Kerberos zu beeinträchtigen.
Hier der originale Auszug
Today many organizations use load balancer solutions to distribute LDAP connections across multiple domain controllers. While the use load balancers for LDAP is considered by some as best practice, in reality they often result in reduced security. Here are the concerns to keep in mind:
- If the load balancer is being used for TLS Offloading, the messages are transported over the network in the clear between the load balancer and the domain controller.
- If the load balancer is terminating the TLS session then starting a new TLS session between it and the domain controller, LDAP channel binding cannot be enforced on the domain controller.
- Kerberos will fail when using an alias or VIP name because the matching SPN cannot be added to multiple domain controller computer objects. The same is true when using a robin-round alias configuration without a load balancer. For more details checkout this article on why Active Directory and load balancers don’t mix.
Often load balancers are used when an application only accepts one target name or IP address, and do not support fault tolerant concepts as implemented by DC Locator. The load balancer is then needed to make the new connection to a different domain controller if the current session fails. A load balancer is not needed when LDAP applications understand the DNS records used for dclocator logic. That approach achieves redundancy while not breaking Kerberos.
Darin enthalten sind folgende weiterführende Artikel:
Excellent breakdown, I like it, nice article. I completely agree with the challenges you described.