Einrichten von SSL mit 389 Directory Server für die LDAP-Authentifizierung

7

Ich habe 389 Directory Server auf RHEL 5 mit Gruppen, Benutzern, Posix usw. ausgeführt. RHEL-Clients authentifizieren Benutzer mit LDAP - keine Probleme, alles funktioniert einwandfrei, aber Passwörter werden im Klartext gesendet und sind mit dem Netzwerk-Sniffer sichtbar. Also entschied ich mich für SSL:

  1. CA erstellt - hat sowohl private als auch öffentliche CA-Zertifikate erhalten
  2. Verwenden von CA-Zertifikaten: Generiert sowohl private als auch öffentliche Zertifikate und kombiniert ( 1. Datei ) für 389DS gemäß 389DS-Zertifikatanforderung, importiert mit CA Public Cert in 389DS von der grafischen Konsole ( 2. Datei ).
  3. SSL in 389DS aktiviert
  4. Auf dem Client wurde unter Verwendung von authconfig-gtk aktiviertem SSL für LDAP nur das öffentliche CA-Zertifikat angegeben

Funktioniert nicht

Wie man? Was ist der beste Weg, um sicher zu integrieren?

ssl  ldap  authentication  389-ds  fedora 
— GioMac
quelle
Normalerweise wird LDAP über SSL über Port 636 ausgeführt. Gegen welchen Port versucht Ihr Client?
— SpacemanSpiff
Sicher ist es 636. Die Frage ist, warum SSL-Handshake nicht funktioniert, was falsch ist, wie es gemacht werden sollte und warum der öffentliche CA-Schlüssel ausreicht.
— GioMac
3
Sie können Ihre SSL-Konfiguration folgendermaßen überprüfen : openssl s_client -connect fqdn.of.the.ldap.server.or.ip:636. Der Server sollte mit den Zertifikaten antworten. Wenn nicht, liegt ein Problem mit der Konfiguration Ihres Servers vor. Aktualisieren Sie Ihre Frage mit den Ergebnissen.
— ixe013
Hoffentlich kann sich jemand einschalten, der mit 389DS vertraut ist, aber sicherlich führen sowohl Server als auch Client Protokolle?
— SpacemanSpiff
ixe013: 389 Seite sieht gut aus: Server antwortet mit öffentlichem Zertifikat und schlägt TLSv1
— GioMac

Antworten:

7

Als erstes möchten Sie möglicherweise überprüfen, ob Ihr Server die Zertifikate ordnungsgemäß präsentiert. Sie können dies tun, indem Sie versuchen, mit OpenSSL eine Verbindung zu Ihrem Server herzustellen. Führen Sie auf einem Clientcomputer mit Zugriff Folgendes aus:

openssl s_client –connect target_server_fqdn:636

Dies sollte einen schönen Ausdruck des Serverzertifikats zurückgeben. Der Schlüssel hier ist die Überprüfung des am Ende gedruckten "Rückgabecodes überprüfen". Möglicherweise erhalten Sie unterschiedliche Codes, aber im Allgemeinen sollten Sie 0 für ein gültiges Zertifikat und möglicherweise 19 erhalten, wenn Sie sich selbst signieren.

Wenn dies fehlschlägt, gehen Sie zurück und überprüfen Sie, ob Sie Ihre serverseitigen Zertifikate ordnungsgemäß importiert haben.

Wenn Sie diesen Test bestanden haben, fahren Sie mit dem Testen Ihrer TLS-Verbindungen auf der Clientseite fort.

Führen Sie auf einem Clientcomputer aus

ldapsearch -z -ZZ '(uid=<testusername>)'

Dadurch wird eine LDAP-Suche über eine verschlüsselte Verbindung erzwungen. Wenn dies erfolgreich ist, sollten Sie einige Benutzerinformationen zurückerhalten, und ein Einchecken in die DS-Protokolle sollte Folgendes ergeben:

[23 / Sep / 2011: 07: 48: 57 -0500] conn = 1631 op = 0 EXT oid = "XXXXXX.X.XX" name = "startTLS" [23 / Sep / 2011: 07: 48: 57 -0500 ] conn = 1631 op = 0 RESULT err = 0 tag = 120 nentries = 0 etime = 0 [23 / Sep / 2011: 07: 48: 57 -0500] conn = 1631 SSL 256-Bit-AES

Wenn dies fehlschlägt, sollten Sie sicherstellen, dass die Zertifikate auf der Clientseite ordnungsgemäß importiert wurden.

Bei der Fehlerbehebung habe ich häufig nach folgenden Bereichen gesucht:

1.) Auf den Clients können Sie in einigen Fällen (die hier von jemandem besser erklärt werden können) versuchen, eine Signatur zu verlangen, indem Sie ldap.conf bearbeiten und die Zeile einschließen

TLS_REQCERT allow

2.) Wenn die Authentifizierungs-GUI Probleme verursacht, können Sie versuchen, TLS für LDAP mit explizit zu aktivieren

