Wichtige Info:
Die vorgesehene Aktualisierung (ADV190023), bezüglich LDAP Signing und Channel Binding für neue und vorhandene Domänen Controllern, geplant für 10. März 2020 wurde in die zweite Hälfte des Kalenderjahres 2020 verschoben. Mit dem März 2020 Update werden nur zusätzliche Auditing Möglichkeiten geschaffen, um die LDAP Systeme zu identifizieren und zu konfigurieren, bevor diese durch das spätere Update keinen Zugriff mehr erlangen.

Das spätere Update bedeutet, dass keine Verbindungen mehr an den Domänen Controller, über unsigned / Clear Text LDAP auf Port 389 durchgeführt werden können. Dann ist es nur noch möglich, entweder LDAPS über Port 636 oder Signed LDAP (StartTLS) auf Port 389 zu verwenden.

Betroffene Domänen Controller Versionen

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP 1
• Windows Server 2008 SP 2

Betroffene LDAP Clients

Die Thematik betrifft natürlich nicht nur unsere Microsoft Umgebung, sondern alle Systeme, die als LDAP Client dienen und LDAP Anfragen versenden. Folgend eine kleine Auflistung der Systeme, die mir eingefallen sind.

• Citrix Gateway
• Citrix AAA
• Citrix LoadBalancer für LDAP
• Citrix Endpoint Management
• VPN (z.B. Sophos)
• Igel UMS Konsole
• Ticket Systeme (z.B. Remedy oder Helpdesk)
• ERP /CRM Systeme (z.B. SAP)
• Datenbank Systeme (z.B. Oracle)
• Webserver (z.B. TomCat oder Apache)
• Security Komponenten (Firewall oder Proxy)
• Backup / Storage Repository

Manche Hersteller, wie z.B. Igel, haben schon reagiert und es ist dort nun möglich über die GUI der UMS Konsole die Verbindung auf LDAPS umzustellen.

Wie kann ich überprüfen, ob unsigned LDAP verwendet wird?

Der erste Schritt um zu prüfen, ob die Umgebung von der Umstellung betroffen ist, besteht darin, die Event Logs auf den Active Directory Server nach den Event IDs 2886, 2887 und 2888 zu durchsuchen. Nach dem Einspielen der März Updates verweisen auch noch die Event IDs 3039, 3040 und 3041 auf ungesicherten LDAP Verkehr. Alle Event IDs sind unter Applications and Services Logs / Directory Service zu finden.

Geprüft wird dies manuell auf allen DCs oder durch das unten eingepflegte Skript, das diese unten genannten manuellen Schritte für euch ausführt.

LDAP signing events

Folgend die Event Logs bezüglich LDAP Signing.

	Description	Trigger
2886	The security of these domain controllers can be significantly improved by configuring the server to enforce validation of LDAP signing.	Triggered every 24 hours, on startup or start of service if the Group Policy is set to None. Minimum Logging Level: 0 or higher
2887	The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.	Triggered every 24 hours when Group Policy is set to None and at least one unprotected bind was completed. Minimum Logging Level: 0 or higher
2888	The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.	Triggered every 24 hours when Group Policy is set to Require Signing and at least one unprotected bind was rejected. Minimum Logging Level: 0 or higher
2889	The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.	Triggered when a client does not use signing for binds on sessions on port 389. Minimum Logging Level: 2 or higher

Wenn auf einem Domänen Controller das Event 2886 vorhanden ist, zeigt dies an, dass signed LDAP von den DCs nicht erzwungen wird und es möglich ist, eine einfache (Clear Text) LDAP Bindung über eine unverschlüsselte Verbindung durchzuführen. Die Security Option „Domain controller: LDAP server signing requirements“ ist dann auf „None“ konfiguriert.

Der nächste Prüfpunkt ist das Event 2887. Diese Event ID tritt alle 24 Stunden auf und meldet, wie viele unsigned und Clear Text Verbindungen zu dem DC aufgetreten sind.

Wenn die Active Directory Server so konfiguriert sind, dass sie unsigned oder einfache LDAP Verbindungen über eine non-SSL/TLS Verbindung ablehnt, protokollieren die Active Directory Server diese Versuche und schreiben alle 24 Stunden eine Zusammenfassung, unter Event ID 2888 ins Event Log.

Änderungen mit März Update

