Spätestens seit der Meldung Microsoft stellt Domaincontroller langsam auf LDAPS um bei heise vom 22.02.2020 kam etwas Unruhe auf, das mit einem zukünftigen Windows Update zwingend LDAPS im Active Directory benötigt wird.

Vorausgegangen war seitens Microsoft die Sicherheitsempfehlung ADV190023 | Anweisungen von Microsoft zum Aktivieren von LDAP-Channelbindung und LDAP-Signaturen vom 13.08.2019.

In der Zwischenzeit hat sich die Lage etwas entspannt, teilten die Redmonder doch am 10.03.2020 in einer Aktualisierung der zuvor genannten Empfehlung mit, das man bis auf weiteres keine Änderungen vornehmen wird.

Dennoch lohnt ein Blick auf das Thema LDAP-Signierung, Kanalbindung und LDAPS, geht es doch um die Sicherheit und damit man für etwaige zukünftige Änderungen gewappnet ist.

Konfigurierbar ist das Ganze über eine Gruppenrichtlinie, die ab Werk auf “Nicht konfiguriert” steht und bislang unverschlüsseltes LDAP zulässt. Angedacht war mit dem Update eine neue Voreinstellung anzuwenden, auf die eigenen Bedürfnisse änderbar ist das Ganze dann nach wie vor.

Konkret geht es dabei um die Konfiguration von

Computerkonfiguration - Richtlinien - Windows-Einstellungen - Sicherheitseinstellungen und Lokale Richtlinien - Sicherheitsoptionen - Domänencontroller: Signaturanforderungen für LDAP-Server

in der “Default Domain Controllers Policy”, ab Werk steht diese auf “Nicht konfiguriert”, via Gruppenrichtlinienverwaltung steht “Keine” und “Erforderlich” zur Auswahl. In der Registry sieht die Einstellung wie folgt aus:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters

Der Wert von REG_DWORD ” LDAPServerIntegrity” kann folgende Werte haben:

• 0 – Deaktiviert/Nicht konfiguriert. Der bisherige Standard bzw. bislang die Vorgabe.
• 1 – Aktiviert/Signatur erforderlich.

Wen, wie und was genau es alles treffen würde lässt sich schwer abschätzen, hier ist pro Netzwerk Vorarbeit gefragt. So muss ggf. festgestellt werden, was alles LDAP nutzt, dazu weiter unten mehr. Zu Unterscheiden ist zudem ob man eine Domäne oder Arbeitsgruppe betreibt, letztere ist von der Änderung nicht betroffen.

Was ist mit Domänen-Mitgliedern?

Geht man vom aktuellen Stand, also Windows 8.x Pro/Enterprise und Windows 10 Pro/Enterprise sowie Windows Server 2012 mit und ohne R2 sowie neuer aus, sollte es zu keinen Schwierigkeiten kommen, sofern eine Domänen-weite Zertifikatsinfrastruktur bereits betrieben wird und somit die notwendigen Zertifikate sowie Vertrauen vorhanden ist.

Wird eine Zertifikatsinfrastruktur benötigt?

Gerade in (sehr) kleinen Umgebungen wurde bisher auf eine eigene Zertifikatsinfrastuktur verzichtet. Domänen-Controller stellen auch ohne CA ein eigenes selbst-signiertes Zertifikat aus, das für verschiedene Dinge verwendet wird. Clients vertrauen diesem Zertifikat allerdings nicht!

Man kommt also nicht umhin, eine CA (Rolle “Active Directory-Zertifikatdienste”) zu installieren und zu konfigurieren.

Der Vollständigkeit halber: Alternativ könnte man mit OpenSSL eine CA bauen oder eine externe Zertifizierungstelle verwenden. Dies sprengt allerdrings den Rahmen dieses Beitrags.

Was ist mit Nicht-Domänen-Mitgliedern?

Das können beispielsweise NAS und Drucker sowie Außendienst- und HomeOffice-Computer sein, die häufig kein Domänen-Mitglied sind. Ebenso VPN-Firewall-Router wie beispielsweise pfSense oder Securepoint UTM die die Benutzer gegenüber dem Active Direcoty authentifizieren.

Nicht-Domänen- bzw. Arbeitsgruppen-Computer melden sich gegenüber einem Windows Server nicht via LDAP an, sondern beim Zugriff auf die Ressource im Rahmen des jeweiligen verwendeten Protokolls. Als Paradebeispiel dient dabei ein Netzlaufwerk, die Anmeldung erfolgt mittels des SMB-Zugriffs, an dieser Stelle ist kein LDAP zwischen Client und Server im Spiel. Bei Remotedesktopverbindungen (RDP) sieht die Sache ähnlich aus.

Explizite LDAP-Zugriffe wie am Beispiel der genannten NAS-, pfSense- oder Securepoint UTM-Zugriffe sind da natürlich anders. Man muss dem jeweiligen Gerät dann das CA- sowie ein Client-Zertifikat zur Verfügung stellen und einbinden.

LDAP-Clients ermitteln

Bereits der heise-Artikel nennt Möglichkeiten um LDAP-Clients zu ermitteln, zusätzlich kann man beispielsweise mit SmartSniff die Zugriffe auf Port 389 beobachten.

Was tun, wenn LDAP zwingend benötigt wird?

Ideal wäre selbstverständlich wenn unverschlüsseltes LDAP nicht mehr verwendet wird. Ist das aufgrund von Legacy-Anwendungen nicht möglich, kann man dieses über die zuvor genannte Gruppenrichtlinie nach wie vor zulassen und man schränkt parallel dazu die Kommunikation mittels Firewall-Regel auf die betroffenen Geräte ein. Das mag zwar nun nicht das Optimum sein, aber besser als vorher alle Mal.

Wenn möglich kann man zusätzlich die Zugriffe durch ein VPN, stunnel, ssh und ähnliches schützen, damit der Datenverkehr dennoch verschlüsselt ist.

Links:

bl.ocks.org – Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers. (mit OpenSSL)

MS Tech Community – Step by Step Guide to Setup LDAPS on Windows Server (mit AD LDS)

MS Support – Aktivieren von LDAP über SSL mit einer Fremdanbieter-Zertifizierungsstelle

Microsoft Support – 2020 LDAP channel binding and LDAP signing requirements for Windows

Windows: Automatische Zertifikatverteilung (Certificate Autoenrollment) einrichten

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.