none
Wildcard-Zertifikate auf Domänencontroller? RRS feed

  • Frage

  • Hallo Kollegen,

    wir haben mehrere DC's, eine MS Enterprise PKI (Zertifkatsautoenrollment für die DC's) und einen Citrix Netscaler für Load-Ballancing von LDAP und SLDAP.

    Im Zuge von ADV190023 soll ja LDAP mit Plaintext vermieden bzw. abgeschaltet werden.

    Alternativ steht SLDAP (636) und LDAP mit StartTLS (389) zur Verfügung.

    636 (SLDAP) auf dem Load-Ballancer ist ja kein Problem. Dort stelle am am Netscaler ein Wildcard-Zertifkat ein und alles ist gut.

    Wie Load-Ballancend man den 389 mit StartTLS ? Wenn ich das tue, zeigen die DC's ja mir ihre Zertifkate mit Ihrem Servernamen. Das geht ja nicht. Müssen auf die DC's Wildcard-Zertifkate?

    Oder denke ich falsch?

     



    • Bearbeitet Tango_ball Freitag, 6. November 2020 15:58
    Freitag, 6. November 2020 15:57

Alle Antworten

  • Moin,

    die Requirements für das LDAPS-Zertifikat sind hier: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority Wenig überraschend, muss der Name des DC zumindest im SAN enthalten sein. Sonst wird das Zertifikat nicht gebunden.

    Je nachdem wieviele DCs Du hast, ein Zertifikat ausstellen, das im Subject den LB Namen (ldap.firma.de oder so ähnlich) hat und im SAN alle DCs. Damit sollte das gehen, aber Autoenrollment ist damit natürlich erst mal vom Tisch.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 6. November 2020 18:49
  • Hallo, ich vermute fast dass der Artikel nicht ganz vollständig ist. Mit dem Release von Windows Server 2008 gab es eine neue Zertifikatvorlage "Kerberos Authentication" (link), diese hat eine versteckte Einstellung CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS welche dafür sorgt, dass auch der Domänenname in Form von FQDN und NETBIOS im SAN der DC-Zertifikate auftauchen. IMHO muss das also auch bei manueller Beantragung oder Verwendung von Dritt-CAs berücksichtigt werden. Wenn der LDAP Connect dann auf den Domänennamen geht, sollte das IMHO Zertifikatseitig funktionieren.

    Beste Grüße

    Uwe

    Dienstag, 10. November 2020 11:42
  • Moin,

    hier müssen wir Äpfel und Birnen auseinander halten:

    1. Kerberos-Authentifizierung, die gegen den Realm und nicht gegen einen bestimmten DC geht: Ja, hier ist der Domänennamen wichtig und Pflicht. Da muss aber auch die EKU "KDC Authentication" präsent sein, nicht nur der Domänenname.
    2. LDAPS-Bindung, die gegen einen Load Balancing-FQDN geht, der mit der AD-Domäne nicht zwingend was zu tun haben muss. Das ist normales TLS, hier reicht Server Authentication als EKU und der aufgerufene Name muss präsent sein.

    Aber auch ich weiß natürlich nicht alles... nur, dass es in Dutzenden Umgebungen so seit Jahren funktioniert ;-)


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 10. November 2020 12:10
  • Hast Du auch Erfahrung, ob das (LDAPS/Loadbalancing) sauber mit individuellen Zertifikaten pro DC funktioniert? (wäre ja zu bevorzugen anstatt überall das gleiche einzusetzen)
    Dienstag, 10. November 2020 12:25
  • Hast Du auch Erfahrung, ob das (LDAPS/Loadbalancing) sauber mit individuellen Zertifikaten pro DC funktioniert? (wäre ja zu bevorzugen anstatt überall das gleiche einzusetzen)

    Ja, solange der Loadbalancer eine ausreichende Persistenz aufweist. Das ist aber vom Zertifikat unabhängig.

    Die Zertifikate können aber trotzdem nicht per Autoenrollment ausgestellt werden, weil sie den LB-Namen beinhalten müssen. Können aber dann natürlich per Autoenrollment erneuert werden :-)


    Evgenij Smirnov

    http://evgenij.smirnov.de




    Dienstag, 10. November 2020 12:32