Wichtig:
Die Aktualisierungen am 10. März 2020 ändern weder die Standard Richtlinien für das LDAP Signing oder LDAP Channel Binding auf neuen oder vorhandenen Active Directory Domänen Controllern.

Es fügt nur die folgenden Funktionen hinzu:

• Neue Events werden im Event Log im Zusammenhang mit der LDAP Channel Bindings protokolliert.
• Eine neue GPO Einstellung „Domain controller: LDAP server channel binding token requirements“ zur Konfiguration der LDAP Channel Binding auf unterstützen Geräten. Mögliche Einstellungen wären None, When Supported oder Always. Event ID 3039 wird nur erstellt, wenn diese Einstellung nicht auf None steht.

LDAP Channel Binding events

Folgend die neuen Events, die erst nach dem März Update erscheinen.

Event	Description	Trigger
3039	The following client performed an LDAP bind over SSL/TLS and failed the LDAP channel binding token validation.	Triggered when a client attempts to bind without valid CBT. Minimum logging level: 2 Note Event can only be generated when Channel Binding is set to When Supported or Always
3040	During the previous 24 hour period, # of unprotected LDAPs binds were performed.	Triggered every 24 hours when CBT Group Policy is set to Never and at least one unprotected bind was completed. Minimum logging level: 0
3041	The security of this directory server can be significantly improved by configuring the server to enforce validation of LDAP channel binding tokens.	Triggered every 24 hours, on startup or start of service if the CBT Group Policy is set to Never. Minimum logging level: 0

Aktivierung LDAP Event Diagnostic Logging

Mit den vorher genannten Event IDs erhalten wir nur die Informationen, das wir noch Clear Text LDAP Anfragen an den Domänen Controller erhalten, aber nicht, wer diese sendet. Um dies zu ändern können wir das Log Level auf unseren Domänen Controller erhöhen und sehen so wer die Clear Text LDAP Verbindung angefragt hat (Event ID 2889).

Warnung:
Mit dieser Einstellung kann eine große Anzahl von Ereignissen im Event Log erstellt werden. Hiermit werden auch noch andere LDAP Schnittstellen Fehler protokolliert. Diese können äußerst alarmierend erscheinen, sind es aber nicht, und können normalerweise ignoriert werden. Dennoch sollte diese Diagnosestufe nur für eine sehr kurze Zeitspanne (z.B. 10 Minuten) während der anfänglichen Entdeckungsphase aktiviert werden. Sobald die „lautesten“ Täter identifiziert und beseitigt worden sind, kann die Einstellung jeweils für längere Zeiträume aktiviert werden.

Enable LDAP Event Diagnostic Logging

Kopiert die untere Zeile in eine REG-Datei und führt diese auf dem DC aus. Es ist kein Neustart erforderlich.

Disable LDAP Event Diagnostic Logging

Kopiert die untere Zeile in eine REG-Datei und führt diese auf dem DC aus, um es wieder zu deaktivieren.

Hinweis:
Möglicherweise müssen die doppelten Anführungszeichen nach dem Kopieren und Einfügen ersetzt werden.

Nach der Aktivierung des erweiterten Log Levels wird bei jedem Zugriff über Clear Text LDAP ein Event mit der ID 2889 erstellt (unter Applications and Services Logs / Directory Service) In diesen Events ist protokolliert, welche IP-Adressen und welche Benutzerkonten diese Verbindung aufgebaut haben.

PowerShell Skript zur Prüfung der DCs

Um die Prüfung der Umgebung zu vereinfachen, habe ich die folgenden PowerShell Skripte von Arne Tiedemann an die Microsoft März Updates angepasst.

• Verbindet euch mit einem Domänen Controller
• Geht auf diesen Link und ladet die beiden Skripte herunter
  (Weitere Anweisungen sind in der README.md Datei hinterlegt)
• Startet das Skript ActiveDirectory-DCLDAPEvents.ps1 um eure Domänen Controller nach Event ID 2887 & 3040 zu durchsuchen

• Das Skript erzeugt daraufhin eine CSV-Datei (InsecureLDAPCount.csv) mit den angezeigten Informationen

Es werden nur die Event Einträge gezählt und man erhält erstmal keine weiteren Informationen durch diese Datei!

Um weitere Informationen zu erhalten, wie z.B. Benutzer Account oder IP-Adresse des LDAP Clients, müsst ihr das Skript ActiveDirectory-LDAPInterfaceEventLogging.ps1 ausführen

