Zum Inhalt wechseln


Foto

LDAPS mit anderem Zertifikat - wie?

Windows Server 2012

  • Bitte melde dich an um zu Antworten
25 Antworten in diesem Thema

#16 NorbertFe

NorbertFe

    Expert Member

  • 30.605 Beiträge

 

Geschrieben 03. Januar 2017 - 12:40

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.

Make something i***-proof and they will build a better i***.


#17 now3

now3

    Newbie

  • 6 Beiträge

 

Geschrieben 03. Januar 2017 - 14:28

: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, 03. Januar 2017 - 14:39.


#18 NilsK

NilsK

    Expert Member

  • 12.334 Beiträge

 

Geschrieben 03. Januar 2017 - 15:08

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#19 now3

now3

    Newbie

  • 6 Beiträge

 

Geschrieben 03. Januar 2017 - 15:41

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, 03. Januar 2017 - 15:44.


#20 NilsK

NilsK

    Expert Member

  • 12.334 Beiträge

 

Geschrieben 03. Januar 2017 - 20:03

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#21 now3

now3

    Newbie

  • 6 Beiträge

 

Geschrieben 03. Januar 2017 - 22:07

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.



#22 NilsK

NilsK

    Expert Member

  • 12.334 Beiträge

 

Geschrieben 04. Januar 2017 - 09:09

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#23 zahni

zahni

    Expert Member

  • 16.390 Beiträge

 

Geschrieben 04. Januar 2017 - 10:35

@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.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#24 magheinz

magheinz

    Newbie

  • 1.328 Beiträge

 

Geschrieben 04. Januar 2017 - 11:57

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.



#25 Doso

Doso

    Board Veteran

  • 2.457 Beiträge

 

Geschrieben 04. Januar 2017 - 17:54

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



#26 NilsK

NilsK

    Expert Member

  • 12.334 Beiträge

 

Geschrieben 05. Januar 2017 - 07:23

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!




Auch mit einem oder mehreren der folgenden Tags versehen: Windows Server 2012