Uwierzytelnianie OpenLDAP TLS

10

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
Amar Prasovic
źródło
Sprawdź uprawnienia do plików certyfikatów. A także usuń hasło, jeśli takie jest ustawione.
zeridon
Dzięki za szybką odpowiedź. Uprawnienia są ustawione na 644, z wyjątkiem pliku .key, który jest na 600. Jak mogę sprawdzić / usunąć hasło? Nie pamiętam, aby ustawiać hasło dla cn = config ..
Amar Prasovic,
2
Mam na myśli hasło do samego certyfikatu (nie do cn = config). Sprawdź: mnx.io/blog/removing-a-passphrase-from-an-ssl-key
zeridon
Nie, tak nie było. Plik klucza został utworzony bez hasła.
Amar Prasovic,
czy możesz spróbować załadować ldiff za pomocą prostego uwierzytelnienia (nie -Y EXTERNAL)
zeridon

Odpowiedzi:

17

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
Hildigerr
źródło
1
To też działało dla mnie!
sonicwave,
2
W moim przypadku musiałem użyć chgrp openldap. W każdym razie jest to kwestia pozwolenia. +1
xonya
również katalog prywatny musi być wykonywalny, aby przejść. sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private
Jeff Puckett
3

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.

Amar Prasovic
źródło
2

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.

Rob Archibald
źródło
2

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.

Vskubriev
źródło
Jeśli używasz letsencrypt, jest to rozwiązanie. Dodaj następujące wiersze do /etc/apparmor.d/usr.sbin.slapd: / etc / letsencrypt / r, / etc / letsencrypt / ** r i ponownie załaduj profile Apparmor.
Bernhard
1

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
Tarek Loubani
źródło
0

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.

A. Gutierrez
źródło
0

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
Arie Skliarouk
źródło
0

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.

użytkownik3240383
źródło