LDAPS mit anderem Zertifikat - wie?

[now3 0]

Hallo zusammen,​

​

​ich habe einen Windows 2012 Server mit einer kleinen AD-Domäne firmenname.local

​

Nun möchte ich einige Dienste, beispielsweise unseren Seafile-Server, mit LDAPS verbinden, damit sich unsere Mädels hier ( :D) nicht verschiedene Kennwörter merken müssen.

​

​Jetzt kommts: wir haben ein Wildcard-Zertifikat¹ *.firmenname.de, welches zur Absicherung dienen soll.

​

​In meiner naiven Denkweise dachte ich:

​1. Einen A-Record anzulegen "ldap.firmenname.de" auf unseren Server

​2. Port 636 in der Firewall öffnen

​3. Unser Wildcard-Zertifikat einspielen

​

​Aber das klappt nicht - der Zugriff mittels ldp.exe verwendet immer das eigen erstellte Zertifikat, und lösche ich das raus, ist gar kein Zugriff auf Port 636 mehr möglich.

​

​Würde mich über einen WInk in die richtige Richtung sehr freuen :)

​

​^​1 Das Wildcard-Zertifikat hat als Zertifikat-Verwendung, wie von Microsoft in einem Uralt-KB 321051, die Verwendung 1.3.6.1.5.5.7.3.1 aktiv

[NilsK 2.930]

Moin,

 

das wird mit einem Wildcard-Zertifikat nicht gehen.

https://support.microsoft.com/en-us/kb/321051

 

Du kannst aber auch ein selbstsigniertes oder internes Zertifikat nehmen, das lässt sich ja per GPO einfach an die Clients verteilen.

 

Gruß, Nils

[now3 0]

Moin Nils,

danke für Deine Antwort.

 

Ist das wirklich so?

Hier lese ich zum Beispiel:

If you want to enable LDAPS on multiple DCs, you will have to purchase a wildcard certificate, which is a certificate you can install on more than one computer.

 

Hier steht auch, dass es gehen müsste. Nur funktionierts halt nicht :suspect:

 

Das mit dem eigenen Zertifikat wäre grds auch okay, klappt aber halt nicht mit Office 365 Exchange, nehme ich an :-(

[NorbertFe 2.027]

Du hast aber den wichtigsten Teil im von Nils verlinkten Artikel offenbar übersehen:

•The Active Directory fully qualified domain name of the domain controller

Und wenn dein AD eben einen nicht offiziell auf dich registrierten Domain Namen haben sollte, würde ich eher dem MSKB Link glauben als deinen. ;)

 

Bye

Norbert

[NilsK 2.930]

Moin,

 

ich würde den beiden Quellen auch nicht trauen - die behaupten das zwar, aber der eine hat es offensichtlich gar nicht getestet, und der andere gibt gleichzeitig an, dass er sich auf einen Webserver bezieht und nicht auf einen DC ... das ordne ich als "Amazon-Antwort" ein ("kann ich nicht beantworten, weil ich das Produkt nicht gekauft habe, aber in folgender völlig anderer Situation ist es so-und-so").

 

Ich halte es auch für ausgesprochen abwegig, für den Zweck "LDAPS im AD" ein Wildcard-Zertifikat zu nehmen. Gerade bei DCs möchte man das ja schon genau kontrollieren, da sind Single-Server-Zertifikate der gewünschte Weg. Wenn man keine PKI hat und keine Self-Signed-Zertifikate ausstellen will, hat man mit OpenSSL in einer Stunde die nötigen Zertifikate erzeugt (inkl. Einlesen in OpenSSL).

 

Gruß, Nils

[testperson 1.674]

Hi,

 

habe das grade mal "rudimentär" getestet. Alle entsprechenden Zertifikate gelöscht und nur ein Wildcard importiert und gebunden und LDAPs funktioniert.

Sinnvoll finde ich es allerdings ebenfalls nicht, für diesen Zweck ein Wildcard Zertifikat zu nutzen.

 

Gruß

Jan

[NorbertFe 2.027]

Ich vermute, er hat ein wildcard Zertifikat für die externe domain und nicht für den ad Domain Namen (weil er vermutlich intern ist). Dann kann das nach obigem Link nicht funktionieren.

[testperson 1.674]

Ja, bei mir passte halt das Wildcard zum Rest.

Manchmal ist man eben auf der Sonnenseite des Lebens ;)

[NilsK 2.930]

Moin,

 

Ja, bei mir passte halt das Wildcard zum Rest.

 

ah, OK, gut zu wissen. Dann ist - technisch betrachtet - der KB-Artikel, den ich gefunden habe, wohl einfach nicht mehr aktuell. Er bezog sich ursprünglich wohl auf Windows 2000, da war Windows mit dem Zertifikatshandling noch nicht so weit.

 

Was aber nichts an dem Umstand ändert, zu dem wir einig sind: Für LDAPS ist das nicht sinnvoll.

EDIT 2: Natürlich funktioniert das mit einem Alias-Namen in keinem Fall. Ein Zertifikat soll ja gerade sicherstellen, dass man mit dem richtigen Server verbunden ist ...

 

EDIT 1: Ich sehe gerade noch eine Bemerkung:

 

 

Das mit dem eigenen Zertifikat wäre grds auch okay, klappt aber halt nicht mit Office 365 Exchange, nehme ich an

 

Ich würde mal behaupten, dass LDAPS in der eigenen Domäne mit Office 365 überhaupt nichts zu tun hat.

 

Gruß, Nils

bearbeitet 3. Januar 2017 von NilsK

[NorbertFe 2.027]

Doch dein Artikel beschreibt genau diese Anforderung. :)

[NilsK 2.930]

Moin,

 

Doch dein Artikel beschreibt genau diese Anforderung. :)

 

nach zwei Bearbeitungen kann ich jetzt leider nicht mehr ganz auseinanderdröseln, worauf du dich beziehst ... ;)

 

Gruß, Nils

[NorbertFe 2.027]

Ich bezog mich auf

ah, OK, gut zu wissen. Dann ist - technisch betrachtet - der KB-Artikel, den ich gefunden habe, wohl einfach nicht mehr aktuell.

und meinen Hinweis weiter oben, dass MS mitteilt, dass der Domain Name des DCs im Zertifikat zu stehen hat:

The Active Directory fully qualified domain name of the domain Controller

Bye

Norbert

[NilsK 2.930]

Moin,

 

ja, die Anforderung ist da beschrieben, aber anders als daraus zu entnehmen war, geht es - technisch - ja offenbar doch mit einem Wildcard-Zertifikat. Ich würde aber davon ausgehen, dass das nicht supported ist, weil der KB-Artikel eben ausdrücklich den DC-Namen anfordert. (Vielleicht meintest du das in der Art.)

 

Ich denke, jetzt haben wir den TO endgültig verwirrt. :D

 

Gruß, Nils

[testperson 1.674]

Zur vollständigen Verwirrung könnte man noch überlegen, zwischen Seafile-Server und DCs IPSec zu erzwingen und somit auf LDAPs verzichten ;)

[Doso 77]

​2. Port 636 in der Firewall öffnen

 

Mach das mal gaaaaanz schnell wieder zu! Wenn der Seafile Server bei euch steht spricht der Seafile Server LDAP(s) mit eurem DC - und nicht der Rest der Welt.