none
LDAPS Zertifikat RRS feed

  • Frage

  • Hallo,

    um LDAPS zu verwenden benötigen meine DCs ja ein Computer-Zertifikat.

    Da wir keine CA besitzen stellt sich mir nun die Frage, ob die Domänencontroller von Hause aus schon so ein Zertifikat besitzen, damit Applikationen LDADS nutzen können?

    Dienstag, 10. März 2020 12:20

Antworten

  • Moin,

    nein, tun sie nicht. Du kannst eine CA bauen (tue bitte Dir selbst einen Gefallen und platziere sie *nicht* auf DCs) oder auch Third Party-Zertifikate nutzen, sofern Deine AD-Domäne einen extern auflösbaren Namen besitzt.


    Evgenij Smirnov

    http://evgenij.smirnov.de


    Dienstag, 10. März 2020 13:32
  • Kleine Ergänzung: Bei LDAPs braucht der Client die Root-CA, logisch. Falls das DC-Zertifikat von einer Sub-CA kommt, braucht er auch diese sowie ggf. alle weiteren Zwischen-CAs. Im Gegensatz zu Webservern liefert LDAPs im SSL-Handshake nicht die CA-Kette aus.
    Dienstag, 10. März 2020 14:13
  • Dem kann ich mich nur anschliessen. Es gibt viele Gründe für eine eigene CA. Und Kompliziert ist es in den meisten Fällen (Sonderwünche mal abgesehen) auch nicht.

    Hier ist eine etwas ältere Anleitunf von mir. Ich würde auf die Offline Root CA verzichten, und direkt eine AD Integrierte aufbauen. Am besten auf einen eignen Server. Hier ist eine ältere aber Gültige Anleitung. Ihr müst nur Stamm-Zertifizierungsstelle statt Untergeordnete in der Anleitung auswählen. https://www.infrastrukturhelden.de/microsoft-infrastruktur/microsoft-windows/server/installation-einer-zertifizierungsstelle-unter-windows-server-2012r2-teil-2-erstellen-der-unter-geordneten-ca/

    Was kann man noch mit einer eigenen CA machen? PowerShell Skripte signieren, Windows RM verschlüsseln, interne Webserver Zertifikate ausstellen und vieles mehr.


    Viele Grüße / Kind regards
    Fabian Niesen
    ---
    Infrastrukturhelden.de (German) - Infrastructureheroes.org (English)
    LinkedIn - Xing - Twitter
    #Iwork4Dell - Opinions and Posts are my own
    My post are provided as they are. Usage is on your own risk.
    Please consider to mark this entry as helpful or solution if it helps or solved your issue.

    Mittwoch, 11. März 2020 06:46
  • Moin,

    da das Auslöserthema dieses Threads nicht wirklich neu ist, sondern zwanzig Jahre lang nicht beachtet wurde, war die Anforderung nach interner PKI ja eigentlich schon immer gegeben. Sie wurde einfach nur von vielen erfolgreich wegdiskutiert.

    Eine Enterprise Root CA zu installieren, dauert 10 Minuten und alle Anleitungen für die Vorversionen sind weiterhin gültig. Eine wichtige Frage musst Du dir im Vorfeld stellen: Werden Systeme, die nicht Mitglied im AD sind, Zertifikate aus dieser PKI validieren müssen? Gerade im Kontext von LDAPS dürfte die Antwort nun endgültig "ja" lauten, und das beschert Dir eine wichtige Konfigurationsaufgabe, die oft vergessen wird: Du musst sicherstellen, dass der CRL-Abruf per HTTP zuverlässig funktioniert, denn LDAP werden die Nicht-AD-Mitglieder ja nicht können, wegen fehlender Authentifizierung.

    Somit:

    1. Enterprise Root CA installieren (Rollendienst "Zertifizierungsstelle")
    2. Gleich als Erstes alle Default-Vorlagen rigoros entfernen, bevor die DCs sich schon was gezogen haben (man kann das auch in der INF-datei angeben, dass die Vorlagen gar nicht erst veröffentlicht werden, aber das führt jetzt zu weit)
    3. Danach die CRL-Veröffentlichung umkonfigurieren, so dass HTTP verwendet wird. Bei IIS noch auf "AllowDoubleEscaping" achten!
    4. Vorlage für Domaincontrolle duplizieren, auf aktuelle Version bringen und für Autoenrollment freischalten (Gruppe "Domaincontroller)
    5. In der "Default Domain Controllers Policy" Autoenrollment aktivieren, falls noch nicht geschehen.
    6. GPUPDATE /FORCE auf allen Domain Controllern ausführen
    7. Kontrollieren, dass alle ein Zertifikat erhalten haben.

    Damit kriegen alle Domaincontroller automatisch Zertifikate, und vorerst nur die. 


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 11. März 2020 08:48

Alle Antworten

  • Moin,

    nein, tun sie nicht. Du kannst eine CA bauen (tue bitte Dir selbst einen Gefallen und platziere sie *nicht* auf DCs) oder auch Third Party-Zertifikate nutzen, sofern Deine AD-Domäne einen extern auflösbaren Namen besitzt.


    Evgenij Smirnov

    http://evgenij.smirnov.de


    Dienstag, 10. März 2020 13:32
  • Hallo Evgenij,

    danke für die Antwort

    Bei mir geht es um ein paar Applikationen, die sich über LDAD(s) z.B. die Benutze importieren.
    Wenn es erstmal kein Zertifikat für LDAPS gibt, warum kann man z.B. beim McAfee ePO Server bei der LDAP Anbindung den Haken setzten, SSL verwenden. Das kann dann ja nicht funktionieren (oder sehe ich das falsch). 

    Da wir keine extern auflösbare Domäne haben bleibt uns also nur eine eigene CA zu installieren oder mit z.B. XCA ein Zertifikat zu erstellen, welches die Anforderungen besitzt, und an die LDAPS-Clients (Applikationsserver) zu verteilen, oder?


    Dienstag, 10. März 2020 13:58
  • Wenn es erstmal kein Zertifikat für LDAPS gibt, warum kann man z.B. beim McAfee ePO Server bei der LDAP Anbindung den Haken setzten, SSL verwenden. Das kann dann ja nicht funktionieren (oder sehe ich das falsch). 

    Da wir keine extern auflösbare Domäne haben bleibt uns also nur eine eigene CA zu installieren oder mit z.B. XCA ein Zertifikat zu erstellen, welches die Anforderungen besitzt, und an die LDAPS-Clients (Applikationsserver) zu verteilen, oder?


    Das siehst Du richtig, aber es gibt ja so etwas wie Fallback ;-) Und genau das dürfte der Fall sein - vermutlich nutzt er dann einfach kein SSL.

    An die Clients müsst ihr nicht das Zertifikat, sondern seine Root CA verteilen. Bei einem selbstsignierten Zertifikat ist es freilich dasselbe.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 10. März 2020 14:07
  • Kleine Ergänzung: Bei LDAPs braucht der Client die Root-CA, logisch. Falls das DC-Zertifikat von einer Sub-CA kommt, braucht er auch diese sowie ggf. alle weiteren Zwischen-CAs. Im Gegensatz zu Webservern liefert LDAPs im SSL-Handshake nicht die CA-Kette aus.
    Dienstag, 10. März 2020 14:13
  • Kleine Ergänzung: Bei LDAPs braucht der Client die Root-CA, logisch. Falls das DC-Zertifikat von einer Sub-CA kommt, braucht er auch diese sowie ggf. alle weiteren Zwischen-CAs. Im Gegensatz zu Webservern liefert LDAPs im SSL-Handshake nicht die CA-Kette aus.

    Moin,

    sicher ist sicher, ja. Aber ich habe hier mindestes einen Fall (RedMine auf GNU Linux), wo die Root CA ausgereicht hat und er sich die restliche Kette selbst aus AIA besorgt hat.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 10. März 2020 14:21
  • Dem kann ich mich nur anschliessen. Es gibt viele Gründe für eine eigene CA. Und Kompliziert ist es in den meisten Fällen (Sonderwünche mal abgesehen) auch nicht.

    Hier ist eine etwas ältere Anleitunf von mir. Ich würde auf die Offline Root CA verzichten, und direkt eine AD Integrierte aufbauen. Am besten auf einen eignen Server. Hier ist eine ältere aber Gültige Anleitung. Ihr müst nur Stamm-Zertifizierungsstelle statt Untergeordnete in der Anleitung auswählen. https://www.infrastrukturhelden.de/microsoft-infrastruktur/microsoft-windows/server/installation-einer-zertifizierungsstelle-unter-windows-server-2012r2-teil-2-erstellen-der-unter-geordneten-ca/

    Was kann man noch mit einer eigenen CA machen? PowerShell Skripte signieren, Windows RM verschlüsseln, interne Webserver Zertifikate ausstellen und vieles mehr.


    Viele Grüße / Kind regards
    Fabian Niesen
    ---
    Infrastrukturhelden.de (German) - Infrastructureheroes.org (English)
    LinkedIn - Xing - Twitter
    #Iwork4Dell - Opinions and Posts are my own
    My post are provided as they are. Usage is on your own risk.
    Please consider to mark this entry as helpful or solution if it helps or solved your issue.

    Mittwoch, 11. März 2020 06:46
  • Vielen Dank an alle für die vielen Tipps.

    Und vielen Dank für den Link zur CA Installationsanleitung

    Das mit der eigenen CA habe ich mir auch schon überlegt, der Respekt davor ist/war aber immer zu groß und die Anforderung nicht wirklich gegeben. Das ändert sich nun ein wenig. Ist eine CA auf einem Windows Server 2019 ähnlich zu installieren/konfigurieren wie auf einem Windows Server 2012/R2? 

    Mittwoch, 11. März 2020 07:10
  • Moin,

    da das Auslöserthema dieses Threads nicht wirklich neu ist, sondern zwanzig Jahre lang nicht beachtet wurde, war die Anforderung nach interner PKI ja eigentlich schon immer gegeben. Sie wurde einfach nur von vielen erfolgreich wegdiskutiert.

    Eine Enterprise Root CA zu installieren, dauert 10 Minuten und alle Anleitungen für die Vorversionen sind weiterhin gültig. Eine wichtige Frage musst Du dir im Vorfeld stellen: Werden Systeme, die nicht Mitglied im AD sind, Zertifikate aus dieser PKI validieren müssen? Gerade im Kontext von LDAPS dürfte die Antwort nun endgültig "ja" lauten, und das beschert Dir eine wichtige Konfigurationsaufgabe, die oft vergessen wird: Du musst sicherstellen, dass der CRL-Abruf per HTTP zuverlässig funktioniert, denn LDAP werden die Nicht-AD-Mitglieder ja nicht können, wegen fehlender Authentifizierung.

    Somit:

    1. Enterprise Root CA installieren (Rollendienst "Zertifizierungsstelle")
    2. Gleich als Erstes alle Default-Vorlagen rigoros entfernen, bevor die DCs sich schon was gezogen haben (man kann das auch in der INF-datei angeben, dass die Vorlagen gar nicht erst veröffentlicht werden, aber das führt jetzt zu weit)
    3. Danach die CRL-Veröffentlichung umkonfigurieren, so dass HTTP verwendet wird. Bei IIS noch auf "AllowDoubleEscaping" achten!
    4. Vorlage für Domaincontrolle duplizieren, auf aktuelle Version bringen und für Autoenrollment freischalten (Gruppe "Domaincontroller)
    5. In der "Default Domain Controllers Policy" Autoenrollment aktivieren, falls noch nicht geschehen.
    6. GPUPDATE /FORCE auf allen Domain Controllern ausführen
    7. Kontrollieren, dass alle ein Zertifikat erhalten haben.

    Damit kriegen alle Domaincontroller automatisch Zertifikate, und vorerst nur die. 


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 11. März 2020 08:48