Ausgangslage: LDAP funktioniert oft länger unsicher als geplant

Viele Active-Directory-Umgebungen haben über Jahre Anwendungen angebunden, die "LDAP" sagen, aber sehr unterschiedliche Dinge tun: Kerberos- oder NTLM-basierte Bindings, anonyme Suchanfragen, einfache Bindings mit Benutzername und Passwort, globale Katalogabfragen, hart konfigurierte Domain Controller oder Bibliotheken, die Zertifikatsfehler still ignorieren.

LDAPS adressiert nur einen Teil dieses Problems: den Transport über TLS, typischerweise auf Port 636 für LDAP und 3269 für den Global Catalog. Das ist wichtig, aber es ist kein Ersatz für LDAP Signing, Channel Binding, saubere Servicekonten oder eine bereinigte Applikationslandschaft. Wer nur Port 636 öffnet und den Rest laufen lässt, hat selten ein belastbares Zielbild erreicht.

Die praktische Herausforderung liegt meistens nicht am Domain Controller. Sobald ein passendes Zertifikat vorhanden ist, kann ein DC LDAPS bereitstellen. Der schwierige Teil ist der Bestand: Welche Systeme sprechen LDAP? Welche nutzen einfache Bindings? Welche vertrauen der internen CA nicht? Welche prüfen Hostnamen nicht korrekt? Und welche Anwendung fällt bei Zertifikatsproblemen still zurück auf unverschlüsseltes LDAP?

Zielbild: TLS ist der Normalfall, Fallbacks sind begründet

Ein brauchbarer Zielzustand ist konkret:

  1. Jeder Domain Controller hat ein individuelles, gültiges Serverzertifikat. Die Zertifikate enthalten passende DNS-Namen, eine vertrauenswürdige Kette, Server-Authentication-Eignung und automatisierte Erneuerung.
  2. LDAP-Clients validieren Zertifikate vollständig. Trust Chain, Hostname, Gültigkeit und Sperrstatus werden geprüft; Zertifikatsfehler werden nicht per Option abgeschaltet.
  3. Applikationen nutzen LDAPS oder signierte/sealed LDAP-Verbindungen bewusst. Einfache Bindings über Klartext-LDAP sind nicht mehr der Normalzustand.
  4. Global-Catalog-Abfragen sind getrennt bewertet. Wer 3268 nutzt, muss wissen, ob 3269 erforderlich ist und welche Anwendungen wirklich domänenübergreifend suchen.
  5. Port 389 bleibt nicht blind offen für alles. Klassischer LDAP-Verkehr wird nach Zweck, Clientnetz und Bind-Typ bewertet, statt pauschal geblockt oder pauschal akzeptiert zu werden.
  6. Zertifikatsbetrieb ist überwacht. Ablauf, Autoenrollment, CRL/AIA-Erreichbarkeit und Schannel-Fehler sind sichtbar.

Das Ziel ist nicht "alles muss LDAPS heißen". Das Ziel ist, sensible LDAP-Bindings und Suchpfade so zu betreiben, dass Credentials nicht im Klartext übertragbar sind und Clients wirklich mit dem erwarteten Domain Controller sprechen.

Umsetzung: erst Zertifikatsbasis, dann Client-Migration

1) LDAP-Verkehr und einfache Bindings inventarisieren

Vor der technischen Umstellung braucht es eine Liste der Abhängigkeiten. Starte mit Domain Controllern, Firewall-Logs, Load-Balancer-Logs, Applikationsdokumentation und Windows-Events.

Typische Fragen:

  • Welche Quell-IP spricht mit Domain Controllern auf 389, 636, 3268 oder 3269?
  • Welche Anwendungen nutzen einfache Bindings mit Benutzername und Passwort?
  • Welche Systeme verwenden hart codierte DC-Namen statt DNS- oder Servicekonzepte?
  • Gibt es Appliances, Scanner, IAM-Systeme, VPN-Gateways, Drucksysteme oder Webanwendungen mit eigener LDAP-Bibliothek?
  • Gibt es externe Standorte oder DMZ-Segmente, die nur einzelne DCs erreichen dürfen?

Auf Domain Controllern helfen LDAP-Interface-Events und Netzwerkdaten, aber sie ersetzen keine Applikationsprüfung. Besonders alte Java-, PHP-, Netzwerk- und Identity-Produkte haben oft eigene TLS-Truststores. Dort scheitert LDAPS nicht am AD, sondern am fehlenden CA-Import oder an falscher Hostnamenprüfung.

2) Domain-Controller-Zertifikate sauber ausrollen

Für LDAPS braucht jeder Domain Controller ein geeignetes Zertifikat im lokalen Computer-Zertifikatsspeicher. In Microsoft-zentrischen Umgebungen ist AD CS mit Autoenrollment meist der sauberste Weg.

