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
Odpowiedzi:
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:
i
źródło
chgrp openldap
. W każdym razie jest to kwestia pozwolenia. +1sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private
Nie wiem, czy to rozwiązanie, czy tylko obejście, ale udało mi się go uruchomić.
Najpierw zatrzymałem slapd za pomocą:
Następnie uruchomiłem go w trybie debugowania:
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.
źródło
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, prostesudo usermod -a -G ssl-cert openldap
rozwiązanie dla mnie.źródło
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.
źródło
/etc/apparmor.d/usr.sbin.slapd
: / etc / letsencrypt / r, / etc / letsencrypt / ** r i ponownie załaduj profile Apparmor.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:
źródło
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.
źródło
Dla mnie problem był w niewłaściwej kolejności zapisów - oto ten, który zadziałał:
źródło
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.
źródło