LDAPS mit anderem Zertifikat - wie?

[NorbertFe 2.062]

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

Ja es geht mit einem Wildcard Zertifikat, wenn dort der Name der AD Domain hinterlegt ist. ;) Solange das stimmt, paßt doch alles. Nix anderes sag ich die ganze Zeit.

[now3 0]

​

​ :D  Vermelde: Verwirrung komplett :D

​

​Ja, dass sich der KB Artikel nicht mehr auf 2008 R2 und neuer bezieht hatte ich schon gesehen. Danke jedenfalls insbesondere an - nomen est omen - testperson :cool: fürs Testen.

​Komischerweise sagt Digicert, dass es nicht geht.

​

​Genau, unser Windows Server ist eigentlich nur noch fürs Active Directory hier und steht lokal mit ner festen externen IP-Adresse rum. Die Domäne ist noch aus alten Zeiten firmenname.local

​

​Wir haben für unsere Firma ein SSL-Zertifikat für die .de Domain. Da war eben die Überlegung, dem Server einen A Record im DNS zu geben "server.firmenname.de" und das Wildcard-Zertifikat von Thatwe *.firmenname.de auch für den zu verwenden.

 

​Wenn ich Euch richtig verstehe, kann ich aber keinen alternativen Namen vergeben, auf welchen dann das Zertifikat lautet.

​Wobei das doch irgendwie funktionieren muss. Ich kann da ja schließlich auch ne fremde Seite im IIS hosten und dort das fremde Zertifikat hinterlegen?

​

​Das mit IPSec zwischen Seafile und DC ist auch ne Idee. Der Seafile steht leider nicht hier, darum muss ich den DC zumindest irgendwie nach außen öffnen.

​

​Jedenfalls herzlichen Dank fürs Feedback, habt mich ein gutes Stück weiter gebracht :thumb1:​ :thumb1:

bearbeitet 3. Januar 2017 von now3

[NilsK 2.958]

Moin,

 

ein DC ist ja nunmal auch kein Webserver ... wenn du einem Webserver, der "horst@hurz.de" heißt, ein Zertifikat für den Namen "www.tolleseite.de" gibst, dann ist das Zertifikat in dem Moment für Clients gültig, in dem sie eine Verbindung zu dem Namen "www.tolleseite.de" herstellen und diese auf den Webserver auflöst. Ein AD-Client will aber seinen DC sprechen und weiß, wie der heißt. Wenn der nun mal "DC01.firmenname.local" lautet, dann wird der Client ein Zertifikat auf den Namen "*.firmenname.de" nicht akzeptieren. Der DC im Übrigen auch nicht, er wird es dem Client gar nicht erst präsentieren, weil der Name ja nicht stimmt.

 

Und nein, du willst deinen DC nicht zum Internet öffnen. Bezüglich des Seafile willst du dir dann lieber ansehen, ob die mittlerweile ihre SAML-Implementierung fertig haben, dann holst du dir jemanden ins Haus, der euch das per ADFS anbindet.

 

Gruß, Nils

[now3 0]

Hi Nils,

 

klar, ein AD Client weiß, wie der DC heisst. Aber wenn ich externe Applikationen wie eben ein Seafile (oder auch Teampass oder sowas) per LDAPS sprechen lasse, dann dürfte das doch egal sein? In den Fall ist das ja kein nativer AD Client, sondern "nur" ein LDAP Client, der über die "www.tolleseite.de" auf LDAP zugreift. Da müsste der Server dann nur noch das entsprechend hinterlegte Zertifikat verwenden.

 

Oder sagt der Server - verzeiht meinen Laiensprech :D :

Hallo LDAP Client, der Du mich auf server.firmenname.de ansprichst. Du willst Daten von meinem AD haben. Das lautet aber firmenname.local. Also verwenden wir mal beide das .local Zertifikat.

bearbeitet 3. Januar 2017 von now3

[NilsK 2.958]

Moin,

 

was wird das hier? Wir haben dir gesagt, was die Voraussetzungen sind. Wir haben dir gesagt, wie du die auf einfache Weise erfüllen kannst.

 