authconfig --enableldaptls --update

Ich hatte zuvor Probleme mit der GUI, daher bleibe ich eher bei der Verwendung von CLI-Befehlen.

3.) Und eine letzte Sache, die Sie versuchen könnten (noch einmal, nur zum Testen), ist anzurufen 

cacertdir_rehash <dir where certs are stored>

Aktualisieren

Wenn Sie weitere Hilfe beim Erstellen von Selbstsignaturzertifikaten suchen, versuchen Sie Folgendes:

1.) Erstellen Sie Ihr eigenes, selbstsigniertes CA-Zertifikat:

certutil -S -n "<CA Certificate Name Here>" -s "cn=<CN Name Here>, dc=<Your DC's FQDN>" -2 -x -t "CT,," -m 1000 -v 120 -d . -k rsa

2.) Erstellen Sie ein Serverzertifikat für den Verzeichnisserver

certutil -S -n "Cert-Name" -s "cn=<Server FQDN>" -c "<Name of CA Certificate>" -t "u,u,u" -m 1001 -v 120 -d . -k rsa

3.) Importieren Sie diese beiden Zertifikate in den Verzeichnisserver im Abschnitt "Zertifikate verwalten", der unter "Aufgaben" ausgewählt ist.

4.) Aktivieren Sie die TLS-Verschlüsselung

5.) Erstellen Sie ein exportierbares Zertifikat für Clients und geben Sie es in eine PEM-Datei aus

certutil -d . -L -n "<CA Certificate Name>" -a > cacert.pem

6.) Laden Sie nach Ihrer Wahl das Client-Zertifikat auf jeden Client herunter.

7.) Bereiten Sie die Zertifikate mit dem zuvor genannten Befehl erneut vor

cacertdir_rehash <dir where certs are stored>
— Univ426
quelle
Es sieht so aus, als ob Serverzertifikate immer noch nicht richtig generiert wurden. Außerdem scheint sich das Format geändert zu haben. Ich habe versucht, Zertifikate mit den gefundenen Anleitungen zu generieren und zu importieren, aber kein Erfolg.
— GioMac
Cool, eingrenzen - Sie versuchen also, selbstsignierte Zertifikate zu generieren? Oder haben Sie eine von einer größeren Zertifizierungsstelle gekauft?
— Univ426
Wenn Sie möchten, kann ich meine Antwort mit dem Prozess aktualisieren, mit dem ich Zertifikate mit CertUtil erstellt habe. Hoffentlich hilft das.
— Univ426
Ist dieser Typ nicht auf Fedora oder so und zertifiziert ein MS-proprietäres Tool?
— Ram
Ich glaube, er hat gesagt, er ist auf RHEL5. Ich denke, MS hat auch einen Build von certutil, könnte dasselbe sein, könnte anders sein, aber ich weiß, dass certutil im Lieferumfang von Directory Server enthalten ist und wir es auf unseren RHEL-Systemen verwenden. docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.1/html/…
— Univ426
2

Ich hatte kein Glück, SSL für das 389-Verzeichnis oder die Administrationsserver nach den gefundenen Howtos zu konfigurieren (ich dachte, das lag daran, dass ich Centos 6 verwendete und die meisten Howtos speziell auf Redhat abzielten).

Was schließlich für mich funktioniert hat, war, Zertifizierungsanforderungen von den Serverschnittstellen der 389-Konsole (admin | dir) zu initiieren, diese Anforderungen mit einer tinyCA-Installation zu signieren (nur ein Frontend für openssl, ich bin faul), die signierten PEM-Zertifikate und CA zu exportieren Zertifikate und importieren Sie diese mit der 389-Konsole zurück.

389 Konsole -> Servergruppe -> (Administrator / Verzeichnis) Server -> Öffnen -> Zertifikate verwalten

Hoffe das hilft...

— Vierbeiner
quelle
Vielen Dank für den Beitrag: Gleiches hier ... Ich habe alle Anleitungen und Handbücher ausprobiert, aber diese zielen auf RHDS ab, nicht auf 389 (es gibt einen Unterschied). Ich werde morgen versuchen, Zertifikate auf die gleiche Weise zu generieren und zu antworten.
— GioMac
tinyCA ist eine gute Sache (c). Ich habe CA erstellt, CA-Zertifikat exportiert, in 389DS importiert, Anforderung mit 389DS erstellt, Anforderungszertifikat in tinyCA importiert, Anforderung mit tinyCA signiert, Serverzertifikat mit dieser Anforderung erstellt, exportiert und dann in 389DS importiert, Client-Zertifikat erstellt, exportiert und in das Zertifikatverzeichnis des Clients kopiert, auch cacert kopiert. Kein Glück. Alle Optionen waren Standard. Also habe ich in 389DS ein Cacert- und Server-Zertifikat, in Openldap auch ein Cacert- und ein Client-Zertifikat. Irgendein Tipp?
— GioMac
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.