Subtellite 0 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 Hallo, Ich befasse mich seit geraumer Zeit mit dem Thema Self-Signed Certifcates und die Umstellung von LDAP auf LDAPS. Ich habe mich vorher nie mit den beiden Themen befasst, also entschuldigt eventuelle Anfängerfragen. Ich habe eine eigene CA in meinem Netzwerk und mehrere Domaincontroller. Die CA (WinServer 2016 DataCenter) dient zur Austellung von eigenen Zertifikaten und die DCs (WinServer 2012 R2 DataCenter) dienen als LDAP-/DHCP-/DNS- und Web-Server. Wenn ich nach dieser (oder ähnlichen) Anleitung gehe: http://terenceluk.blogspot.com/2013/10/configure-ldaps-active-directory-domain.html soll ich auf der CA eine Zertifikatvorlage erstellen, diese veröffentlichen und die veröffentlichte Zertifikatvorlage von den DCs aus anfordern. Das soll ausreichen um LDAPS zu aktivieren. Ich muss allerdings noch mit dem ADSI Editor das Templateschema ändern, damit ich die Vorlage überhaupt veröffentlichen kann (habe ich irgendwo gelesen). Außerdem habe auch irgendwo gelesen das das ganze nicht funktioniert wenn man mehrere Zertifikate auf den DCs hat die Serverauthentifizierung anbieten. Nun habe ich aber auf meinen DCs auch die Zertifikatvorlage für Domaincontrollerauthentifizierung, die schon vorher installiert war. Wozu brauche ich dann eine zweite Vorlage die nur anders heisst? Mit der ldp.exe kann ich auch bestätigen das die Verbindung über den Port 636 (und auch 389) funktioniert (sowohl von DC1 zu DC1 als auch von DC1 zu DC2 zum Bsp.). Auch ein Script (https://evotec.xyz/testing-ldap-and-ldaps-connectivity-with-powershell/) zeigt mir das alle meine DCs bereit sind für LDAPS. Und trotzdem kann ich zum Beispiel von einer Linuxmaschine (ein Testsystem) keine LDAPS Verbindung aufbauen. Mit der Abfrage openssl s_client -showcerts -connect DC1.MEINE.DOMAIN:636 sollte eigentlich das LDAPS Certificat inklusive Certchain angezeigt werden, allerdings ohne Erfolg (Ausgabe lautet unter anderem: write:errno=104 no peer certificate available no client certificate CA names sent ssl handshake has read 0 bytes). Versuche ich das ganze über eine CSR (wie hier beschrieben: https://bl.ocks.org/magnetikonline/0ccdabfec58eb1929c997d22e7341e45) funktioniert es. Aber dann muss ich für jeden Computer im Netzwerk (und für jeden DC?) eine CSR erstellen. Ich habe offensichtlich nicht verstanden wie LDAPS funktioniert und hoffe ihr könnt mir weiter helfen. Zitieren Link zu diesem Kommentar
NorbertFe 2.072 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 vor 15 Minuten schrieb Subtellite: Ich habe eine eigene CA in meinem Netzwerk und mehrere Domaincontroller. Die CA (WinServer 2016 DataCenter) dient zur Austellung von eigenen Zertifikaten und die DCs (WinServer 2012 R2 DataCenter) dienen als LDAP-/DHCP-/DNS- und Web-Server. Ist das eine ad integrierte ca (Enterprise/Unternehmens-ca)? Falls ja sind die richtigen templates ja per default dabei, falls du nicht händisch eingegriffen hast. Lösche mal domänencontroller und domaincontroller-authentication. Dann bleibt nur die Kerberos Vorlage bestehen und deine dcs ziehen sich die automatisch. vor 19 Minuten schrieb Subtellite: Wozu brauche ich dann eine zweite Vorlage die nur anders heisst? Brauchst du nicht. Siehe oben. Nimm die kerberosvorlage. Das ist die aktuellste. Die anderen entfernst du und stellst sie nicht mehr bereit. vor 20 Minuten schrieb Subtellite: Ich muss allerdings noch mit dem ADSI Editor das Templateschema ändern, damit ich die Vorlage überhaupt veröffentlichen kann (habe ich irgendwo gelesen). Nö. vor 20 Minuten schrieb Subtellite: Ich habe offensichtlich nicht verstanden wie LDAPS funktioniert und hoffe ihr könnt mir weiter helfen. Naja die Grundlagen von ca‘s und pki mal eben so lernen ist eben nicht. ein Tipp. Probiere das nicht in der produktivumgebung. Zitieren Link zu diesem Kommentar
testperson 1.718 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 Hi, leicht OT: vor einer Stunde schrieb Subtellite: ... und die DCs (WinServer 2012 R2 DataCenter) dienen als LDAP-/DHCP-/DNS- und Web-Server. deine Domain Controller sind tatsächlich Web-Server? Gruß Jan Zitieren Link zu diesem Kommentar
NorbertFe 2.072 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 vor 49 Minuten schrieb testperson: deine Domain Controller sind tatsächlich Web-Server? Geht doch... Zitieren Link zu diesem Kommentar
cj_berlin 1.334 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 @Subtellite: Da bisher niemand das kommentiert hat, muss ich das nun machen: Zertifikate, die eine private CA ausstellt, sind keine Self-Signed Certs. Self-Signed, wie der Name schon sagt, bedeutet, dass der Subject gleich dem Issuer ist. In einer PKI, egal ob privat oder öffentlich, gibt es in der Regel nur ein Self-Signed Zertifikat: Das der Root CA. 1 Zitieren Link zu diesem Kommentar
Subtellite 0 Geschrieben 28. Dezember 2020 Autor Melden Teilen Geschrieben 28. Dezember 2020 vor 2 Stunden schrieb NorbertFe: Ist das eine ad integrierte ca (Enterprise/Unternehmens-ca)? Falls ja sind die richtigen templates ja per default dabei, falls du nicht händisch eingegriffen hast. Lösche mal domänencontroller und domaincontroller-authentication. Dann bleibt nur die Kerberos Vorlage bestehen und deine dcs ziehen sich die automatisch. Brauchst du nicht. Siehe oben. Nimm die kerberosvorlage. Das ist die aktuellste. Die anderen entfernst du und stellst sie nicht mehr bereit. Nö. Naja die Grundlagen von ca‘s und pki mal eben so lernen ist eben nicht. ein Tipp. Probiere das nicht in der produktivumgebung. Ja das ist eine Enterprise-CA. Ich habe die DC-Auth.-Vorlage gelöscht und dann auch mal wegen dem Templateschema geschaut und tatsächlich musste ich (nicht mehr) mit dem ADSI Editor das Template ändern um die Vorlagen zu veröffentlichen zu können (das musste ich aber, deswegen bin ich über das Templateschema und den ADSI Editor gestolpert). Von einer Windowsmaschine kann ich mir das Zertifikat des DCs anzeigen lassen (mit der openssl abfrage) allerdings nur mit der Fehlermeldung unable to get local issuer certificate und unable to verify the first certificate. Von der Linuxmaschine bekomme ich nur die oben genannte Meldung. Das ich die Grundlagen nicht mal eben so lerne ist mir klar geworden als ich anfing mich damit zu befassen. Ich bin außerdem der neue in der Firma, also seh ich zu das ich die Aufgabe umsetzen kann. Und danke für den Tipp, ich werde mal eine Testumgebung erstellen. vor einer Stunde schrieb testperson: deine Domain Controller sind tatsächlich Web-Server? Grad nochmal geschaut, nein sind sie nicht. Unsere Webserver sind wonders versteckt. Keine warum die Webserver in die Auflistung mit rein gerutscht sind. vor 17 Minuten schrieb cj_berlin: Zertifikate, die eine private CA ausstellt, sind keine Self-Signed Certs. Self-Signed, wie der Name schon sagt, bedeutet, dass der Subject gleich dem Issuer ist. In einer PKI, egal ob privat oder öffentlich, gibt es in der Regel nur ein Self-Signed Zertifikat: Das der Root CA. Das ist auch unser Self-Signed-Certificate. Unsere CA stellt ein SelfSignedCert aus (das Root-Certificate) was als als Anker für alle Clients dient. Die DCs sollen sich dann mit den LDAPS Zertifikaten (mit dem entsprechenden Zertifizierungspfad) ausweisen. Zitieren Link zu diesem Kommentar
NorbertFe 2.072 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 vor 2 Minuten schrieb Subtellite: Das ist auch unser Self-Signed-Certificate. Der Hinweis war, dass du dich nicht mit self signed certificates befaßt, sondern mit einer CA. ;) vor 3 Minuten schrieb Subtellite: Das ich die Grundlagen nicht mal eben so lerne ist mir klar geworden als ich anfing mich damit zu befassen. Ich bin außerdem der neue in der Firma, also seh ich zu das ich die Aufgabe umsetzen kann. Und danke für den Tipp, ich werde mal eine Testumgebung erstellen. Lustig, dass dir als "Neuem" in der Firma das erst jemand sagen muss, dass man sowas nicht am Produktivsystem "testet". Zitieren Link zu diesem Kommentar
Subtellite 0 Geschrieben 28. Dezember 2020 Autor Melden Teilen Geschrieben 28. Dezember 2020 Naja Ich verändere ja nicht wirklich etwas. Ich erstelle Zertifikate (bzw. deren vorlagen) die ich auch wieder lösche wenn es nicht funktioniert. Da ist die Testumgebng für mich nicht notwendig gewesen. Meine "Testumgebung" war tatsächlich nur eine Linuxkiste mit der ich mich austoben konnte. Alles andere in der Domäne bzw. an den DCs oder der CA wurde ja nicht verändert. Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 vor 3 Stunden schrieb Subtellite: Und trotzdem kann ich zum Beispiel von einer Linuxmaschine (ein Testsystem) keine LDAPS Verbindung aufbauen. Mit der Abfrage openssl s_client -showcerts -connect DC1.MEINE.DOMAIN:636 sollte eigentlich das LDAPS Certificat inklusive Certchain angezeigt werden, allerdings ohne Erfolg (Ausgabe lautet unter anderem: write:errno=104 no peer certificate available no client certificate CA names sent ssl handshake has read 0 bytes). Dein Linux muß der kompletten Zertifkatskette vertrauen. Tut es das? Also ist das Root-Cert und ggf. alle Intermediate CAs auf dem Linux (OpenSSL vermutlich?) als vetrauenswürdig hinterlegt? Zitieren Link zu diesem Kommentar
NorbertFe 2.072 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 vor 56 Minuten schrieb Subtellite: Naja Ich verändere ja nicht wirklich etwas. Doch. Oder wie stellst du dir eine ad integrierte ca so vor? vor 57 Minuten schrieb Subtellite: Alles andere in der Domäne bzw. an den DCs oder der CA wurde ja nicht verändert. Ach die ca war schon da? Zitieren Link zu diesem Kommentar
Subtellite 0 Geschrieben 28. Dezember 2020 Autor Melden Teilen Geschrieben 28. Dezember 2020 Ja die CA war schon vor mir da. Ich habe keine DC oder irgendwelche Server (DHCP/DNS oder ähnliches) hinzugefügt oder entfernt. Ich habe tatsächlich nur die LDAPS Zertifikate hinzugefügt oder entfernt. Das klang ja auch so einfach, weshalb ich auf eine komplette Testlandschaft verzichtet habe. Das aktuelle Netzwerk läuft ja schon über LDAP und soll auf LDAPS umgestellt werden. Zitieren Link zu diesem Kommentar
NorbertFe 2.072 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 Sobald die dcs ein Zertifikat haben läuft Windowsseitig alles auch per tls oder ldaps. Den Hinweis von @daabm berücksichtigt? Wenn der LDAP Client keine Funktion zum ignorieren der zertifimatskette hat, muss er dem Root zerr vertrauen. Manche wollen auch noch korrekt die crl erreichen können. Zitieren Link zu diesem Kommentar
Subtellite 0 Geschrieben 28. Dezember 2020 Autor Melden Teilen Geschrieben 28. Dezember 2020 vor 41 Minuten schrieb daabm: Dein Linux muß der kompletten Zertifkatskette vertrauen. Tut es das? Also ist das Root-Cert und ggf. alle Intermediate CAs auf dem Linux (OpenSSL vermutlich?) als vetrauenswürdig hinterlegt? Ich sage mal vorsichtig ja, das tut die Linuxkiste. Da ich nur das Root-Cert und die LDAPS-Certs habe und alle drei in den Trusted Store geladen habe sollte die Linuxkiste der Certchain vertrauen. Also Root-CA -> Domaincontroller -> Clients Zitieren Link zu diesem Kommentar
NorbertFe 2.072 Geschrieben 28. Dezember 2020 Melden Teilen Geschrieben 28. Dezember 2020 vor 23 Minuten schrieb Subtellite: die LDAPS-Certs Wozu? Die liefert der ldapserver doch sowieso bei der Verbindung. :/ Zitieren Link zu diesem Kommentar
Subtellite 0 Geschrieben 28. Dezember 2020 Autor Melden Teilen Geschrieben 28. Dezember 2020 Ja genau und trotzdem funktioniert es nicht. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.