Uwierzytelnianie OpenLDAP TLS

Próbuję wdrożyć TLS zgodnie z https://help.ubuntu.com/lts/serverguide/openldap-server.html Kiedy próbuję zmodyfikować bazę danych cn = config za pomocą tego pliku ldif:

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

Otrzymuję następujący błąd:

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)

Co ja robię źle?

EDYCJA: Kiedy próbuję użyć prostego uwierzytelniania, pojawia się następujący błąd:

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

Postępowałem zgodnie z tym samym przewodnikiem i miałem ten sam problem. Będzie działać, jeśli wykonasz kroki w celu „Zaostrzenia prawa własności i uprawnień” wymienionych po pierwszym szkodliwym poleceniu ldapmodify - a mianowicie:

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

i

sudo systemctl restart slapd.service

Nie wiem, czy to rozwiązanie, czy tylko obejście, ale udało mi się go uruchomić.

Najpierw zatrzymałem slapd za pomocą:

service slapd stop

Następnie uruchomiłem go w trybie debugowania:

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

Ważne jest, aby uruchomić go TYLKO za pomocą ldapi: /// URL. Po jego uruchomieniu wykonałem polecenie ldapmodify, a atrybuty zostały zaimportowane.

Na koniec zatrzymałem tryb debugowania i uruchomiłem slapd normalnie.

W odpowiedzi na odpowiedź A. Gutierreza najlepszym sposobem na sprawdzenie dostępu do każdego pliku jest uruchomienie sudo -u openldap cat <filename>. Przeglądałem wszystkie pliki wiele razy, a one wyglądały na poprawnie ustawione uprawnienia. Okazało się, że jest to problem grupowy dla openldap. Gdy w końcu to zrozumiałem, proste sudo usermod -a -G ssl-cert openldaprozwiązanie dla mnie.

Czasami problem leży w profilu apparmor dla usługi slapd. Upewnij się, że profil Apparmor zezwalał na ścieżki certyfikatów dla demona.

Jest całkiem wizualnie /etc/apparmor.d/usr.sbin.slapd. Domyślnie ten profil umożliwia odczyt certyfikatów w domyślnych lokalizacjach.

Apparmor powinien zapobiegać nieokreślonym działaniom wykonywalnym demona, pomimo odpowiednich uprawnień uniksowych.

Jak zgłosiłem w tym błędzie na Ubuntu Launchpad , ten problem może być również spowodowany przez apparmor. Zwykle będzie to widoczne w dzienniku systemowym jako odmowa dostępu.

Poprawka wstawia następujący wiersz w /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

a następnie odświeżanie profilu:

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

Mam również ten problem. Problem polega na tym, że użytkownik uruchamiający slapd didnt ma dostęp do plików certyfikatów. Sprawdź, że właścicielem tych plików jest użytkownik openldap.

Dla mnie problem był w niewłaściwej kolejności zapisów - oto ten, który zadziałał:

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

Niestety wydaje się, że jest to „domyślny” błąd, który pojawia się praktycznie w każdym przypadku. Odpowiedź @ wulfsdad zazwyczaj to naprawia.

Inną rzeczą, o której zawsze zapominam, jest to, że domyślnie na ubuntu slapd chce klucza w formacie openssl. Zazwyczaj używam do tego kluczy PCKS # 8 i oczekuję, że po prostu zadziała (co powinno być sprawiedliwe). Jeśli wypróbowałeś wszystkie powyższe odpowiedzi, upewnij się, że klucz ma odpowiedni format. Kiedy googlujesz na temat błędu, zwykle czytasz o złych uprawnieniach i pocierasz głowę, dlaczego apache działa z tym samym kluczem, którego nie lubi slapd.