• Startet das Skript auf dem Domänen Controller

Das Skript erkennt, falls ihr eines der beiden Skripte in den letzten 15 Minuten ausgeführt habt und würde dann nicht nochmal alle DCs nach den bekannten Events durchsuchen.

Es nutzt zur Identifizierung der betroffenen DCs die erstellte InsecureLDAPCount.csv Datei und startet, basierend auf der Liste, das erhöhte Log Level für 30 Minuten auf den DCs. Als Ergebnis erhaltet ihr eine detaillierte Liste für jeden betroffenen DC mit den folgenden Informationen.

DomainController – LDAP Client IP-Address – Port – User – BindType

Falls das erhöhte Log Level keine 30 Minuten laufen soll, kann mit folgenden Parameter der Zeitraum pro Anfrage angepasst werden.

Maßnahmenplan für ADV190023 

1. Installiert die März Windows Updates, wenn diese veröffentlicht sind, auf den Domänen Controllern.
2. Prüft Umgebung Automatisch per Skript Link oder mit folgenden manuellen Schritten
   
   • Konfiguriert das LDAP Event Diagnostic Logging auf 2 oder höher
   • Überwacht das Event Log unter Applications and Services Logs / Directory Service auf allen Domänen Controllern
     • LDAP Signing failure event 2887
     • LDAP Channel Binding failure event 3040
       
       Hinweis:
       Event 3039 kann nur erzeugt werden, wenn Channel Binding auf When Supported oder Always gesetzt ist.
       
3. Identifiziert die Geräte für jede IP-Adresse, die bei Event 2887 (unsigned LDAP) oder Event 3039 (no LDAP Channel Binding) genannt wird.
4. Aktiviert LDAPS auf Domänen Controller (Signed LDAP wird immer angenommen und sollte in der Phase nicht auf Erforderlich gestellt werden)
5. Aktiviert auf den genannten Geräten LDAPS oder Signed LDAP (StartTLS)

Aktivierung LDAPS & Signed LDAP (StartTLS) auf DC

Kurze Anleitung zum Aktivieren von LDAPS & Signed LDAP (StartTLS) auf euren Domänen Controllern.

Methode 1

Die erste Methode ist die einfachste:
Der DC akzeptiert LDAPS & Signed LDAP (StartTLS) automatisch, wenn eine Microsoft Enterprise Root-CA auf einem Domänen Controller installiert ist. Wenn die Active Directory Certificate Services (AD CS) Rolle installiert und die Art der CA Einrichtung auf dem DC als „Enterprise“ angegeben wird, werden alle DCs in der Gesamtstruktur automatisch so konfiguriert, dass sie beides akzeptieren.

Hinweis:
Obwohl es im Allgemeinen eine gute Sache ist, eine CA in der Organisation zu haben, ist die Platzierung auf dem DC insgesamt keine Gute Idee.

Methode 2

In den meisten Fällen wird ein Zertifikat verwendet, wo sich die Root-CA nicht auf einem DC befindet. Daher besteht die zweite Methode dadrin, einfach ein Zertifikat (Server Authentication fähig) auf jedem DC einzupflegen.

Wichtig:
Denkt daran, dass unabhängig davon, welche CA für den Erhalt dieses Zertifikats verwendet wird, sowohl die DCs als auch die Systeme, auf denen die LDAP Client Anwendung läuft, diesem Zertifikat vertrauen müssen.

Hinweis:
Bei einem Windows Server 2008 / R2 / 2012 DC muss das Zertifikat im AD DS Personal Store (NTDS\Personal) importiert werden.
Bei älteren Servern (älter als 2003 R2) muss das Zertifikat in den Computer Personal Store importiert werden.
Bei Windows Server 2016 & 2019 funktionieren beide Methoden.

Voraussetzungen

• Installierte & Aktivierte CA

Veröffentlichung eines passenden Certificate Template

Wir benötigen ein Certificate Template, das sowohl die Server Authentication unterstützt, als auch einen exportierbaren Private Key hat.

• Verbindet euch mit eurem Server der die AD CA Rolle installiert hat.
• Öffnet über Start > Ausführen und dem Befehl certsrv.msc die Zertifikatskonsole

• Erweitert die Anzeige, durch Doppelklick auf den Namen eurer CA
• Klickt nun mit der rechten Maustaste auf Zertifikatvorlagen und dann auf Verwalten

