Jump to content

LDAPS mit anderem Zertifikat - wie?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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.

Link zu diesem Kommentar

​ :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 von now3
Link zu diesem Kommentar

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

Link zu diesem Kommentar

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 von now3
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...