Jump to content

Subtellite

Members
  • Gesamte Inhalte

    7
  • Registriert seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von Subtellite

Apprentice

Apprentice (3/14)

  • Erste Antwort
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei
  • 1 Jahre dabei

Neueste Abzeichen

0

Reputation in der Community

  1. Ja natürlich ist das mein Problem, von alleine beseitigen die DCs mein Problem nämlich nicht. Aber egal, das Problem konnte ich beseitigen, ich denke es ist ein Bug mit der auf der Linuxmaschine installierten Openssl version (1.1.1h), denn auf der Windowskiste (Openssl 1.1.1i) zieht er sich das (richtige) Zertifikat. Ich probiere das jetzt noch mit ein paar anderen Clients aus. Auch auf dem einen DC (den anderen teste ich noch zur sicherheit) zeigt mir Wireshark an, das der LDAP Browser über Port 636 zugreift (389 funktioniert logischerweise auch). Das einzige was mich gerade wundert ist, das der Globalcatalog Port 3268 zwar im Wiresharkmitschnitt auftaucht, der für LDAPs aber nicht (3269). Vielen Dank Jungs
  2. Ja genau und trotzdem funktioniert es nicht.
  3. Ich sage mal vorsichtig ja, das tut die Linuxkiste. Da ich nur das Root-Cert und die LDAPS-Certs habe und alle drei in den Trusted Store geladen habe sollte die Linuxkiste der Certchain vertrauen. Also Root-CA -> Domaincontroller -> Clients
  4. Ja die CA war schon vor mir da. Ich habe keine DC oder irgendwelche Server (DHCP/DNS oder ähnliches) hinzugefügt oder entfernt. Ich habe tatsächlich nur die LDAPS Zertifikate hinzugefügt oder entfernt. Das klang ja auch so einfach, weshalb ich auf eine komplette Testlandschaft verzichtet habe. Das aktuelle Netzwerk läuft ja schon über LDAP und soll auf LDAPS umgestellt werden.
  5. Naja Ich verändere ja nicht wirklich etwas. Ich erstelle Zertifikate (bzw. deren vorlagen) die ich auch wieder lösche wenn es nicht funktioniert. Da ist die Testumgebng für mich nicht notwendig gewesen. Meine "Testumgebung" war tatsächlich nur eine Linuxkiste mit der ich mich austoben konnte. Alles andere in der Domäne bzw. an den DCs oder der CA wurde ja nicht verändert.
  6. Ja das ist eine Enterprise-CA. Ich habe die DC-Auth.-Vorlage gelöscht und dann auch mal wegen dem Templateschema geschaut und tatsächlich musste ich (nicht mehr) mit dem ADSI Editor das Template ändern um die Vorlagen zu veröffentlichen zu können (das musste ich aber, deswegen bin ich über das Templateschema und den ADSI Editor gestolpert). Von einer Windowsmaschine kann ich mir das Zertifikat des DCs anzeigen lassen (mit der openssl abfrage) allerdings nur mit der Fehlermeldung unable to get local issuer certificate und unable to verify the first certificate. Von der Linuxmaschine bekomme ich nur die oben genannte Meldung. Das ich die Grundlagen nicht mal eben so lerne ist mir klar geworden als ich anfing mich damit zu befassen. Ich bin außerdem der neue in der Firma, also seh ich zu das ich die Aufgabe umsetzen kann. Und danke für den Tipp, ich werde mal eine Testumgebung erstellen. Grad nochmal geschaut, nein sind sie nicht. Unsere Webserver sind wonders versteckt. Keine warum die Webserver in die Auflistung mit rein gerutscht sind. Das ist auch unser Self-Signed-Certificate. Unsere CA stellt ein SelfSignedCert aus (das Root-Certificate) was als als Anker für alle Clients dient. Die DCs sollen sich dann mit den LDAPS Zertifikaten (mit dem entsprechenden Zertifizierungspfad) ausweisen.
  7. Hallo, Ich befasse mich seit geraumer Zeit mit dem Thema Self-Signed Certifcates und die Umstellung von LDAP auf LDAPS. Ich habe mich vorher nie mit den beiden Themen befasst, also entschuldigt eventuelle Anfängerfragen. Ich habe eine eigene CA in meinem Netzwerk und mehrere Domaincontroller. Die CA (WinServer 2016 DataCenter) dient zur Austellung von eigenen Zertifikaten und die DCs (WinServer 2012 R2 DataCenter) dienen als LDAP-/DHCP-/DNS- und Web-Server. Wenn ich nach dieser (oder ähnlichen) Anleitung gehe: http://terenceluk.blogspot.com/2013/10/configure-ldaps-active-directory-domain.html soll ich auf der CA eine Zertifikatvorlage erstellen, diese veröffentlichen und die veröffentlichte Zertifikatvorlage von den DCs aus anfordern. Das soll ausreichen um LDAPS zu aktivieren. Ich muss allerdings noch mit dem ADSI Editor das Templateschema ändern, damit ich die Vorlage überhaupt veröffentlichen kann (habe ich irgendwo gelesen). Außerdem habe auch irgendwo gelesen das das ganze nicht funktioniert wenn man mehrere Zertifikate auf den DCs hat die Serverauthentifizierung anbieten. Nun habe ich aber auf meinen DCs auch die Zertifikatvorlage für Domaincontrollerauthentifizierung, die schon vorher installiert war. Wozu brauche ich dann eine zweite Vorlage die nur anders heisst? Mit der ldp.exe kann ich auch bestätigen das die Verbindung über den Port 636 (und auch 389) funktioniert (sowohl von DC1 zu DC1 als auch von DC1 zu DC2 zum Bsp.). Auch ein Script (https://evotec.xyz/testing-ldap-and-ldaps-connectivity-with-powershell/) zeigt mir das alle meine DCs bereit sind für LDAPS. Und trotzdem kann ich zum Beispiel von einer Linuxmaschine (ein Testsystem) keine LDAPS Verbindung aufbauen. Mit der Abfrage openssl s_client -showcerts -connect DC1.MEINE.DOMAIN:636 sollte eigentlich das LDAPS Certificat inklusive Certchain angezeigt werden, allerdings ohne Erfolg (Ausgabe lautet unter anderem: write:errno=104 no peer certificate available no client certificate CA names sent ssl handshake has read 0 bytes). Versuche ich das ganze über eine CSR (wie hier beschrieben: https://bl.ocks.org/magnetikonline/0ccdabfec58eb1929c997d22e7341e45) funktioniert es. Aber dann muss ich für jeden Computer im Netzwerk (und für jeden DC?) eine CSR erstellen. Ich habe offensichtlich nicht verstanden wie LDAPS funktioniert und hoffe ihr könnt mir weiter helfen.
×
×
  • Neu erstellen...