• Klickt in der Konsole für Zertifikatvorlagen, mit der rechten Maustaste auf Webserver und wählt dann Vorlage duplizieren aus

Es muss nicht die Webserver Vorlage verwendet werden. Man kann natürlich auch eine eigene Vorlage erstellen oder eine der vorhandenen anderen Vorlagen verwenden, die die Server Authentifizierung als Zweck hat.

• In dem nun erscheinen Fenster wird das duplizierte Template editiert. Ändert das folgende unter Allgemein
  • Ändert den Template Anzeige Name
  • Ändert die Gültigkeitsdauer und Erneuerungszeitraum an eure Sicherheits Parameter an

• Unter Anforderungsverarbeitung klickt auf Exportieren von privaten Schlüssel zulassen

• Unter Antragstellername wählt DNS-Name und Dienstprinzipalname (SPN) aus

Hinweis:
Wenn das Certificate Template für Wildcards genutzt werden soll, muss hier Supply in the request ausgewählt sein

• Unter Sicherheit klickt auf Add

• Im folgenden Fenster klickt auf Locations…

• Wählt Computers aus und bestätigt dies mit OK

• Gebt eure DCs ein und bestätigt dies mit Check Names und OK

• Klickt unter Sicherheit nun auf eure neu hinzugefügten DCs aus und erweitert die Allow Berechtigungen um Read, Write & Enroll

• Kontrolliert unter Erweiterungen nochmals, dass als Anwendungsrichtlinien auch Server Authentication ausgewählt ist. Bestätigt die Eingaben mit OK.

• Schliesst die Certificate Template Konsole
• Geht wieder in Zertifikatskonsole und klickt mit der rechten Maustaste in den Detail Bereich von Zertifikatvorlagen
• Klickt hier auf Neu und dann auf Auszustellende Zertifikatvorlage

• Im Fenster Zertifikatvorlagen aktivieren wählt das gerade neu erstellte Template (hier Server Authentication) aus und klickt auf OK

Beantragung eines Server Authentication Certificates

Für LDAPS können wir entweder ein SAN-Zertifikat oder ein Wildcard Zertifikat nutzen. Beide Arten von Zertifikaten müssen mit der Berechtigung für Server Authentication erstellt werden. Führt entweder die folgende Anleitung für SAN-Zertifikat oder Wildcard Zertifikat aus.

Beantragung SAN-Zertifikat

• Verbindet euch mit dem ersten DC
• Öffnet dort über Start > Ausführen mit dem Befehl mmc eine Konsole

• In der MMC Konsole klickt auf Datei und auf Snap-In hinzufügen/entfernen

• Im folgenden Fenster wählt auf der linken Seite Zertifikate aus und klickt auf Hinzufügen

• Im Zertifikat Snap-In Fenster wählt Computerkonto aus und klickt auf Weiter

• Unter Computer auswählen wählt Lokalen Computer aus und klickt auf Fertig stellen
• Erweitert die Konsole um die Ordner Zertifikate (Lokaler Computer) > Eigene Zertifikate > Zertifikate
• Klickt mit der rechten Maustaste auf den Ordner und klickt auf Alle Aufgaben und Neues Zertifikat anfordern

• Klickt die ersten beiden Fenster mit Weiter durch
• Im Fenster Zertifikate anfordern wählt euer neu erstelltes Zertifikat Template aus (hier Server Authentication)
• Klickt auf Registrieren

• Wenn die Erstellung erfolgreich war, wird dies unter Status angezeigt. Bestätigt dies mit Finish

• Doppelklickt im Ergebnisbereich auf das neue Zertifikat, um das Dialogfeld für die Zertifikatseigenschaften zu öffnen

• Klickt auf die Registerkarte Details und wählt dort die Option Erweiterte Schlüsselverwendung aus. Prüft das Server Authentication (1.3.6.1.5.5.5.7.3.1) hinzugefügt wurde

Führt diese Schritte für jeden Domänen Controller aus.

Beantragung Wildcard Zertifikat

Wenn vor den Domänen Controllern ein Load Balancer (z.B. Citrix ADC oder DNS-Round Robin) eingesetzt wird, muss nicht jeder DC ein eigenes Zertifikat erhalten. Hierbei benötigt nur der Load Balancer ein Zertifikat (z.B. ldaps.deyda.net oder ein Wildcard Zertifikat), das dann auf allen DCs importiert und akzeptiert wird.

