Niektóre systemy nie mogą połączyć się z ldap za pomocą ldaps, ale inne mogą, czy to jest symbol zastępczy?

Kiedy próbuję nawiązać połączenia ldaps z moim serwerem Novel eDirectory 8.8, czasami muszę umieścić TLS_REQCERT neverplik ldap.conf serwerów klienta. Oczywiście jest to zły pomysł.

Polecenie, które uruchamiam, jest podobne do tego z poświadczeniami, które faktycznie działają ...

ldapsearch -x -H ldaps://ldapserver -b 'ou=active,ou=people,dc=example,dc=org' -D 'cn=admin,dc=example,dc=org' -W "cn=username"

W systemie Ubuntu 13.10 działa dobrze.

W SLES działa dobrze.

W CentOS 6.5 zwraca:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Teraz certyfikat, który zaimportowałem, jest certyfikatem zastępczym zakupionym w DigiCert. Mój współpracownik znalazł kilka raportów wskazujących, że niektóre systemy mają problemy z symbolami wieloznacznymi.

Więc czy winą za to jest wildcard? Jeśli tak, jak to naprawić?

Jeśli nie jest to znak zastępczy, to co to jest?

Zgodnie z sugestią Andrew Schulmana dodałem -d1do mojej komendy ldapsearch. Oto, z czym skończyłem:

ldap_url_parse_ext(ldaps://ldap.example.org)
ldap_create
ldap_url_parse_ext(ldaps://ldap.example.org:636/??base)
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.example.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.225.0.24:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap' tokenDescription='ldap(0)' certPrefix='cacerts' keyPrefix='cacerts' flags=readOnly
TLS: cannot open certdb '/etc/openldap', error -8018:Unknown PKCS #11 error.
TLS: could not get info about the CA certificate directory /etc/openldap/cacerts - error -5950:File not found.
TLS: certificate [CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 2 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Z tego, co mówi, CentOS nie ufa DigiCert? Czy CentOS nie ma listy zaufanych emitentów?

ssl-certificate ldap edirectory

— David R.
źródło

„Nie można skontaktować się z serwerem LDAP” brzmi bardziej tak, jakby serwer nie był dostępny z tego komputera klienckiego. Czy najpierw sprawdziłeś, czy możesz się z nim połączyć? Np telnet ldapserver ldapslub openssl s_client -connect ldapserver:636.

— Richard E. Silverman

Tak, potwierdziłem, że można połączyć się z serwerem. W końcu nigdy by nie działało, gdyby w ogóle nie mogło się połączyć.

— David R.

Wspomniałeś o trzech różnych hostach klientów. Ten, który nie działa, mógł nie być w stanie połączyć się z powodu problemu z siecią, podczas gdy inni mogli.

— Richard E. Silverman

Myślałem, że mój post był całkiem jasny, że edytuję plik ldap.conf na wszystkich hostach. Tak jak wtedy, gdy dodałem linię do pliku, zadziałało, ale bez linii nie. Dlatego nie ma problemu z połączeniem.

— David R.

To nie było dla mnie jasne, kiedy początkowo czytałem twój post, choć rozumiem, co masz na myśli teraz. W każdym razie dodane informacje o debugowaniu TLS pokazują problem; Dodałem odpowiedź do dalszych działań.

— Richard E. Silverman

Odpowiedzi:

ldapsearch szuka w / etc / openldap / cacerts swojego magazynu zaufanych certyfikatów CA, który najwyraźniej nie jest skonfigurowany, a zatem odrzuca certyfikat, ponieważ nie może zbudować dla niego łańcucha zaufania. Gdyby ldapsearch używał OpenSSL, potrzebowałby kolekcji w formacie „hashdir” wytworzonej np. Przez program „authconfig” Red Hat lub pojedynczy plik z płaską listą zaufanych certyfikatów. Odwołanie się tutaj do „moznss” sugeruje, że to ldapsearch jest zbudowane na Mozilli NSS, w którym to przypadku musisz użyć „certutil”, aby uzyskać certyfikat db (lub lepiej, skieruj go na systemową bazę certyfikatów NSS, jeśli taka istnieje) .

W systemach, w których działa, ldapsearch musi mieć działający magazyn certyfikatów, być może dlatego, że te pakiety OpenLDAP są zbudowane w oparciu o OpenSSL (a może dostępny jest działający magazyn w stylu NSS).

— Richard E. Silverman
źródło

Ach /etc/openldap/certsjest tam, gdzie jest sklep z certyfikatem. Nie zawracam sobie głowy. W /etc/openldap/ldap.conf zmieniłem TLS_CACERTDIR /etc/openldap/cacertsna TLS_CACERTDIR /etc/openldap/certsi moja komenda ldapsearch zaczęła działać. Dzięki!

— David R.

Mam zainstalowany ldapsearch na Ubuntu 16.04 i nie ma katalogu / etc / openldap.

— vcardillo

ldapsearch powie „Nie można skontaktować się z serwerem LDAP”, jeśli nie może zweryfikować certyfikatu TLS. Dodaj -d1do polecenia ldapsearch i sprawdź linie wyjściowe zaczynające się od „TLS:”, aby uzyskać więcej informacji o tym, czy połączenie TLS nie działa i dlaczego.

— Andrew Schulman
źródło

Zredagowałem moje pytanie w odpowiedzi na twoją sugestię. Dzięki!

— David R.

Rozwiązanie zależy od instalacji:

Jeśli używasz niepoprawnego certyfikatu , możesz wymusić akceptację konfiguracji za /etc/openldap/ldap.confpomocą
```
TLS_REQCERT allow
```
lub
```
TLS_REQCERT never
```
Jeśli używasz ważnego certyfikatu, prawdopodobnie Twoja instalacja ldap nie wie, gdzie znajduje się magazyn zaufanych certyfikatów CA (prawdopodobnie w zależności od instalacji OpenSSL). Następnie możesz spróbować ustawić lokalizację i wymusić sprawdzenie konfiguracji za /etc/openldap/ldap.confpomocą
```
TLS_CACERT /etc/openldap/cacert
TLS_REQCERT demand
```
/etc/openldap/cacertmoże być tym lub znajdować się na dowolnej ścieżce. Musi zawierać łańcuch certyfikatów Twojego urzędu certyfikacji. Może to być pojedynczy plik z płaską listą zaufanych certyfikatów.

Uwaga ścieżki zależą od dostawcy LDAP. To może być /etc/ldaplub /etc/openldapczy tak.

— Juan Garcia
źródło