Wichtige Anforderungen:

  • private Schlüssel pro Domain Controller, nicht ein gemeinsames Zertifikat für alle DCs,
  • Server-Authentication-Eignung,
  • DNS-Namen, die Clients tatsächlich verwenden, insbesondere der FQDN des DCs,
  • moderne Signatur- und Schlüssellängen,
  • vertrauenswürdige Root- und Intermediate-CA auf allen LDAP-Clients,
  • erreichbare CRL- und AIA-Pfade,
  • automatische Erneuerung vor Ablauf.

Vermeide Sonderlösungen wie manuell importierte PFX-Dateien ohne Erneuerungspfad, selbstsignierte Zertifikate, Wildcards oder Zertifikate, deren Namen nur zufällig zu einem Alias passen. LDAPS lebt von korrekter Serverauthentifizierung. Wenn Clients später Zertifikatsprüfung deaktivieren müssen, ist das Ziel verfehlt.

3) LDAPS auf jedem DC technisch validieren

Nach dem Rollout reicht ein einfacher Porttest nicht aus. Test-NetConnection zeigt nur, ob 636 erreichbar ist. Relevant ist, ob der TLS-Handshake mit dem erwarteten Namen, der richtigen Kette und einem akzeptierten Zertifikat funktioniert.

Ein pragmatischer Windows-Test ist:

$server = 'dc01.corp.example'
$client = [Net.Sockets.TcpClient]::new()
$client.Connect($server, 636)

$stream = [Net.Security.SslStream]::new(
  $client.GetStream(),
  $false,
  { param($sender, $cert, $chain, $errors) $errors -eq [Net.Security.SslPolicyErrors]::None }
)

$stream.AuthenticateAsClient($server)
[pscustomobject]@{
  Server      = $server
  Protocol    = $stream.SslProtocol
  Cipher      = $stream.NegotiatedCipherSuite
  Certificate = $stream.RemoteCertificate.Subject
}

$stream.Dispose()
$client.Dispose()

Der Test soll nicht Credentials prüfen, sondern die Transportbasis. Danach folgen Applikationstests mit den echten LDAP-Bibliotheken. Genau dort fallen falsch gepflegte Truststores, kurze Hostnamen, IP-Zugriffe oder deaktivierte Zertifikatsprüfung auf.

4) Anwendungen kontrolliert migrieren

Für jede Anwendung sollte dokumentiert werden:

  • genutzter LDAP-Zweck: Authentifizierung, Gruppensuche, Adressbuch, Provisionierung oder Health Check,
  • Zielport: 636 für LDAP oder 3269 für Global Catalog,
  • verwendeter Name: FQDN statt IP-Adresse,
  • Servicekonto mit minimalen Rechten,
  • TLS-Truststore und Hostnamenprüfung,
  • Timeout- und Failover-Verhalten,
  • Verhalten bei Zertifikatsablauf oder DC-Wechsel.

Viele Störungen entstehen nicht beim ersten Test, sondern beim Failover. Eine Anwendung funktioniert gegen dc01, scheitert aber gegen dc02, weil Zertifikate, Namen oder Truststores nicht gleich sauber sind. Deshalb müssen alle DCs im vorgesehenen Suchpfad getestet werden, nicht nur der Lieblings-DC der Anwendung.

5) LDAP Signing und Channel Binding nicht ausklammern

LDAPS verschlüsselt den Transport. LDAP Signing und Channel Binding adressieren andere Risiken und sollten nicht aus dem Projekt fallen.

Für AD-Hardening ist die Reihenfolge meistens:

  1. LDAP-Nutzung und einfache Bindings sichtbar machen.
  2. LDAPS und Zertifikatsvalidierung für Anwendungen sauber herstellen.
  3. LDAP Signing und Channel Binding geplant verschärfen.
  4. Unsichere Bindings und unnötige Fallbacks entfernen.
  5. Ausnahmen dokumentieren und zeitlich begrenzen.

Ein häufiger Fehler ist, LDAPS als Freifahrtschein für jede alte Bind-Methode zu behandeln. Wenn ein Produkt nur per einfachem Bind arbeiten kann, reduziert LDAPS das Credential-Transportproblem. Es löst aber nicht automatisch schwache Servicekonten, fehlende MFA an der Anwendung, schlechte Gruppenfilter oder überbreite Leserechte.

6) Netzwerkregeln mit Betriebssicht setzen

Port 389 pauschal auf allen Domain Controllern zu blockieren ist selten ein sauberer erster Schritt. AD nutzt LDAP auch für legitime signierte und authentifizierte Vorgänge. Ein hartes Firewall-Blocken kann Anmeldungen, Richtlinien, Anwendungen oder Monitoring unerwartet treffen.

Sinnvoller ist:

  • Applikationssegmente explizit auf 636 oder 3269 zu migrieren,
  • LDAP-Zugriffe aus nicht benötigten Netzen zu entfernen,
  • DC-Zugriffe auf bekannte Quellsysteme einzugrenzen,
  • Domain-Client- und Server-Kommunikation getrennt von Applikations-LDAP zu betrachten,
  • unsichere einfache Bindings durch Policy, Monitoring und Applikationsänderung zu reduzieren.