• Verbindet euch mit dem ersten DC
• Öffnet dort über Start > Ausführen mit dem Befehl mmc eine Konsole

• In der MMC Konsole klickt auf Datei und auf Snap-In hinzufügen/entfernen

• Im folgenden Fenster wählt auf der linken Seite Zertifikate aus und klickt auf Hinzufügen

• Im Zertifikat Snap-In Fenster wählt Computerkonto aus und klickt auf Weiter

• Unter Computer auswählen wählt Lokalen Computer aus und klickt auf Fertig stellen
• Erweitert die Konsole um die Ordner Zertifikate (Lokaler Computer) > Eigene Zertifikate > Zertifikate
• Klickt mit der rechten Maustaste auf den Ordner und klickt auf Alle Aufgaben und Neues Zertifikat anfordern

• Klickt die ersten beiden Fenster mit Weiter durch
• Im Fenster Zertifikate anfordern wählt euer neu erstelltes Zertifikat Template aus (hier Server Authentication)
• Klickt auf den Warnhinweis More information is required to enroll for this certificate…
  
  Hinweis:
  Wenn euch diese Warnung nicht angezeigt wird, ist das Certificate Template nicht mit Supply in the request unter Subject Name im Template

• Im Fenster Zertifikat Eigenschaften unter dem Reiter Subject gebt folgendes ein
  • Type (Common name)
  • Value (Eure Domäne für das Wildcard, z.B. *.deyda.local)
• Klickt dann auf Add

• Im Reiter General gebt den Anzeigenamen des Zertifikats unter Friendly name (z.B. *.deyda.local) ein

• Prüft im Reiter Extensions, das sowohl Digital signature & Key encipherment ausgewählt ist

• Prüft im Reiter Private Key, das Make private key exportable markiert ist und bestätigt dies mit OK

• Wenn alle Voraussetzungen ausgefüllt sind klickt auf Enroll

• Wenn die Erstellung erfolgreich war, wird dies unter Status angezeigt. Bestätigt dies mit Finish

• Doppelklickt im Ergebnisbereich auf das neue Zertifikat, um das Dialogfeld für die Zertifikatseigenschaften zu öffnen

• Klickt auf die Registerkarte Details und wählt dort die Option Erweiterte Schlüsselverwendung aus. Prüft das Server Authentication (1.3.6.1.5.5.5.7.3.1) hinzugefügt wurde

Dies muss nur einmal für alle DCs ausgeführt werden.

Exportieren des LDAPS Zertifikats

Die folgenden Schritte zeigen, wie ein LDAPS-fähiges Zertifikat aus dem lokalen Zertifikatsspeicher eines Domänen Controller exportiert werden kann. Die folgenden Schritte gelten für Wildcard und SAN-Zertifikate.

• Verbindet euch mit dem ersten DC
• Öffnet dort über Start > Ausführen mit dem Befehl mmc eine Konsole

• In der MMC Konsole klickt auf Datei und auf Snap-In hinzufügen/entfernen

• Im folgenden Fenster wählt auf der linken Seite Zertifikate aus und klickt auf Hinzufügen

• Im Zertifikat Snap-In Fenster wählt Computerkonto aus und klickt auf Weiter

• Unter Computer auswählen wählt Lokalen Computer aus und klickt auf Fertig stellen
• Erweitert die Konsole um die Ordner Zertifikate (Lokaler Computer) > Eigene Zertifikate > Zertifikate
• Klickt mit der rechten Maustaste auf das vorhin neu erstellte Zertifikat ( hier DC01.deyda.net, man erkennt es an der Spalte Zertifikat Template) und klickt auf Alle Aufgaben und Exportieren

• Klickt auf dem Begrüßungsbildschirm des Zertifikatsexport-Assistenten auf Weiter
• Im Fenster Privaten Schlüssel exportieren wählt Ja, privaten Schlüssel exportieren aus und Bestätigt es mit Weiter.
  • Wenn die Möglichkeit nicht besteht, den privaten Schlüssel zu exportieren, dann wurde das falsche Certificate Template ausgewählt oder es wurde falsch erstellt

• Im Fenster Format der zu exportierenden Datei sollte Alle erweiterten Eigenschaften exportieren ausgewählt werden. Bestätigt dies mit Weiter.
  • Die anderen Auswahlmöglichkeiten sind optional.

