OpenLDAP TLS-Authentifizierung

Ich versuche, TLS gemäß https://help.ubuntu.com/lts/serverguide/openldap-server.html zu implementieren. Wenn ich versuche, die Datenbank cn = config mit dieser ldif-Datei zu ändern:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/test-ldap-server_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/test-ldap-server_key.pem

Ich erhalte folgenden Fehler:

ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)

Was mache ich falsch?

BEARBEITEN: Wenn ich versuche, einfache Authentifizierung zu verwenden, wird der folgende Fehler angezeigt:

ldapmodify -x -D cn=admin,dc=example,dc=com -W -f certinfo.ldif
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
        additional info: invalid DN

Ich folgte dem gleichen Leitfaden und hatte das gleiche Problem. Es funktioniert, wenn Sie die Schritte zum "Verschärfen von Besitz und Berechtigungen" ausführen, die zuerst nach dem Befehl "ldapmodify" aufgeführt sind - nämlich:

sudo adduser openldap ssl-cert
sudo chgrp ssl-cert /etc/ssl/private
sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod g+X /etc/ssl/private
sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem

und

sudo systemctl restart slapd.service

Nun, ich weiß nicht, ob dies eine Lösung oder nur eine Problemumgehung ist, aber ich habe es geschafft, dass es funktioniert.

Ich habe den Slapd zuerst gestoppt mit:

service slapd stop

Dann habe ich es im Debug-Modus gestartet:

slapd -h ldapi:/// -u openldap -g openldap -d 65 -F /etc/ldap/slapd.d/ -d 65

Wichtig ist, dass Sie es NUR mit der URL ldapi: /// starten. Nach dem Start habe ich den Befehl ldapmodify ausgeführt und die Attribute wurden importiert.

Am Ende habe ich den Debug-Modus gestoppt und den Slapd normal gestartet.

Im Anschluss an die Antwort von A. Gutierrez können Sie den Zugriff für jede Datei am besten überprüfen, indem Sie sie ausführen sudo -u openldap cat <filename>. Ich habe alle Dateien mehrmals angesehen und sie haben die richtigen Berechtigungen festgelegt. Es stellte sich heraus, dass dies ein Gruppenproblem für openldap war. Als ich das endlich herausgefunden hatte, sudo usermod -a -G ssl-cert openldaplöste es ein einfaches für mich.

Manchmal liegt das Problem im Apparmor-Profil für Slapd-Dienste. Stellen Sie sicher, dass das Apparmor-Profil Zertifikatspfade für den Daemon zugelassen hat.

Es ist ganz visuell in /etc/apparmor.d/usr.sbin.slapd. Standardmäßig ermöglicht dieses Profil das Lesen von Zertifikaten an Standardspeicherorten.

Apparmor sollte trotz spezifizierter Unix-Berechtigungen nicht spezifizierte Aktionen für die ausführbare Datei des Dämons verhindern.

Wie ich in diesem Fehler auf Ubuntu Launchpad berichtet habe , kann dieses Problem auch durch Apparmor verursacht werden. Normalerweise wird dies im Syslog als Zugriffsverweigerung angezeigt.

Das Update fügt die folgende Zeile in /etc/apparmor.d/usr.sbin.slapd ein:

/etc/letsencrypt/** r,

und dann das Profil aktualisieren:

# apparmor_parser -vr usr.sbin.slapd
# service apparmor restart

Ich habe dieses Problem auch. Das Problem ist, dass der Benutzer, der slapd ausführt, keinen Zugriff auf Zertifikatsdateien hat. Überprüfen Sie, ob der Eigentümer dieser Dateien ein openldap-Benutzer ist.

Für mich war das Problem in der falschen Reihenfolge der Aufzeichnungen - hier ist die, die funktioniert hat:

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cm_ca_cert.pem
-
# This never worked for me, no idea why
#add: olcTLSCipherSuite
#olcTLSCipherSuite: TLSv1+RSA:!NULL
#-
replace: olcTLSVerifyClient
olcTLSVerifyClient: never
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/cm_server.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/cm_server.key

Leider scheint dies der "Standard" -Fehler zu sein, den Sie für fast alles erhalten. Die Antwort von @ wulfsdad behebt das Problem normalerweise.

Eine andere Sache, die ich immer vergesse, ist, dass standardmäßig auf Ubuntu Slapd der Schlüssel im OpenSSL-Format sein soll. Ich reguliere aber regelmäßig PCKS # 8 und erwarte, dass es einfach funktioniert (was fair sein sollte). Wenn Sie alle oben genannten Antworten ausprobiert haben, stellen Sie außerdem sicher, dass der Schlüssel das richtige Format hat. Wenn Sie über den Fehler googeln, lesen Sie normalerweise über falsche Berechtigungen und reiben sich den Kopf, warum Apache mit dem Schlüssel funktioniert, den Slapd nicht mag.