LDAPS Zertifikat

[al3x 11]

Hallo in die Runde,

 

in einer 2012er-AD mit 4 DC´s muss ein 3rd-party System (Linux-Groupware) ans AD angebunden werden, dies soll natürlich gleich mit ldaps geschehen.

Hierzu bräuchte ich mal eure Unterstützung bzgl. best-practice, bin mir da nämlich trotz div. Quellen/Posts unschlüssig.

Ist es sinnvoller für solche non-Windows Systeme ein eigenes Zertifikat mit langer Laufzeit zu erstellen, das dann auf allen DC´s importiert wird und von der Applikation benutzt wird?

wie hier zB beschrieben....oder hier  ?!

 

Oder exportiert man besser von jedem einzelnen DC ein sowieso vorhandenes Kerberos-Authentifizierungszertifikat (1.3.6.1.4.3...) und bindet diese (in dem Fall 4 Zertifikate) in dem "externen" System ein?

Bedeutet aber doch, dass man diese Prozedur jährlich wiederholen muss, sobald die automatisch erstellten Zertifikate abgelaufen sind.

 

Oder hab ich was übersehen?

 

[NorbertFe 2.061]

Häh? Dein Groupwaresystem spricht also LDAPs mit den DCs. Also müssen deine DCs ein Zertifikat dafür anbieten (bspw. das erwähnte Kerberos-Auth Zert). Da mußt du auch nichts im externen System einbinden, sondern maximal entscheiden, ob du das Root-Zert an das externe System gibts, oder ob du Zertifikatsfehler ggf. ignorieren kannst/darfst/willst. Deine Formulierungen lassen ein wenig darauf schließen, dass dir das Prinzip nicht ganz geläufig ist. Falls mich das täuschen sollte, dann bitte nicht übel nehmen. :)

Bye

Norbert

[NilsK 2.957]

Moin,

 

stell es dir vor wie bei einem Webserver und dessen TLS-Zertifikat ("SSL-Zertifikat") - das ist ziemlich exakt dasselbe. Der Webserver hat ein Zertifikat, mit dem er die Verschlüsselung einleitet. Der Client braucht kein Zertifikat, er muss nur dem Zertifikat des Servers vertrauen. Dafür muss man ihm das Root-Zertifikat seiner PKI zugreifbar machen. Genauso ist das auch beim DC und dem LDAPS-Zertifikat.

 

Die Artikel, die du zitierst, gehen von anderen bzw. speziellen Voraussetzungen aus. Sie gelten nicht allgemein. Im ersten Fall geht es um LDAP-Loadbalancer (die ohnehin im AD nicht supported sind), im zweiten um spezielle Szenarien bei DCs, die mehr als ein Zertifikat haben (was man vermeiden sollte, aber in den meisten Fällen auch kein Problem darstellen würde).

 

Gruß, Nils

 

[al3x 11]

Moin und danke für eure Antworten!

 

@Norbert,

also wenn ich mir die LDAPS-Events 2889 anschaue, dann sieht man, dass der Groupwareserver eine Klartextverbindung mit dem AD herstellen will.

Um hier auf SSL umzustellen, muss in dessen config der Port 636 eingestellt und das bzw. ein (oder mehrere bei mehreren DCs?) LDAP-Zertifikate hinterlegt werden.

 

Daher mein erster Gedanke, von den DC´s die Kerb-Auth-Certs zu exportieren und in der config das .crt anzugeben.

 

 

bearbeitet 27. Februar 2020 von al3x

[NorbertFe 2.061]

Siehe nils‘ Antwort. Du installierst dir ja auch nicht jedes Webserverzertifikat in deinem Browser. 

[al3x 11]

vor 16 Minuten schrieb NorbertFe:

Siehe nils‘ Antwort. Du installierst dir ja auch nicht jedes Webserverzertifikat in deinem Browser. 

also ist der Weg das Kerb-Auth zu exportieren der richtige Weg?

 

 

 

[NorbertFe 2.061]

Nein. Wie schon gesagt, dein Client (groupware System) muss halt die Verbindung über Port 636 herstellen und dem angebotenen Zertifikat vertrauen (= Root Zertifikat besitzen), oder dem angebotenen Zertifikat nicht vertrauen, das aber dann ignorieren. 

[al3x 11]

hm.. okay dann bin ich ja nicht ganz b***d , denn so war eigentlich auch mein bisheriger Stand.

Dann hat es mit dem Zertifikat, welches man dort zwecks ldaps einbinden muss wohl eine andere Bewandnis. Eventuell ist das nur wenn Clients per 636 auf die Groupware wollen OHNE das eine AD-Query dahintersteckt....

[NorbertFe 2.061]

vor 53 Minuten schrieb al3x:

man dort zwecks ldaps einbinden muss wohl eine andere Bewandnis

Falls "dort" deine Groupware meint, dann dürfte es sich um das ROOOOOOOT Zertifikat handeln. ;) Ansonsten müßtest du mal genauer werden und ggf. einen Screenshot schicken.