Wenn du weiter basteln willst, nur zu. Ich bin dann hier aber raus.

 

Gruß, Nils

[now3 0]

Hi,

 

quatsch, ich will nicht basteln. Ich wills verstehen :) Das scheint nämlich mit den Zertifikaten anders zu sein wie beim IIS (oder noch besser beim Nginx) - da würde ich mich nämlich auskennen. Es scheint auch nicht so zu sein, dass ich mehrere Zertifikate in den Store importiere und der LDAPS einfach das "passende" verwendet, abhängig vom Domainnamen, mit dem er aufgerufen wurde. So wie ich mir das eigentlich vorgestellt habe.

 

Seafile soll auch irgendwann O-Auth können, aber tut das derzeit genauso wenig wie SAML, daher ist das noch keine Option.

[NilsK 2.958]

Moin,

 

nochmal: Ein DC ist kein Webserver. Und LDAPS ist nicht https.

 

Ein Webserver soll oft unter verschiedenen Namen erreichbar sein. Das dafür nötige Zertifikatshandling ist Teil der Webserver-Software. Da kommen dann auch noch Techniken wie Host Headers, SNI usw. ins Spiel. Wenn du dich auf der Ebene auskennst, wirst du davon ja schon gehört haben.

 

Ein DC soll gerade nicht unter verschiedenen Namen erreichbar sein. Es geht hier um die zentrale Security-Komponente eines Netzwerks. Aus genau dem Grund schreibt Microsoft (wie auch der Kerberos-Standard) ein Zertifikat mit exaktem Hostnamen vor.

 

Und ganz sicher willst du deinen DC nicht zum Internet öffnen. Das ist ein No-go. Wenn Seafile keine andere Authentisierung für SSO ermöglicht, dann muss man dem Szenario eben auf SSO verzichten.

 

Gruß, Nils

[zahni 554]

@now3,

 

Die Kommunikation des Webservers mit LDAPS hat doch nichts mit dem Hostnamen den Webservers zu tun.

Übrigens: Wenn Du eine Windows-Enterprise-CA in einem AD installierst, holt sich der DC das  Zertifikat dort alleine. Auf dem Client (der Webserver) müsste dann das Root-Zertifikat der Windows-CA importiert werden.

[magheinz 110]

​

​

Das mit IPSec zwischen Seafile und DC ist auch ne Idee. Der Seafile steht leider nicht hier, darum muss ich den DC zumindest irgendwie nach außen öffnen.

​

​Jedenfalls herzlichen Dank fürs Feedback, habt mich ein gutes Stück weiter gebracht :thumb1:​ :thumb1:

Also dein seafile soll eine Authentifizierung per LDAP machen. Der Seafile steht  aber icht bei euch und das LDAP muss übers internet laufen?

Da bleibt nur ein VPN dazwischen und eventuell ein filternder LDAP-Proxy mit RO-Rechten. Je nach dem welches Vertrauen der seafileserver geniesst.

 

Was die Verschlüsselung betrifft ist es egal ob du LDAPS machst oder ein VPN da drunter legst, aber die Angriffsfläche die ein DC im internet bietet würde meiner Meinung sogar eine parallele gepflegte Nutezrdatenbank auf dem seafile-server lokal rechtfertigen.

 

Wie gesagt: Bau ein VPN auf. Ob ipsec, SSL oder was auch immer ist egal. Sorg nur dafür das der DC nicht im internet ist. Der hat alle deine Userdaten, Passwörter etc.

[Doso 77]

Kann mich nur anschließen: Bitte stellt keinen AD Domaincontroller frei ins Internet.

[NilsK 2.958]

Moin,

 

ich würde sogar noch weiter gehen: Wenn der Seafile-Server von einem Dienstleister verwaltet wird, dann ist eine AD-Anbindung ein No-go. Sonst hat der Dienstleister Zugriff auf die AD-Anmeldung. Das ist ein nicht vertrauenswürdiges System.

 

Gruß, Nils