Microsoft stellt Domaincontroller langsam auf LDAPS um
Microsoft bereitet eine Umstellung auf LDAPS im Active Directory vor. Admins sollten rechtzeitig Einstellungen und Logs prüfen, um Ausfälle zu vermeiden.
(Bild: Thannaree Deepul/Shutterstock.com)
Mit einem Update, das später im Jahr für alle unterstützen Versionen von Windows Server erscheinen sollte und noch einmal verschoben wurde, leitet Microsoft langsam das Ende von unverschlüsselten LDAP-Verbindungen ein. Probleme können Admins bekommen, die die Einstellung bisher nicht gesetzt haben und alte Soft- oder Hardware im Einsatz haben. Um die Fehler rechtzeitig zu vermeiden, hilft ein Blick in die Ereignisanzeige.
[Update vom 4.6. um 14:50] Microsoft hat die Änderung zum wiederholten Mal verschoben. Wörtlich heißt es in der Anweisung: "Aktualisierungen in absehbarer Zeit nehmen keine Änderungen an LDAP-Signaturen oder Channelbindungsrichtlinien oder den entsprechenden Registrierungswerten auf neuen oder vorhandenen Domänencontrollern vor" Dennoch lohnt es sich, schon rechtzeitig über eine verschlüsselte Variante (LDAPS oder TLS) nachzudenken. [/Update]
Ein Windows-Domaincontroller spricht standardmäßig auch über das Protokoll LDAP über Port 389 unverschlüsselt mit seinen Clients. Dass das auch dann keine gute Idee ist, wenn Server und Client über ein vermeintlich sicheres internes Netz verbunden sind, ist schon seit vielen Jahren kein Geheimnis. Mit Windows-Clients und modernen Softwareprodukten erfolgt der Verkehr bereits über verschlüsseltes LDAPS auf Port 636 oder mit aktiviertem TLS.
Neuer Standard für Gruppenrichtlinie
Wer sein Active Directory nicht weiter konfiguriert hat, erlaubt bisher, dass Clients sich unverschlüsselt mit dem Server verbinden. Das liegt an der Grundeinstellung der Gruppenrichtlinie unter:
Computerkonfiguration/Richtlinien/Windows-Einstellungen, Sicherheitseinstellungen und Lokale Richtlinien/Sicherheitsoptionen/Domänencontroller: Signaturanforderungen für LDAP-Server
Ist sie nicht konfiguriert, erlaubt sie bisher unverschlüsselte LDAP-Verbindungen. Mit dem ursprünglich für März geplanten und jetzt auf die zweite Jahreshälfte verschobenen Update soll sich dieses Verhalten ändern. Wer die Richtlinie bisher auf "Nicht konfiguriert" belassen hat, kann sich dann nicht mehr über LDAP verbinden. Problematisch wird das, wenn man veraltete Soft- oder Hardware im Einsatz hat, die noch kein LDAPS oder TLS auf LDAP gelernt hat.
Ausdrücklich nicht betroffen vom Update sind Umgebungen, in denen der Admin die Gruppenrichtlinie konfiguriert und LDAP bewusst aktiviert hat.
Ereignisanzeige prüfen
Um unangenehme Überraschungen am Patchday zu vermeiden, sollte man möglichst früh die Ereignisanzeige auf allen Domaincontrollern öffnen und einen Filter auf den "Verzeichnisdienst" und die Ereignis-IDs "2886-2888" für die letzten 24 Stunden einrichten.
Ereignisse mit der ID 2887 werden alle 24 Stunden erzeugt, wenn am letzten Tag Clients versucht haben, sich per LDAP zu verbinden. Ist das nicht der Fall, kann man problemlos die oben angegebene Richtlinie einrichten und LDAP abdrehen.
Um herauszufinden, welche Clients noch kein LDAPS sprechen, muss man das Logging-Level erhöhen. Das erledigt man am schnellsten auf einer Kommandozeile mit Admin-Rechten:
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2
Ohne Neustart landen jetzt Ereignisse mit der ID 2889 im Log. Sie verraten IP und Benutzername aller Verbindungsversuche ohne LDAPS. Jetzt kommt man nicht umhin, sich mit diesen Problemfällen zu befassen und LDAPS nachzurüsten.
Nur in absoluten Ausnahmefällen sollten Sie die Richtlinie so konfigurieren, dass LDAP in Zukunft erlaubt bleibt – etwa, wenn eine alte Software in wenigen Monaten ohnehin abgeschaltet wird. Microsoft verweist zu recht, welches Sicherheitsrisiko man sich mit unverschlüsseltem LDAP einhandelt.
[Update vom 22.02. um 10:46] Die Änderung wird noch nicht im März per Update ausgespielt. Microsoft hat den Termin auf ein Update in der zweiten Jahreshälfte 2020 verschoben. Der Fehler ist korrigiert.
[Update vom 02.03. um 08:55] Der Artikel stellt nur die Optionen "unverschlüsseltes LDAP" und "verschlüsseltes LDAPS" gegenüber. Besonders in heterogenen Umgebungen (Windows-AD mit Diensten aus der Linux-Welt) ist SASL (Simple Authentication and Security Layer), auf Port 389 eine weitere Option. Alle Verbindungen auf Port 389 abzulehnen ist dann der falsche Weg. (jam)
