Das Lesen des Heise Artikels “Microsoft stellt Domaincontroller langsam auf LDAPS um” sorgte bei mir kurz für Bluthochdruck. Microsoft erlaubt nach dem Update per Default kein LDAP mehr? Wie kann das sein? Ich dachte, Microsoft Loves OpenSource und strebt seit Jahren nach RFC-konformen Entwicklungen. Es folgt eine Klarstellung.
Begriffsklärung LDAPS
Vorab müssen wir die im oben genannten Artikel fälschlich verwendeten Begriffe LDAP und LDAPS klären. Grundsätzlich handelt es sich bei LDAP um das “Lightweight Directory Access Protocol”. Dieses Protokoll ist aus den 1990er Jahren und ursprünglich für den vereinfachten Zugriff auf X.500 Verzeichnisse gedacht. Es bildet die Grundlage für Microsoft’s Verzeichnisdienst Active Directory (AD), welcher das erste Mal mit der Windows 2000 Server Edition im Jahr 1999 vorgestellt wurde. Seither hat das Protokoll mehrere offizielle Überarbeitungen erfahren.
LDAPS
In LDAPv2 wurde LDAPS, genannt LDAP over SSL, eingeführt. Wikipedia sagt dazu:
A common alternative method of securing LDAP communication is using an SSL tunnel. The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003.[10] Global Catalog is available by default on ports 3268, and 3269 for LDAPS.[11]
LDAP mit TLS
Die aktuelle Version ist LDAPv3 (RCF4511). Diese unterstützt auf Wunsch eine Verschlüsselung auf dem Standard-Port 389 mit Hilfe von STARTTLS. Folglich kann ein LDAP Server ganz problemlos so eingestellt werden, dass er nur TLS-verschlüsselte Verbindungen akzeptiert. Nun ist LDAPS seit 2003 deprecated und es existiert eine Alternative. Warum sollte Microsoft seine Kunden im Jahr 2020 zur Verwendung eines überholten Protokolls zwingen?
Klarstellung
Ich habe mich zu früh aufgeregt. Der Heise Artikel ist gelinde gesagt etwas unscharf. Die anstehenden Updates haben mit LDAPS überhaupt gar nichts zu tun. Wir sprechen von “LDAP channel binding” (CBT) und “LDAP signing”. Zwar ist eine Umstellung auf LDAPS möglich, aber weder notwendig, noch empfehlenswert. Bei der Lösungsfindung hat mir die überall referenzierte offizielle MS Dokumentation nicht wirklich weitergeholfen:
- https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows
- https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
Aber in diesem TechNet-Artikel finden sich Anweisungen für das Vorgehen beim Rollout, inklusive der aktuellen Informationen zu den kommenden Updates.
Zusammenfassend gibt es folgende Kombinationen, um den Anforderungen gerecht zu werden:
| LDAP Authentication | Signing NOT configured | Signing REQUIRED | Port |
| Simple Bind | ? | ? | 389 |
| Simple Bind over SSL/TLS | ? | ? | 636 |
| Unsinged SASL | ? | ? | 389 |
| SASL over SSL/TLS | ? | ? | 636 |
| SASL + Built-in Encryption | ? | ? | 389 |
Die untere Variante ist RFC-konform und auch die von Microsoft angestrebte Zielkonfiguration.
Die nächsten Schritte
Installation des März 2020 Updates
Durch die zahlreichen verunsicherten Meldungen und Reaktionen hat Microsoft den Zeitplan für das Erzwingen der verschlüsselten und signierten Kommunikation bis auf weiteres verschoben. Das im März 2020 erschienene Update CVE-2017-8563 erweitert lediglich das Windows Event Log der Domaincontroller (DC) um einige IDs. Das erleichtert die Suche nach existierenden Systemen (nachfolgend Clients), welche die kommenden Anforderungen nicht erfüllen.
Aktivieren des Auditing
Damit diese Events aufgezeichnet werden, wird über einen Registry Key auf den DCs das Auditing für “LDAP Interface Events” aktiviert:
Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2Analyse der Events
Wer seine Log Daten in Azure Monitor speichert, kann mit der folgenden Query alle relevanten Events abrufen:
Event | where (EventID == 2886 or EventID == 2887 or EventID == 2888 or EventID == 2889 or EventID == 3039 or EventID == 3040 or EventID == 3041)Die Events 2886, 2887, 2888, 3040 und 3041 tauchen dabei alle 24h im Event Log auf. Sie zeigen Zusammenfassungen über den aktuellen Status und allgemein das Vorhandensein von unsignierten Verbindungen. Diese werden bereits ohne Aktivierung des Auditing nach der Installation des Updates angezeigt.
Interessanter sind die Events 2889 für Clients ohne LDAP Signing und 3039 für Clients ohne LDAP Channel Binding (CBT). Eine detaillierte Beschreibung der EventIDs ist dem Microsoft Artikel zu entnehmen: https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows
Ergreifung von Maßnahmen
Die weiteren Maßnahmen richten sich nach den obigen Ergebnissen. Dabei spielen die bereits getroffenen Einstellungen und ganz allgemein der Aufbau des Netzwerks eine Rolle. Die Anpassung der unten genannten Einstellungen haben Auswirkungen auf alle an das AD angebundenen Clients. Unter anderem bedacht werden müssen:
- Windows Server und Clients
- Linux Server und Clients (hier hilft der RedHat Artikel Impact of Microsoft Security Advisory ADV190023)
- Firewall- oder andere Appliances
- Jegliche Software mit separat konfigurierter AD Anbindung (PHP, Java, etc.)
Folgender grober Ablauf ist allgemein gültig:
- Versorgen aller Windows-Server/-Clients mit CVE-2017-8563
- Identifizieren der Clients ohne Signing (EventID 2889) und Anpassung der entsprechenden Konfigurationen. Für Azure Monitor hilft dabei folgende Query:
Event | where EventID == 2889 | parse ParameterXml with '<Param>' Client_IP '</Param><Param>' Client_Account '</Param><Param>' Client_BindingType '</Param>' | extend Client_BindingType = replace(@"0", @"Unsigned SASL bind", Client_BindingType) | extend Client_BindingType = replace(@"1", @"Simple bind", Client_BindingType) | project TimeGenerated, Computer, Client_Account, Client_IP, Client_BindingType | sort by TimeGenerated desc - Setzen der empfohlenen Werte auf den DCs:
- LDAPServerIntegrity = 2 (GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements > Require Signing)
- LdapEnforceChannelBinding = 1 (GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server channel binding token requirements > When Supported”
- Identifizieren der Clients ohne CBT (EventID 3039) und Anpassung der entsprechenden Konfigurationen (diese werden erst nach dem Setzen von LdapEnforceChannelBinding = 1 oder höher angezeigt)
- Setzen von LdapEnforceChannelBinding = 2 (Always)
Fazit
Die Umstellung des Active Directory zur Verwendung von Signing und CBT hat Auswirkungen auf alle angebunden Clients. Folglich sollte sie gründlich geplant und bedacht umgesetzt werden. Wie auch immer, das März 2020 Update erleichtert zwar die Vorbereitung, aber derzeit stehen keine endgültigen Informationen zum Zeitplan von MS zur Verfügung. Dennoch ist der Handlungsbedarf akut, denn sicher ist: Sollten die Einstellungen wie ursprünglich geplant mit einem Update automatisch ausgerollt werden, ist für viele Clients keine Kommunikation mit dem AD mehr möglich.
Nehmen Sie bei weiteren Fragen, Anregungen oder Ideen gerne Kontakt mit uns auf!