Für DMZ-, VPN-, NAC-, PAM- oder IAM-Systeme lohnt sich eine eigene Regelmatrix. Dort ist meist klarer, welche Systeme überhaupt LDAP zu Domain Controllern sprechen dürfen.

Vorteile

  • Schützt Credentials im Transport: Einfache Bindings senden Passwörter nicht mehr über Klartext-LDAP.
  • Stärkt Serverauthentifizierung: Clients können prüfen, ob sie wirklich mit dem erwarteten Domain Controller sprechen.
  • Besserer Betriebsstandard für Anwendungen: LDAP-Abhängigkeiten, Servicekonten, Truststores und Failover werden sichtbar.
  • Gute Basis für weitere LDAP-Härtung: Signing, Channel Binding und spätere Fallback-Reduktion lassen sich belastbarer planen.
  • Auditierbarer Zertifikatsbetrieb: Autoenrollment, Ablaufüberwachung und CA-Vertrauen sind messbare Kontrollen.
  • Weniger Ad-hoc-Ausnahmen: Anwendungen bekommen klare Zielports, Namen und Verantwortliche.

Nachteile und Grenzen

  • Zertifikatsbetrieb wird kritisch: Ablaufende DC-Zertifikate, kaputte Autoenrollment-GPOs oder unerreichbare CRLs können Anwendungen stören.
  • Legacy-Clients fallen auf: Alte Appliances und Bibliotheken unterstützen LDAPS oft nur mit schwacher oder unvollständiger Zertifikatsprüfung.
  • LDAPS ersetzt keine Berechtigungshygiene: Schlechte LDAP-Filter, überprivilegierte Servicekonten und breite Leserechte bleiben eigene Probleme.
  • Port 389 verschwindet nicht automatisch: Signierte LDAP-Nutzung kann weiterhin legitim sein; pauschale Blocks sind riskant.
  • Global Catalog braucht Sonderprüfung: 3269 ist nicht nur "636 mit anderem Port", sondern hängt am Suchumfang und an der Anwendung.
  • Failover wird anspruchsvoller: Jeder DC im Pfad braucht passende Zertifikate und konsistente Erreichbarkeit.

Typische Stolperfallen

  • Nur 636 testen: Ein offener Port beweist keinen gültigen TLS-Handshake und keine saubere Zertifikatsprüfung.
  • Zertifikatsprüfung im Client deaktivieren: Dann bleibt Verschlüsselung, aber Serverauthentifizierung wird faktisch aufgegeben.
  • IP-Adressen statt Namen verwenden: Hostnamenprüfung kann so nicht sauber funktionieren.
  • Nur einen Domain Controller prüfen: Failover auf einen zweiten DC bricht dann im Wartungsfenster oder bei Störung.
  • CRL/AIA-Erreichbarkeit vergessen: Strikte Clients verweigern Verbindungen, wenn Sperrlisten nicht erreichbar sind.
  • LDAPS mit LDAP Signing verwechseln: TLS allein ersetzt nicht alle LDAP-Schutzmechanismen.
  • Public-CA oder Wildcard-Zertifikate reflexartig nutzen: Interne DC-Zertifikate brauchen klare Namen, Erneuerung und kontrollierte private Schlüssel.
  • Applikationsbesitzer zu spät einbinden: LDAP ist oft in Konfigurationen versteckt, die nur das Fachverfahren kennt.

Projekt-Checkliste

  • [ ] LDAP-Ziele, Quellsysteme und Ports 389, 636, 3268, 3269 aus Logs und Applikationsdaten inventarisieren.
  • [ ] Einfache LDAP-Bindings und Anwendungen mit Benutzername/Passwort-Bind identifizieren.
  • [ ] AD-CS-Zertifikatstemplate für Domain Controller prüfen oder sauber erstellen.
  • [ ] Autoenrollment für alle Domain Controller aktivieren und Zertifikatsausstellung verifizieren.
  • [ ] Root-/Intermediate-CA, CRL und AIA aus Sicht relevanter LDAP-Clients testen.
  • [ ] LDAPS-Handshake pro Domain Controller mit FQDN und Zertifikatsvalidierung prüfen.
  • [ ] Applikationen auf 636 oder 3269 migrieren und echte Bibliothekstests durchführen.
  • [ ] Servicekonten, Suchbasen, Gruppenfilter und Rechte im Zuge der Migration bereinigen.
  • [ ] LDAP Signing und Channel Binding als nächsten Härtungsschritt planen.
  • [ ] Netzwerkregeln für Applikationssegmente und DMZ-Systeme gezielt anpassen.
  • [ ] Monitoring für Zertifikatsablauf, Schannel-Fehler und neue unsichere LDAP-Bindings einrichten.
  • [ ] Ausnahmen mit Owner, Begründung, Ablaufdatum und Review-Termin dokumentieren.