• Gebt auf dem Bildschirm Sicherheit ein Passwort ein, das beim Import des Zertifikats verwendet werden soll. Klickt dann auf Weiter.

• Wählt im Fenster Zu exportierende Datei über Durchsuchen einen Pfad aus und definiert einen Dateinamen. Klick dann auf Weiter

• Bestätigt die Einstellungen auf dem Abschlussbildschirm mit einem Klick auf Fertig

• Daraufhin folgt eine Pop-up Meldung, die anzeigt, dass der Export erfolgreich war. Klicken Sie auf OK.

Importieren zur Verwendung mit AD DS

Das Zertifikat muss nun in den Zertifikatsspeicher des Active Directory Domain Services (NTDS\Personal) importiert werden. Dieser Schritt muss für jeden Domänen Controller durchgeführt werden, der LDAPS anbieten soll. Diese Zertifikate müssen manuell erneuert werden, wenn sie ablaufen. Die folgenden Schritte gelten für Wildcard und SAN-Zertifikate.

Hinweis:
Die folgenden Schritte müssen bei Windows Server 2008 / R2 / 2012 DCs durchgeführt werden. Bei Windows Server 2016 & 2019 sind die folgenden Schritte optional.

• Verbindet euch mit dem ersten DC
• Öffnet dort über Start > Ausführen mit dem Befehl mmc eine Konsole

• In der MMC Konsole klickt auf Datei und auf Snap-In hinzufügen/entfernen

• Im folgenden Fenster wählt auf der linken Seite Zertifikate aus und klickt auf Hinzufügen

• Im Zertifikat Snap-In Fenster wählt Dienstkonto aus und klickt auf Weiter

• Unter Computer auswählen wählt Lokalen Computer aus und klickt auf Weiter
• Wählt Active Directory Domain Services aus und bestätigt dies mit Fertig

• Erweitert die Konsole um die Ordner Zertifikate – Dienste (Active Directory Domain Services) > NTDS\Personal
• Klickt mit der rechten Maustaste auf den Ordner NTDS\Personal und klickt auf Alle Aufgaben und Importieren

• Beim Zertifikat Import Wizard Fenster klickt Weiter
• Klickt im Fenster Zu importierende Datei auf die Schaltfläche Durchsuchen und sucht dann die zuvor exportierte Zertifikatsdatei
  • Stellt sicher, dass Personal Information Exchange (pfx,.p12) als Dateityp ausgewählt ist

• Bestätigt die Auswahl mit Weiter

• Gebt im folgenden Fenster Private Key Protection das für das Zertifikat festgelegte Passwort ein und klickt dann auf Weiter

• Stellt auf der Seite Zertifikatspeicher sicher, dass die Option Alle Zertifikate im folgenden Speicher ablegen ausgewählt ist und der Zertifikatspeicher NTDS\Personal lautet. Bestätigt dies mit Weiter

• Bestätigt die Einstellungen auf dem Abschlussbildschirm mit einem klick auf Fertig

• Es sollte dann eine Meldung erscheinen, dass der Import erfolgreich war. Klickt auf OK

• Überprüft den erfolgreichen Import. Klappt den Navigationsbereich unter NTDS\Personal > Zertifikate auf. Hier sollte das importierte Zertifikat zu sehen sein

Überprüfung der Verbindungen

Führt nach der Installation eines Zertifikats die folgenden Schritte aus, um zu überprüfen, ob LDAPS und Signed LDAP (StartTLS) funktioniert.

• Startet das Active Directory Administration Tool (Ldp.exe)
  • Bei nicht Domänen Controllern müssen die Remoteserver-Verwaltungstools installiert werden

• Klickt auf Connection und dann auf Connect

• Gebt den Namen des LDAP Servers (z.B. Domänen Controller oder LDAP Load Balancer) ein, den ihr testen wollt
• Ändert den Port auf 636 und aktiviert das Kästchen SSL um LDAPS zu testen
• Startet den Test mit OK

• Erfolgreiche Verbindung über LDAPS

• Ändert den Port auf 389 und deaktiviert das Kästchen SSL um Signed LDAP (Start TLS) zu testen
• Startet den Test mit OK

• Aufbau der LDAP Verbindung funktioniert

• Klickt nun auf Options > TLS > StartTLS um Signed LDAP (StartTLS) zu starten

• Signed LDAP (StartTLS) konnte Verbindung aufbauen

Check ohne Zertifikat

