У меня установлен OpenLDAP 2.4.50 в системе Alpine 3.8 и два клиента Debian 10 - назовем их A и B - пытаются подключиться к серверу ldap. Моя проблема в том, что первый может, а второй нет.
A и B - идентичные машины, на обеих установлена последняя версия Debian 10. Клиент A может подключать сервер ldap с ldapsearch -x -b "dc=mydomain,dc=tld" -H ldaps://ldap.mydomain.tld/, но клиент B не работает. Вот что показывает сервер, когда клиент B пытается подключиться:
Jul 16 12:46:39 reglisse local4.debug slapd[17451]: conn=1132 fd=22 ACCEPT from IP=xxx.xxx.xxx.xxx:45444 (IP=0.0.0.0:636)
Jul 16 12:46:39 reglisse local4.debug slapd[17451]: conn=1132 fd=22 TLS established tls_ssf=256 ssf=256
Jul 16 12:46:39 reglisse local4.debug slapd[17451]: conn=1132 fd=22 closed (connection lost)
certbot.ldapsearch -x -b "dc=mydomain,dc=tld" -H ldap://ldap.mydomain.tld/ -v. Это должно доказать, что проблемы с сетью нет и что сервер правильно прослушивает порт 389.openssl s_client -connect ldap.mydomain.tld:636 -showcerts. Это должно доказать, что сервер правильно слушает порт 636.ldap-utils установленная версия пакета и ldd /usr/bin/ldapsearch показывает, что оба двоичных файла построены на основе одних и тех же библиотек. Это должно доказать, что оба клиента идентичны.slapd.conf не имеет абсолютно ничего особенного:
suffix dc=mydomain,dc=tld
rootdn cn=admin,dc=mydomain,dc=tld
rootpw "xxxxxxxxxxx"
TLSCertificateKeyFile /etc/openldap/certs/privkey.pem
TLSCACertificateFile /etc/openldap/certs/fullchain.pem
TLSCertificateFile /etc/openldap/certs/cert.pem
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
Итак, что я здесь делаю не так?
Я обнаружил, что ldapsearch имеет -d вариант, показывающий интересные вещи:
$ ldapsearch -x -b "dc=mydomain,dc=tld" -H ldaps://ldap.mydomain.tld/ -v -d1
ldap_url_parse_ext(ldaps://ldap.mydomain.tld/)
ldap_initialize( ldaps://ldap.mydomain.tld:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://ldap.mydomain.tld:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.mydomain.tld:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 45.67.80.98:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Таким образом, кажется, что сертификат ldap сервера не пользуется доверием клиента B. Чтобы исправить эту проблему, мне пришлось установить следующую строку в /etc/ldap/ldap.conf.
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Некоторые люди могут решить подобные проблемы с помощью:
TLS_REQCERT allow
/etc/ldap/ldap.conf похоже, это файл конфигурации, который используют большинство клиентов ldap. У клиента A уже был этот файл, поэтому он сработал.