Microsoft stellt Domaincontroller langsam auf LDAPS um

(Bild: Thannaree Deepul/Shutterstock.com)
Mit einem Update, das später im Jahr für alle unterstützen Versionen von Windows Server erscheinen wird, 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.

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.

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 gelernt hat.

Ausdrücklich nicht betroffen vom Update sind Umgebungen, in denen der Admin die Gruppenrichtlinie konfiguriert und LDAP bewusst aktiviert hat.

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.

Administratoren sollten die Ereignis-IDs 2886 bis 2888 im Auge behalten – sie geben Hinweise darauf, ob ein Client sich per LDAP (ohne "S") verbunden hat.
Administratoren sollten die Ereignis-IDs 2886 bis 2888 im Auge behalten – sie geben Hinweise darauf, ob ein Client sich per LDAP (ohne „S“) verbunden hat.

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. 

Source link

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.