Zu Testzwecken kann man nochmals das importierte Zertifikat aus dem DC löschen oder sich gegen einen DC ohne Zertifikat verbinden. Dort kann man die gleichen Verbindungen versuchen aufzubauen.

• LDAPS Verbindung (Port 636 SSL) nicht erfolgreich

• LDAP Verbindung (Port 389) funktioniert noch

• Aber der Schwenk auf Signed LDAP (StartTLS) nicht mehr

Citrix ADC konfigurieren

Wie oben schon benannt, ist leider der Citrix ADC mit seinen DC Verbindungen eventuell auch von dem kommenden Change betroffen. Daher hier noch eine kleine Anleitung zum Ändern der benötigten Einstellungen im Citrix ADC.

Voraussetzungen

• Der Domänen Controller hat ein Zertifikat (Server Authentication) für LDAPS oder Signed LDAP (StartTLS) gebunden (z.B. Wildcard Zertifikat)
• Wenn LDAPS eingesetzt werden soll, müssen die betroffenen Firewalls noch angepasst werden (Port Änderung von 389 nach 636)

Authentication LDAPS Server

• Verbindet euch mit der Management IP des betroffenen Systems

• Geht im Navigationsmenü auf System > Authentication > Basic Policies > LDAP

• Wechselt auf den Reiter Servers

• Öffnet euren bestehenden LDAP Server (hier 10.0.0.4_LDAP)

• Ändert den Security Type in SSL, was direkt dazu führt das auch der Port auf 636 geändert wird

• Nun kann man diese Änderung direkt mit Test LDAP Reachability testen. Dies ist unter Connection Settings zu finden

Ein weiterer Vorteil beim Schwenk auf LDAPS ist, das der Benutzer selbstständig sein Passwort ändern kann.

• Aktiviert hierfür unter Other Settings noch den Punkt Allow Password Change

CLI Command

Beispiel:

Authentication Signed LDAP (StartTLS) Server

• Verbindet euch mit der Management IP des betroffenen Systems

• Geht im Navigationsmenü auf System > Authentication > Basic Policies > LDAP

• Wechselt auf den Reiter Servers

• Öffnet euren bestehenden LDAP Server (hier 10.0.0.4_LDAP)

Wenn die Firewalls nicht angepasst werden sollen, kann auch Signed LDAP (StartTLS) im Citrix ADC genutzt werden.

• Ändern den Security Type in TLS, der Port bleibt auf 389

• Nun kann man diese Änderung direkt mit Test LDAP Reachability testen. Dies ist unter Connection Settings zu finden

CLI Command

Beispiel:

Load Balanced LDAPS Server

Als Load Balancing Protocol für LDAPS kann TCP oder SSL_TCP ausgewählt werden. Wegen der höheren Kompatibilität (z.B. zu Linux Appliances) ist SSL_TCP zu empfehlen (SSL Terminierung geschieht auf dem Citrix ADC).

Bei bestehenden LDAP Load Balancing muss folgendes für LDAPS neu erstellt werden:

• Load Balancing Monitor
• Load Balancing Service Groups
• Load Balancing vServer

• Verbindet euch mit der Management IP des betroffenen Systems

Konfiguration LDAPS Monitor

• Geht im Navigationsmenü auf Traffic Management > Load Balancing > Monitors

• Klickt nun auf Add, falls ihr keinen bestehenden LDAPS Monitor habt

• Konfiguriert den neuen Monitor
  • Name (Name des Monitors, z.B. LDAPS)
  • Type (Typ des Monitors, LDAP)
  • Password (Das Passwort des unter Bind DN hinterlegten Service Accounts)
  • Base DN (Domänen Namen in LDAP Format, z.B. dc=deyda, dc=local)
  • Bind DN (Service Account für die Kommunikation mit der AD, z.B. service_ldap@deyda.local)
  • Filter (Einschränkung der Suchergebnisse, cn=builtin)
  • Secure (Aktiviert die Secure Checkbox)
• Bestätigt die Eingabe mit Create

CLI Command

Beispiel:

Konfiguration der LDAPS Service Group

• Geht im Navigationsmenü auf Traffic Management > Load Balancing > Service Groups

• Klickt nun auf Add um eine neue Service Group für LDAPS zu erstellen

• Konfiguriert die neue Service Group für LDAPS
  • Name (Name der Service Group, z.B. LDAPS-svc_group)
  • Protocol (Protokoll, SSL_TCP)
