now3

S2D ist halt flexibler und billiger. Da reichen für den Anfang bereits die 2 Server. Eine nackte SAS-MSA2040 verursacht bereits ca. 1-5k€ Mehrkosten, braucht mehr Platz im Rack und mehr Strom. Und ist unflexibler, wenn die mal voll ist.

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.

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.

​ ​ :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:

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 :-(

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-Zertifikat1 *.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