Ich habe einen DC, der unter Windows Server 2019 läuft und auf dem die Rolle „Domänendienste“ installiert ist. Ich habe eine mehrstufige Zertifizierungsstelle in derselben Domäne mit der Rolle „AD CS“ eingerichtet (Root ausgeschaltet, Intermediate ausgeschaltet, Issuer eingeschaltet und Domänenmitglied).
Ich habe Probleme, Drittanbieter-Clients (also nicht in die Domäne eingebundene Rechner und/oder Webanwendungen) über LDAPS/636 zum BINDEN zu bringen. Sie funktionieren über LDAP/389 einwandfrei und einige funktionieren mit StartTLS, obwohl das nicht immer eine Option ist und ich lieber das richtige LDAPS verwende.
Ich habe ein Zertifikat für den AD-Server generiert und darauf geachtet, seinen FQDN im Betreff des Zertifikats zu verwenden und seinen DNS-Hostnamen und seine IP-Adresse als SANs einzuschließen, um alle Eventualitäten abzudecken. Ich habe außerdem sichergestellt, dass in der Erweiterung „Erweiterte Schlüsselverwendung“ die Option „Serverauthentifizierung“ ausgewählt wurde.
Ich muss dies noch überprüfen, da ich keinen Remotezugriff auf die Umgebung habe, aber nehmen wir an, dass das Zertifikat gemäß der Dokumentation von Microsoft mit dem Schannel CSP generiert wurde. Das Zertifikat ist von der richtigen ausstellenden Zertifizierungsstelle signiert, und die Clients haben die gesamte CA-Kette installiert und können das AD-Zertifikat lokal überprüfen (wenn ich das Zertifikat aus AD exportiere und es auf einen der Clients kopiere).
Hier wird es seltsam: Wenn ich auf den AD-Server gehe, öffne ich ldp.exe, kann ich mich über LDAPS/636 mit SSL verbinden und Host supports SSL, SSL cipher strength = 256 bitses erscheint in der Ausgabe-/Konsolenansicht. Wenn ich jedoch auf einen der Clients gehe – sagen wir, eine Linux-Maschine – und versuche, mich über openssl zu verbinden:
openssl s_client -showcerts -state -connect <AD_FQDN>:636
Ich erhalte kein Zertifikat, sondern stattdessen das hier (aufgrund der Beschaffenheit des Netzwerks musste ich das hier aufschreiben und nicht kopieren/einfügen, es kann also zu kleinen Ungenauigkeiten kommen):
CONNECTED (00000003)
write: errno = 104
---
no peer certificate available
---
No client cert CA names sent
---
SSL handshake has read 0 bytes and written 324 bytes
Verification: OK
---
<snip>
Wenn ich versuche, einen Client so einzurichten, dass er LDAPS zur Authentifizierung verwendet, kann ich ihn tatsächlich noch nicht zum Laufen bringen. Normalerweise sehe ich so etwas wie diesen nicht hilfreichen Fehler: SSL_Certificate error: Connection closed by peerwas meiner Erfahrung nach normalerweise auf ein Problem mit der Zertifikatsüberprüfung/Vertrauenswürdigkeit hinweist (was Sinn machen würde, wenn der Client nicht einmal ein Zertifikat zur Überprüfung erhält). Einige andere Clients sind noch weniger hilfreich und sagen nur „Verbindung zum LDAP-Server fehlgeschlagen“
Der DC hört definitiv auf Port 636 und ich kann mich von den Clients aus extern damit verbinden (also nicht nur über Loopback innerhalb der DC-Maschine), was ich mit netcat überprüft habe.
nc -vz <AD_FQDN> 636
Irgendwelche Ideen, was dieses Problem verursachen könnte?
Antwort1
Es stellte sich heraus, dass unsere Firewall eine Anwendungsüberprüfung durchführte und die SSL-Verbindung unterbrach. Das Deaktivieren der Anwendungsüberprüfung löste meine Probleme.