4
Best Practice LDAPS mit 2 DC und interner MS CA
Hallo,
da das Thema LDAPS ja gerade überall diskutiert wird soll auch in meinem Unternehmen vollständig auf LDAPS umgestellt werden.
Bisher habe ich schon zwei Systeme mit LDAPS angebunden. Einige andere laufen noch mit LDAP.
Ich habe diese Anleitung durchgearbeitet: https://www.der-windows-papst.de/wp-content/uploads/2016/10/LDAP-over-SS ...
Mit einem bisschen Vorwissen über unsere interne MS CA konnte ich somit ganz einfach für beide DCs ein LDAPoverSSL Zertifikat erstellen. Ich habe zuvor auch diverse (nur intern verfügbare) Weboberflächen mit vertrausneswürdigen Zertifikaten versehen damit bei HTTPS Seiten keine Warung beim Enduser auftaucht.
Was mir jetzt erst aufgefallen ist: Obwohl ich bei einem System in den LDAPS Settings nicht den FQDN sondern die IP-Adresse vom DC angegeben hab funktioniert LDAPS einwandfrei.
Würde ich das mit einer HTTPS Webseite machen würde mein Browser meckern dass der Zertifikat nicht mit dem DNS Namen übereinstimmt. (Die nerzige Wanung das Zertifikat sei ungültig).
Also scheint es manchen Systemen egal zu sein wenn das Zertifikat nicht zum FQDN passt?
Bei einer anderen Applikation die LDAPS verwendet musste ich zwingend den korrketen FQDN (wie im Zertifikat) verwenden. (Beim testen mit zB LDAPadmin.exe erhält man auch eine Warnung das der Name nicht passt wenn man direkt die IP vom DC einträgt)
Also so oder so, möchte ich immer den richtigen FQDN einsetzen wenn es geht, auch wenn es nicht immer zwingend nötig ist.
Da kam mir jetzt die Idee, anstatt DC01.my.domain und DC02.my.domain einfach einen neuen statischen DNS Eintrag zu erstellen: LDAP.my.domain.
Sollte ich in Zukunft mal einen neuen DC bekommen und den alten ablösenoder aus andren Gründen müsste ich nicht bei allen Applikationen den LDAP Server anpassen sondern könnte dies zentral im DNS Server erledigen.
Auch bei Systemen die nur eine LDAP Serveradresse akzeptieren könnte ich somit indirekt doch beide DCs verwenden. (RoundRobin)
Also muss ich in meinem LDAP Zertifikat als weitere DNS Namen jetzt auch LDAP.my.domain eintragen. Das kenne ich schon von meinen Webserver Zertfikaten, da habe ich auch für manche Systeme verschiedene FQDNs. (zB SERVER0815.my.domain oder auch APPLIAKTIONSNAME.my.domain).
Wenn ich aber bei der Zertifikatserstellung (ich wollte das LDAP Cert einfach neu erstellen) mehrere DNS Namen eintrage wird das komplett ignoriert. Es wird immer nur automatisch der eigene FQDN eingetragen.
Es gibt einen MS Artikel wie man extra SAN (Subject Alternative Name) hinzufügt aber der ist nur für Server 2003.
Mache ich etwas falsch beider Zertifikatserstelung oder ist mein Vorhaben mit extra DNS Name für LDAP eher unklug? Ich könnte auch einfach dabei bleiben und überall DC01.my.domain oder eben DC02.my.domain eintragen. (Bei manchen Systemen kann man auch mehrere LDAP Server eintrage da wäre das dann schon gut gelöst).
da das Thema LDAPS ja gerade überall diskutiert wird soll auch in meinem Unternehmen vollständig auf LDAPS umgestellt werden.
Bisher habe ich schon zwei Systeme mit LDAPS angebunden. Einige andere laufen noch mit LDAP.
Ich habe diese Anleitung durchgearbeitet: https://www.der-windows-papst.de/wp-content/uploads/2016/10/LDAP-over-SS ...
Mit einem bisschen Vorwissen über unsere interne MS CA konnte ich somit ganz einfach für beide DCs ein LDAPoverSSL Zertifikat erstellen. Ich habe zuvor auch diverse (nur intern verfügbare) Weboberflächen mit vertrausneswürdigen Zertifikaten versehen damit bei HTTPS Seiten keine Warung beim Enduser auftaucht.
Was mir jetzt erst aufgefallen ist: Obwohl ich bei einem System in den LDAPS Settings nicht den FQDN sondern die IP-Adresse vom DC angegeben hab funktioniert LDAPS einwandfrei.
Würde ich das mit einer HTTPS Webseite machen würde mein Browser meckern dass der Zertifikat nicht mit dem DNS Namen übereinstimmt. (Die nerzige Wanung das Zertifikat sei ungültig).
Also scheint es manchen Systemen egal zu sein wenn das Zertifikat nicht zum FQDN passt?
Bei einer anderen Applikation die LDAPS verwendet musste ich zwingend den korrketen FQDN (wie im Zertifikat) verwenden. (Beim testen mit zB LDAPadmin.exe erhält man auch eine Warnung das der Name nicht passt wenn man direkt die IP vom DC einträgt)
Also so oder so, möchte ich immer den richtigen FQDN einsetzen wenn es geht, auch wenn es nicht immer zwingend nötig ist.
Da kam mir jetzt die Idee, anstatt DC01.my.domain und DC02.my.domain einfach einen neuen statischen DNS Eintrag zu erstellen: LDAP.my.domain.
Sollte ich in Zukunft mal einen neuen DC bekommen und den alten ablösenoder aus andren Gründen müsste ich nicht bei allen Applikationen den LDAP Server anpassen sondern könnte dies zentral im DNS Server erledigen.
Auch bei Systemen die nur eine LDAP Serveradresse akzeptieren könnte ich somit indirekt doch beide DCs verwenden. (RoundRobin)
Also muss ich in meinem LDAP Zertifikat als weitere DNS Namen jetzt auch LDAP.my.domain eintragen. Das kenne ich schon von meinen Webserver Zertfikaten, da habe ich auch für manche Systeme verschiedene FQDNs. (zB SERVER0815.my.domain oder auch APPLIAKTIONSNAME.my.domain).
Wenn ich aber bei der Zertifikatserstellung (ich wollte das LDAP Cert einfach neu erstellen) mehrere DNS Namen eintrage wird das komplett ignoriert. Es wird immer nur automatisch der eigene FQDN eingetragen.
Es gibt einen MS Artikel wie man extra SAN (Subject Alternative Name) hinzufügt aber der ist nur für Server 2003.
Mache ich etwas falsch beider Zertifikatserstelung oder ist mein Vorhaben mit extra DNS Name für LDAP eher unklug? Ich könnte auch einfach dabei bleiben und überall DC01.my.domain oder eben DC02.my.domain eintragen. (Bei manchen Systemen kann man auch mehrere LDAP Server eintrage da wäre das dann schon gut gelöst).
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 551345
Url: https://administrator.de/contentid/551345
Printed on: April 24, 2024 at 15:04 o'clock
4 Comments
Latest comment
Hi,
ich weiß gar nicht, warum jetzt so viele bei diesem Thema anschlagen. Ich habe bei uns in der Umgebung überprüft und wir müssen gar nichts machen.
Wir betreiben eine interne Enterprise CA. Alle DC aller Domänen des Forest bekommen seit dem automatisch ein Zertifikat von der Vorlage "Domänencontroller" und dieses wird dann auch immer wieder automatisch verlängert/erneuert. Dieses Zertifikat von dieser Vorlage enthält standardmäßig bereits die "Erweiterte Schlüsselverwendung" "Serverauthentifizierung (1.3.6.1.5.5.7.3.1)". Ich weiß jetzt nicht, warum man ein zweites Zertifikat mit dieser Extension erstellen/importieren sollte. Welchen Sinn sollte das haben?
Ich kann jetzt schon von einem Domain-Member (alle Domänen des Forest) per LDAPS an den DC binden, z.B. mit LDP.exe, "SSL" und Port 636. Ich muss nichts extra dafür tun. Auch nicht das im von Dir verlinkten PDF genannte manuelle Importieren des Zertifikats in den Speicher des Dienstkontos für den AD-Dienst. Warum auch? Wenn die Dienste darauf programmiert sind, sich automatisch ein geeignetes Zertifikat aus dem Zertifikatsspeicher auszuwählen, und kein Zertifikat dafür im Speicher des Kontos haben, unter welchem sie selbst laufen, dann greifen sie auf den Computerspeicher zurück. Das war doch bei den Microsoft Diensten schon immer so, oder?
Und jeder neue DC wird sich dann auch ein eigenes Zertifikat holen. Da brauche ich kein Wildcard-Zertifikat oder eines mit mehreren FQDN, z.B. einem zusätzlichen Alias.
Und wenn ich die Ankündigungen von Microsoft richtig verstanden habe, dann ändert sich da nur etwas hinsichtlich der Standard-Einstellungen:
Nur Windows Clients, welche können, müssen dann auch über LDAPS gehen.
Windows Clients, welche nicht können, z.B. weil das OS (noch) nicht kann, können dann auch weiterhin nicht über LDAPS gehen.
Dritte OS, welche bisher über LDAP gebunden sind, können das auch weiterhin tun.
Das ist doch nichts anderes, als damals, als MS bei NTLM von v1 auf v2 umgeschaltet hat. Man kann v1 abschalten, muss es aber nicht. Und beim Aushandeln wird v2 bevorzugt, wenn beide v2 können. Und irgendwann dann war v1 standardmäßig deaktiviert, konnte aber wieder aktiviert werden.
Genauso sehen ich das hier. Es wird der Standard geändert. Aber keine Funktion abgeschaltet. Mag sein, dass dann bei späteren Versionen/Updates irgendwann mal LDAP ohne SSL standardmäßig abgeschaltet wird. Aber man wird es dann mit Sicherheit wieder aktivieren können, wenn nötig.
Die andere Frage nach dem Alias für die "bequeme" oder "dauerhafte" Konfiguration der diversen LDAP-Anbindungen:
Gesetzt den Fall, dass die betreffende DNS-Zone AD-integriert ist, und keine anderen Nicht-DC dort als Nameserver dafür eingetragen sind, dann kann man bei der Bindung einfach den FQDN der Domäne verwenden, statt den eines DC.
E.
ich weiß gar nicht, warum jetzt so viele bei diesem Thema anschlagen. Ich habe bei uns in der Umgebung überprüft und wir müssen gar nichts machen.
Wir betreiben eine interne Enterprise CA. Alle DC aller Domänen des Forest bekommen seit dem automatisch ein Zertifikat von der Vorlage "Domänencontroller" und dieses wird dann auch immer wieder automatisch verlängert/erneuert. Dieses Zertifikat von dieser Vorlage enthält standardmäßig bereits die "Erweiterte Schlüsselverwendung" "Serverauthentifizierung (1.3.6.1.5.5.7.3.1)". Ich weiß jetzt nicht, warum man ein zweites Zertifikat mit dieser Extension erstellen/importieren sollte. Welchen Sinn sollte das haben?
Ich kann jetzt schon von einem Domain-Member (alle Domänen des Forest) per LDAPS an den DC binden, z.B. mit LDP.exe, "SSL" und Port 636. Ich muss nichts extra dafür tun. Auch nicht das im von Dir verlinkten PDF genannte manuelle Importieren des Zertifikats in den Speicher des Dienstkontos für den AD-Dienst. Warum auch? Wenn die Dienste darauf programmiert sind, sich automatisch ein geeignetes Zertifikat aus dem Zertifikatsspeicher auszuwählen, und kein Zertifikat dafür im Speicher des Kontos haben, unter welchem sie selbst laufen, dann greifen sie auf den Computerspeicher zurück. Das war doch bei den Microsoft Diensten schon immer so, oder?
Und jeder neue DC wird sich dann auch ein eigenes Zertifikat holen. Da brauche ich kein Wildcard-Zertifikat oder eines mit mehreren FQDN, z.B. einem zusätzlichen Alias.
Und wenn ich die Ankündigungen von Microsoft richtig verstanden habe, dann ändert sich da nur etwas hinsichtlich der Standard-Einstellungen:
Nur Windows Clients, welche können, müssen dann auch über LDAPS gehen.
Windows Clients, welche nicht können, z.B. weil das OS (noch) nicht kann, können dann auch weiterhin nicht über LDAPS gehen.
Dritte OS, welche bisher über LDAP gebunden sind, können das auch weiterhin tun.
Das ist doch nichts anderes, als damals, als MS bei NTLM von v1 auf v2 umgeschaltet hat. Man kann v1 abschalten, muss es aber nicht. Und beim Aushandeln wird v2 bevorzugt, wenn beide v2 können. Und irgendwann dann war v1 standardmäßig deaktiviert, konnte aber wieder aktiviert werden.
Genauso sehen ich das hier. Es wird der Standard geändert. Aber keine Funktion abgeschaltet. Mag sein, dass dann bei späteren Versionen/Updates irgendwann mal LDAP ohne SSL standardmäßig abgeschaltet wird. Aber man wird es dann mit Sicherheit wieder aktivieren können, wenn nötig.
Die andere Frage nach dem Alias für die "bequeme" oder "dauerhafte" Konfiguration der diversen LDAP-Anbindungen:
Gesetzt den Fall, dass die betreffende DNS-Zone AD-integriert ist, und keine anderen Nicht-DC dort als Nameserver dafür eingetragen sind, dann kann man bei der Bindung einfach den FQDN der Domäne verwenden, statt den eines DC.
E.
Mir ist bewusst dass sich lediglich die Standardeinstellung ändern wird und man natürlich trotzdem LDAP ohne Verschlüsselung weiterhin genutzt werden kann, wenn man die entsprechende GPO erstellt.
Nur jetzt hat der die entsprechende Person das Thema aufgeschnappt sodass ich nun in dem Zuge gleich mal möglichst alles auf LDAPS umstellen soll. Das habe ich in der Vergangenheit schon teilweise gemacht aber einige Systeme laufen halt immernoch ohne Verschlüsselung. Mir ist auch klar dass die Clients mitspielen müssen, die überprüfe ich alle nach und nach ob und wie man LDAPS einrichtet. Und dabei kam mir die Idee einfach eine extra DNS Adresse für LDAP zu nehmen.
Ich bin mir nicht sicher ob ich weiß was Du meinst.
Wir haben nur eine Domäne, ohne Subdomains oder anderen Standorten. Darin zwei DCs, einer davon ist auch die interne CA. (Ich weiß nicht ob eine "interne Enterprise CA" etwas anderes ist, spielt der Begriff "Enterprise" eine Rolle?).
Die beiden DCs sind auch beide DNS Server. Alle PCs und Server registrieren sich mit Hostname automatisch. Außerdem gibt es zusätzlich einige statische DNS-Namen die wir von Hand gesetzt haben (zB mit dem Applikationsnamen, ganz angenehm für Weboberflächen).
Doofe Frage aber, entspricht das in etwa dem was Du meinst?
Wenn ja, was soll ich dann auf dem Client als LDAP Server angeben wenn mein FQDN vom DC zB DC01.meine.domain lautet ?
Reicht also einfach "meine.domain" aus? Ich habe das eben einfach mal naiv mit einem Ping von meinem Notebook aus getestet, es wird einfach einer der beiden DCs angepingt. (ein kleiner AHA-Effekt!)
Und dass man kein extra Zertifikat braucht war mir nicht bewusst! Ich habe nun die o.g. schöne Schritt-fürSchritt Anleitung durchgearbeitet und war froh dass alles gut geklappt hat. Dass es andere (einfachere) Löungen gibt bzgl. den Zertifikaten war mir nicht bewusst. Ich habe irgendwann mal nach "LDAPS" gegooglet und diese Anleitung gefunden. Dass es anders geht steht dort leider nicht. Ich werde das ganze nochmal neu betrachten müssen!
Nur jetzt hat der die entsprechende Person das Thema aufgeschnappt sodass ich nun in dem Zuge gleich mal möglichst alles auf LDAPS umstellen soll. Das habe ich in der Vergangenheit schon teilweise gemacht aber einige Systeme laufen halt immernoch ohne Verschlüsselung. Mir ist auch klar dass die Clients mitspielen müssen, die überprüfe ich alle nach und nach ob und wie man LDAPS einrichtet. Und dabei kam mir die Idee einfach eine extra DNS Adresse für LDAP zu nehmen.
Zitat von @emeriks:
Die andere Frage nach dem Alias für die "bequeme" oder "dauerhafte" Konfiguration der diversen LDAP-Anbindungen:
Gesetzt den Fall, dass die betreffende DNS-Zone AD-integriert ist, und keine anderen Nicht-DC dort als Nameserver dafür eingetragen sind, dann > kann man bei der Bindung einfach den FQDN der Domäne verwenden, statt den eines DC.
Die andere Frage nach dem Alias für die "bequeme" oder "dauerhafte" Konfiguration der diversen LDAP-Anbindungen:
Gesetzt den Fall, dass die betreffende DNS-Zone AD-integriert ist, und keine anderen Nicht-DC dort als Nameserver dafür eingetragen sind, dann > kann man bei der Bindung einfach den FQDN der Domäne verwenden, statt den eines DC.
Ich bin mir nicht sicher ob ich weiß was Du meinst.
Wir haben nur eine Domäne, ohne Subdomains oder anderen Standorten. Darin zwei DCs, einer davon ist auch die interne CA. (Ich weiß nicht ob eine "interne Enterprise CA" etwas anderes ist, spielt der Begriff "Enterprise" eine Rolle?).
Die beiden DCs sind auch beide DNS Server. Alle PCs und Server registrieren sich mit Hostname automatisch. Außerdem gibt es zusätzlich einige statische DNS-Namen die wir von Hand gesetzt haben (zB mit dem Applikationsnamen, ganz angenehm für Weboberflächen).
Doofe Frage aber, entspricht das in etwa dem was Du meinst?
Wenn ja, was soll ich dann auf dem Client als LDAP Server angeben wenn mein FQDN vom DC zB DC01.meine.domain lautet ?
Reicht also einfach "meine.domain" aus? Ich habe das eben einfach mal naiv mit einem Ping von meinem Notebook aus getestet, es wird einfach einer der beiden DCs angepingt. (ein kleiner AHA-Effekt!)
Und dass man kein extra Zertifikat braucht war mir nicht bewusst! Ich habe nun die o.g. schöne Schritt-fürSchritt Anleitung durchgearbeitet und war froh dass alles gut geklappt hat. Dass es andere (einfachere) Löungen gibt bzgl. den Zertifikaten war mir nicht bewusst. Ich habe irgendwann mal nach "LDAPS" gegooglet und diese Anleitung gefunden. Dass es anders geht steht dort leider nicht. Ich werde das ganze nochmal neu betrachten müssen!
@albzundy
bzgl. FQN
Im Prinzip wie Du schon schreibst. Unter bestimmten Bedingungen.
Hinweis auf "AD integriert" war gemeint, dass in den meisten Umgebungen zu vermuten ist, dass die Zone dann auch auf allen DC's der Domäne repliziert ist und dass auf allen DC's dann auch ein DNS-Dienst läuft. Das muss nicht so sein, aber bei Dir scheint es ja genauso zu sein.
Ein MS-DNS-Server trägt sich für jeder Primär- bzw. AD-integrierte Zone, welche er selbst hostet, automatisch für diese Zone mit einem A-Record ohne Namen ein (mit ihrer eigenen IP-Adresse). Man kann aber darüber hinaus noch andere MS-DNS-Server betreiben (auf Windows Member Computer), welche eine Sekundär-Kopie dieser Zone hosten und auch einen A-Record ohne Namen in dieser Zone haben. Wenn dem so ist, dann kann beim Auflösen des Domänen-FQDN auch ein Server mit einer Sekundär-Zone geliefert werden (wegen Round-Robin), welcher aber kein DC ist und dann natürlich auch keine LDAP-Anfragen an die Domäne beantworten kann. Dann wäre es nicht so gut, bei den LDAP-Bindungen einfach nur den FQDN der Domäne anzugeben.
bzgl. Enterprise CA
Man wird beim Erstellen einer neuen Windows CA gefragt, was man einrichten will: Enterprise oder Standalone.
Bei Enterprise werden die Zertifikatsvorlagen und Root-Retifikate automatisch im AD veröffentlicht. Und noch einiges an Funktionalitäten mehr.
Suche mal im Web z.B. nach "Windows CA Enterprise vs. Standalone", da wirst Du genung Erklärungen finden.
bzgl. FQN
Im Prinzip wie Du schon schreibst. Unter bestimmten Bedingungen.
Hinweis auf "AD integriert" war gemeint, dass in den meisten Umgebungen zu vermuten ist, dass die Zone dann auch auf allen DC's der Domäne repliziert ist und dass auf allen DC's dann auch ein DNS-Dienst läuft. Das muss nicht so sein, aber bei Dir scheint es ja genauso zu sein.
Ein MS-DNS-Server trägt sich für jeder Primär- bzw. AD-integrierte Zone, welche er selbst hostet, automatisch für diese Zone mit einem A-Record ohne Namen ein (mit ihrer eigenen IP-Adresse). Man kann aber darüber hinaus noch andere MS-DNS-Server betreiben (auf Windows Member Computer), welche eine Sekundär-Kopie dieser Zone hosten und auch einen A-Record ohne Namen in dieser Zone haben. Wenn dem so ist, dann kann beim Auflösen des Domänen-FQDN auch ein Server mit einer Sekundär-Zone geliefert werden (wegen Round-Robin), welcher aber kein DC ist und dann natürlich auch keine LDAP-Anfragen an die Domäne beantworten kann. Dann wäre es nicht so gut, bei den LDAP-Bindungen einfach nur den FQDN der Domäne anzugeben.
bzgl. Enterprise CA
Man wird beim Erstellen einer neuen Windows CA gefragt, was man einrichten will: Enterprise oder Standalone.
Bei Enterprise werden die Zertifikatsvorlagen und Root-Retifikate automatisch im AD veröffentlicht. Und noch einiges an Funktionalitäten mehr.
Suche mal im Web z.B. nach "Windows CA Enterprise vs. Standalone", da wirst Du genung Erklärungen finden.
Okay ich verstehe schon etwas besser was du meintest bzgl den DNS Servern bzw extra DCs. Bei uns ist alles relativ simpel.
Ich habe eben nachgeforscht, wir haben auch eine Enterprise-CA! Dazu muss ich sagen, wir hatten lange Zeit einfach gar keine CA, aber haben durch einen Dienstleister einen zweiten Exchange mit DAG einrichten lassen. Dabei wurde auch einem unserer beiden DCs die CA-Enterprise Rolle hinzugefügt. Ich war zwar mit dabei und habe auch viel aufgeschnappt und betreue das ganze auch jetzt aber super Sattelfest bin ich nun leider nicht
Ich habe eben bei einem der beiden DCs das extra LDAPS Zertifikat gelöscht und somit einfach mit seinem "hauseigenen" DC Zertifikat auch eine LDAPS Verbindung herstellen können. Das es so einfach ist habe ich nicht gewusst.
Wofür braucht man dann eigentlich den "umständlichen" Weg der in der Anleitung von "der-windows-papst" beschrieben wird?
Ich habe eben nachgeforscht, wir haben auch eine Enterprise-CA! Dazu muss ich sagen, wir hatten lange Zeit einfach gar keine CA, aber haben durch einen Dienstleister einen zweiten Exchange mit DAG einrichten lassen. Dabei wurde auch einem unserer beiden DCs die CA-Enterprise Rolle hinzugefügt. Ich war zwar mit dabei und habe auch viel aufgeschnappt und betreue das ganze auch jetzt aber super Sattelfest bin ich nun leider nicht
Ich habe eben bei einem der beiden DCs das extra LDAPS Zertifikat gelöscht und somit einfach mit seinem "hauseigenen" DC Zertifikat auch eine LDAPS Verbindung herstellen können. Das es so einfach ist habe ich nicht gewusst.
Wofür braucht man dann eigentlich den "umständlichen" Weg der in der Anleitung von "der-windows-papst" beschrieben wird?
