LDAPs ohne Windows CA aktivieren – Microsoft

Seitens Microsoft wird jedem Administrator nahe gelegt, die unsichere Verbindung mittels LDAP in den Ruhestand zu schicken und auf die verschlüsselte Variante LDAPs zu wechseln. Besitzt man innerhalb der Active Directory Domäne eine Certificate Authority (CA), ist das Ausstellen eines Zertifikates für jeden Domain Controller nicht unbedingt aufwendig. Möchte man allerdings ohne Windows CA auskommen, sind einige weitere Schritte notwendig, welche in diesem Artikel näher betrachtet werden.

LDAPs Voraussetzungen

Die Voraussetzungen für eine LDAPs Verbindung sind von Microsoft relativ eindeutig formuliert. Darunter findet man:

• Das Zertifikat muss „Server Authentication“ unterstützen.
• Der FQDN (Full Qualified Domain Name) muss am Zertifikat als Subject-Name als auch als Subject-Alternative-Name definiert sein.
• Das Zertifikat muss von einer CA stammen, welche sowohl der Client als auch der Domain Controller vertrauen.

Soweit zu den wichtigsten Anforderungen an das Zertifikat. Eine genauere Auflistung seitens Microsoft findest du übrigens hier: Microsoft Docs | Enable LDAP over SSL with a third-party certification authority 

How To

CA Zertifikat erstellen

Da ein Zertifikat einer Root-CA eine der Voraussetzungen von Microsoft für das Aktivieren von LDAPs ist und wir keine eigene Windows CA verwenden möchten, müssen wir auf einen Workaround setzen. Dabei kommt uns OpenSSL zur Hilfe. Zwar wird OpenSSL standardmäßig bei Linux Distributionen mit ausgeliefert, es gibt allerdings auch Community Versionen speziell für Windows. Diese können entweder im Self-Installer oder einer bereits kompilierten Version auf der OpenSSL Wiki heruntergeladen werden. Nach dem Entpacken (oder der Installation) können wir mithilfe der Eingabeaufforderung weiterarbeiten.

Zuerst generieren wir uns einen Private Key für unser Root Zertifikat:

openssl genrsa -des3 -out Root_CA.key 4096

Anschließend generieren wir zu dem zuvor erstellten Private Key das entsprechende Zertifikat. Als Gültigkeitsdauer gebe ich 20 Jahre an (kann beliebig variiert werden):

openssl req -new -x509 -days 7300 -key Root_CA.key -out Root_CA.crt

Während dem Erstellvorgang werden weitere Parameter abgefragt. Wichtig ist hierbei, dass als „Common Name“ der Domain Name angegeben wird. Die restlichen Parameter müssen nicht wahrheitsgetreu angegeben werden und können auch übersprungen werden:

Country Name (2 letter code) [AU]:AT
State or Province Name (full name) [Some-State]:Kaernten
Locality Name (eg, city) []:Klagenfurt
Organization Name (eg, company) [Internet Widgits Pty Ltd]:TechblogDE
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:techblog.local
Email Address []:it@techblog.de

CA Zertifikat importieren

Nachdem das Root CA erfolgreich mittels OpenSSL erstellt wurde, muss es anschließend auf allen Domain Controllern im „Trusted Root Certification Authorities Store“ importiert werden. Dazu öffnet man eine MMC, klickt auf „Datei“ -> „Snap-In hinzufügen/entfernen“ -> „Zertifikate“ -> „Computerkonto“ -> „Lokalen Computer“ und ruft das entsprechende MMC Snap-In auf. Diese Schritte müssen wir auf allen verfügbaren DCs wiederholen oder man erstellt für die automatisierte Verteilung eine GPO.

Client Zertifikat erstellen

Nachdem wir nun erfolgreich unser Root Zertifikat erstellt und auf den DCs verteilt haben, müssen wir anschließend für jeden DC ein eigenes Clientzertifikat erstellen. Um einen solchen Prozess zu starten, benötigen wir zuerst ein „Certificate Signing Request“ (CSR) File. Es gibt verschiedene Ansätze, wie man ein solches File generieren lassen kann, wir nehmen dafür das Microsoft Certreq Tool her. Das Certreq Tool generiert aus einem *.inf eine *.csr Datei, das bedeutet, dass wir zuerst das .inf File erstellen müssen. Als Vorlage könnt ihr folgenden Input hernehmen und es mit euren Daten ergänzen:

;----------------- request.inf -----------------

[Version]
Signature= $Windows NT$

[NewRequest]
Subject = "CN=dc01.techblog.local"
KeySpec = 1
KeyLength = 4096
Hashalgorithm = sha256
Exportable = TRUE
FriendlyName = dc01.techblog.local
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xA0; Digital Signature, Key Encipherment

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=dc01.techblog.local&"
_continue_ = "dns=dc01&"
_continue_ = "dns=techblog.local&"

;----------------------------------

Folgende Parameter müssen durch euch ersetzt werden: Subject, FriendlyName, Extensions. Der Rest kann so übernommen und als „dc01.techblog.local.inf“ gespeichert werden. Nun wechseln wir auf den Domain Controller mit dem Hostnamen DC01 und kopieren das zuvor erstelle File auf den Desktop. Anschließend öffnet man eine Eingabeaufforderung und führt am Desktop folgenden Befehl aus:

certreq -new dc01.techblog.local.inf dc01.techblog.local.csr

Mit diesem Befehl wird am Domain Controller ein Private Key und der nötige Certificate Signing Request erstellt. Den .CSR kopieren wir nun wieder auf die Maschine, auf dem wir zuvor das Root CA Zertifikat generiert haben und erstellen noch zusätzlich folgende Datei (dc01.techblog.local_ext.txt):

keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names
[alt_names]
DNS.1 = dc01.techblog.local
DNS.2 = dc01
DNS.3 = techblog.local

Bitte achtet darauf, dass ihr unter den Alternative Names die gleichen Namen aufführt, wie ihr es bereits bei der .INF Datei getan habt. Anschließend können wir das Zertifikat mithilfe von OpenSSL erstellen:

openssl x509 -req -days 3650 -in dc01.techblog.local.csr -CA Root_CA.crt -CAkey Root_CA.key -extfile dc01.techblog.local_ext.txt -set_serial 01 -out dc01.techblog.local.crt

Kopiert nun das Zertifikatsfile „dc01.techblog.local.crt“ auf euren Domain Controller und führt folgenden Befehl in der Eingabeaufforderung aus:

certreq -accept dc01.techblog.local.crt

Wenn der Befehl erfolgreich ausgeführt wurde, solltet ihr das Zertifikat bereits im „Personal Store“ finden können. Anschließend muss der DC einmal neu gestartet werden und wir können die LDAPs Verbindung bereits testen, indem wir „ldp.exe“ auf einem DC ausführen und eine Verbindung via Port 636 und SSL herstellen möchten.

LDAPs ohne DC Neustart

Wird der Domain Controller bereits produktiv verwendet und ein Neustart ist daher nicht möglich, kann man die LDAPs Zertifikate auch mit folgender Methode neu laden.

Dazu erstellt man eine Datei namens „ldap_certreload.txt“ und kopiert folgenden Inhalt in das Textfile:

dn:
changetype: modify
add: renewServerCertificate
renewServerCertificate: 1
-

Anschließend wechselt man in die Eingabeaufforderung und führen folgenden Befehl aus:

ldifde -i -f ldap_certreload.txt

Tritt dabei ein Fehler auf, wurde das Zertifikat nicht richtig erstellt. Meist liegt hier ein Fehler bei den Alternative Names vor.

Fazit

Alle Schritte des Punktes „Client Zertifikat erstellen“ müssen für alle DCs innerhalb der Domäne ausgeführt werden. Wenn das erledigt ist und die Tests mit der LDP.EXE erfolgreich verliefen, kann man Schritt für Schritt die Applikationen auf LDAPs umstellen. Da das Clientzertifikat eine Gültigkeitsdauer von 10 Jahren aufweist, ist man auch relativ lange vor weiteren Änderungen befreit. Wichtig ist hierbei: Das Root Zertifikat und Key dürfen nicht verloren gehen!