• Bestätigt die Eingabe mit OK

• Klickt im folgenden Fenster auf No Service Group Member, um die bestehenden DCs für LDAPS einzubinden

• Ändert die Server Methode auf Server Based und klickt auf Click to select, wenn bestehende Server eingebunden werden sollen. Wenn neue Server eingebunden werden sollen, klickt auf Add

• Wählt die DCs aus, die für LDAPS konfiguriert sind und fügt diese per Select hinzu

• Konfiguriert den benötigten Port (636) und bestätigt die Eingabe mit Create

• Im folgenden Load Balancing Service Group Fenster, wählt auf der rechten Seite Monitors aus

• Klickt nun auf No Service Group to Monitor Binding, um den vorher erstellten LDAPS Monitor anzubinden

• Wählt nun den Monitor (hier LDAPS) aus und bestätigt dies mit Select

• Bestätigt die Anbindung des Monitors durch Klick auf Bind

• Bestätigt die Eingaben mit Done. Der Effective State muss als Up angezeigt werden.

CLI Command

Beispiel:

Konfiguration der LDAPS virtual Server

• Geht im Navigationsmenü auf Traffic Management > Load Balancing > Virtual Servers

• Klickt nun auf Add um einen neuen Virtual Server für LDAPS zu erstellen

• Konfiguriert den neuen Virtual Server für LDAPS
  • Name (Name des Virtual Servers, z.B. LDAPS-LB)
  • Protocol (Protokoll, SSL_TCP)
  • IP Address Type (IP Address)
  • IP Address (IP Adresse des vServers, z.B. 10.0.0.200)
  • Port (LDAPS Port, 636)
• Bestätigt die Eingabe mit OK

• Klickt im folgenden Fenster auf No Load Balancing Virtual Server ServiceGroup Binding, um die neu erstellte Service Group einzubinden

• Klickt auf Click to select, um in die Auswahlliste der Service Groups zu gelangen

• Wählt die vorher konfigurierte Service Group (LDAPS-svc_group) aus und fügt diese per Select hinzu
• Klickt nach dem hinzufügen auf Continue

• Klickt unter Certificate auf No Server Certificate

• Wählt nun ein passendes Zertifikat für diesen Load Balancer aus. Hier wird ein Wildcard Zertifikat der lokalen Domäne (Wildcard-deyda-local) ausgewählt und mit Select bestätigt

• Klickt nun folgend auf Continue und dann auf Done

CLI Command

Beispiel:

Konfiguration des LDAPS Authentication Servers

• Geht im Navigationsmenü auf System > Authentication > Basic Policies > LDAP

• Wechselt auf den Reiter Servers

• Öffnet den bestehenden LDAP Server (hier 10.0.0.4_LDAP) oder erstellt einen neuen

• Ändert die folgenden Einstellungen des bestehenden Authentication Servers
  • IP Address (IP Adresse des LB vServer, 10.0.0.200)
  • Security Type (Art der Verbindung, SSL)
  • Port (Port der Verbindung, 636)
    
    Dies wird aber automatisch geändert wenn unter Security Type SSL ausgewählt wird.

• Nun kann man diese Änderung direkt mit Test LDAP Reachability testen. Dies ist unter Connection Settings zu finden

Ein weiterer Vorteil beim Schwenk auf LDAPS ist, dass der Benutzer selbstständig sein Passwort ändern kann.

• Aktiviert hierfür unter Other Settings noch den Punkt Allow Password Change

CLI Command

Beispiel:

Load Balanced Signed LDAP (StartTLS)

Wenn die Firewalls nicht angepasst werden sollen, sollte Signed LDAP (StartTLS) im Citrix ADC genutzt werden. Hiefür muss nichts an der Load Balancing Kette geändert werden, da immer noch Port 389 genutzt wird.

• Verbindet euch mit der Management IP des betroffenen Systems

• Geht im Navigationsmenü auf System > Authentication > Basic Policies > LDAP

• Wechselt auf den Reiter Servers

• Öffnet den bestehenden LDAP Server (hier 10.0.0.4_LDAP) oder erstellt einen neuen

• Ändert den Security Type in TLS, der Port bleibt auf 389

• Nun kann man diese Änderung direkt mit Test LDAP Reachability testen. Dies ist unter Connection Settings zu finden

CLI Command

Beispiel: