HAProxy für Active Directory LDAP

Prinzipiell ist Active Directory auf Redundanz ausgelegt, mehrere Domain Controller sorgen dafür dass immer einer verfügbar ist. AD nutzt hierfür allerdings SRV-DNS-Records, die von Clients die per LDAP auf das Active Directory zugreifen in der Regel nicht beachtet werden. Das hat den Effekt, dass Anwendungen (wenn sie überhaupt die Möglichkeit bieten mehrere LDAP-Server anzugeben) öfter mal stocken wenn der DC der als erstes eingetragen ist nicht erreichbar ist. In der Regel warten sie dann auf einen Timeout bis sie den nächsten DC probieren. Und das bei jeder Abfrage.

Um das zu vermeiden habe ich jetzt zwei Ubuntu-VMs aufgesetzt (16.04, nicht 18.04, siehe den Nachtrag am Ende) auf denen jeweils ein HAProxy läuft, der alle DCs als Backend eingetragen hat. HAProxy verteilt die Zugriffe auf die vorhandenen DCs, sollte einer ausfallen merkt HAProxy das und leitet die Anfragen an einen anderen DC bis der ausgefallene DC wieder da ist. Zwei VMs, da dadurch natürlich der Proxy der Single Point of Failure wird.

Ich habe also:

• dcproxy1, 10.11.12.2
• dcproxy2, 10.11.12.3

Dazu kommt eine virtuelle IP-Adresse, die von keepalived immer auf einer der beiden VMs gehalten wird.

Auf beiden VMs die benötigten Dienste installieren:

sudo apt install keepalived haproxy

Ein SSL-Zertifikat erzeugen und auf beide VMs kopieren. Ich habe dafür /etc/ssl/ gewählt. Hinweis: HAProxy benötigt Zertifikate und Key zusammen in einem bundle file.

sudo cat dcproxy.example.com_cert_with_chain.pem dcproxy.example.com_key.pem |sudo tee dcproxy.example.com_bundle.pem

Die Konfiguration für HAProxy ist auf beiden VMs identisch. So sieht meine /etc/haproxy/haproxy.cfg aus:

global
log /dev/log    local0
log /dev/log    local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
#  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
#  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3
tune.ssl.default-dh-param 2048
defaults
log     global
mode    http
option  httplog
option  dontlognull
timeout connect 5000
timeout client  50000
timeout server  50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend ldap_service_front
mode                  tcp
log                   global
bind                  :389
description           LDAP Service
option                tcplog
option                logasap
option                socket-stats
option                tcpka
timeout client        5s
default_backend       ldap_service_back
backend ldap_service_back
server                ldap-1 dc01.ad.example.com:389 check fall 1 rise 1 inter 2s
server                ldap-2 dc02.ad.example.com:389 check fall 1 rise 1 inter 2s
server                ldap-3 dc03.ad.example.com:389 check fall 1 rise 1 inter 2s
mode                  tcp
balance               source
timeout server        2s
timeout connect       1s
option                tcpka
# https://www.mail-archive.com/haproxy@formilux.org/msg17371.html
option                tcp-check
tcp-check             connect port 389
tcp-check             send-binary 300c0201            # LDAP bind request "<ROOT>" simple
tcp-check             send-binary 01                  # message ID
tcp-check             send-binary 6007                # protocol Op
tcp-check             send-binary 0201                # bind request
tcp-check             send-binary 03                  # LDAP v3
tcp-check             send-binary 04008000            # name, simple authentication
tcp-check             expect binary 0a0100            # bind response + result code: success
tcp-check             send-binary 30050201034200      # unbind request
# LDAPS
frontend ldapS_service_front
mode                  tcp
log                   global
bind                  :636 ssl crt /etc/ssl/dcproxy.example.com_bundle.pem
description           LDAPS Service
option                tcplog
option                logasap
option                socket-stats
option                tcpka
timeout client        5s
default_backend       ldaps_service_back
backend ldaps_service_back
server                ldapS-1 dc01.example.com:636 check fall 1 rise 1 inter 2s verify none check check-ssl ssl
server                ldapS-2 dc02.example.com:636 check fall 1 rise 1 inter 2s verify none check check-ssl ssl
server                ldapS-3 dc03.example.com:636 check fall 1 rise 1 inter 2s verify none check check-ssl ssl
mode                  tcp
balance               source
timeout server        2s
timeout connect       1s
option                tcpka
option                tcp-check
tcp-check             connect port 636 ssl
tcp-check             send-binary 300c0201            # LDAP bind request "<ROOT>" simple
tcp-check             send-binary 01                  # message ID
tcp-check             send-binary 6007                # protocol Op
tcp-check             send-binary 0201                # bind request
tcp-check             send-binary 03                  # LDAP v3
tcp-check             send-binary 04008000            # name, simple authentication
tcp-check             expect binary 0a0100            # bind response + result code: success
tcp-check             send-binary 30050201034200      # unbind request

Als nächstes kommt die Konfiguration von keepalived. Die /etc/keepalived/keepalived.conf auf VM1:

vrrp_instance VI_1 {
state MASTER
interface ens160
virtual_router_id 101
priority 101
advert_int 1
authentication {
auth_type PASS
auth_pass SECRET
}
virtual_ipaddress {
10.11.12.1
}
}

Die Konfiguration auf VM2 ist nahezu identisch:

vrrp_instance VI_1 {
state MASTER
interface ens160
virtual_router_id 101
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass SECRET
}
virtual_ipaddress {
10.11.12.1
}
}

Der einzige Unterschied ist die priority.

Das war es schon. Einmal die Dienste neu starten, dann sollte alles funktionieren:

sudo systemctl restart haproxy
sudo systemctl restart keepalived

Die VM mit der höheren ID bekommt die virtuelle IP. Sollte die VM ausfallen dauert es nach meinen Tests unter 5 Sekunden bis die andere VM die IP bekommt.

Auf den Clients wird jetzt dcproxy.example.com als LDAP-Server eingetragen, was auf die floating IP zeigt. Damit ist immer einer der beiden HAProxys erreichbar.

Im vCenter habe ich noch eine DRS-Regel eingerichtet die dafür sorgt dass die beiden VMs nie auf dem gleichen Host laufen, idealerweise eine in jedem Rechnerraum.

Nachtrag 14.04.2019

Nach einiger Zeit ist ein Problem aufgetreten, und zwar haben die VMs die virtuelle IP-Adresse verloren, aber keiner der beiden keepalived-Instanzen war der Meinung er müsste sie wiederherstellen. War auch kein Wunder, die beiden konnten ja Problemlos miteinander reden und haben kein Problem festgestellt. Nach etwas Recherche habe ich dann herausgefunden dass das Problem aufgetreten ist, wenn ein Systemupdate eingespielt wurde, das den systemd neu gestartet hat. Anscheinend hat dann die Netzwerk-Komponente von systemd die gespeicherte Netzwerkkonfiguration geladen, in der die virtuelle IP-Adresse nicht vorkam, und sie damit entfernt.

Das Problem ist ein bekannter Bug im systemd der bei Ubuntu 18.04 mitgeliefert wird. Er ist zwar behoben, aber die Version in der es behoben ist ist bei Ubuntu 18.04 noch nicht dabei.

Ich habe verschiedenste Checks versucht, um den IP-Verlust mit Sicherheit zu erkennen, damit keepalived sie wieder einrichten kann, aber zu guter Letzt habe ich die VMs mit Ubuntu 16.04 neu aufgesetzt. Seitdem ist das Problem nicht wieder aufgetreten.