LDAPS-соединение успешно выполняется без параметра «tls_cacertdir» в nslcd.conf

У меня есть сервер OpenLDAP в моей серверной среде, и у меня есть еще два сервера [два клиента LDAP], которые я настроил с моим сервером LDAP для входа пользователя. Мой сервер LDAP - поддерживает только LDAPS (порт: 636) и не поддерживает LDAP (порт: 389). Но моя проблема в том, что с одного из моих клиентов LDAP я удалил директиву tls_cacertdir из nslcd.conf и разрешил пользователям входить в него конкретный сервер [сервер настроен для связи с сервером LDAP через LDAPS (порт: 636). обычный LDAP (порт: 389) отключен]. Удивительно, но этот сервер позволяет пользователям входить на сервер. но в то же время я удалил " tls_cacertdir "от другого клиента LDAP, тогда он не позволял пользователям входить в систему на сервере, и была ошибка, говорящая, что не удается подключиться к серверу LDAP. Теперь я немного запутался, почему я испытываю два разных поведения этих двух клиентов LDAP. Кроме того, я беспокоюсь, потому что Теперь я сомневаюсь, что LDAP на самом деле общается через LDAPS или нет. Может кто-нибудь объяснить мне, почему это происходит?

Server A : [this LDAP client will reject user login when I remove "tls_cacertdir" directive from the nslcd.conf]
openldap-clients.x86_64            2.4.44-5.el7
nss-pam-ldapd.x86_64               0.8.13-8.el7


Server B : [this LDAP client will NOT reject user login when I remove "tls_cacertdir" directive from the nslcd.conf]
openldap-clients.x86_64       2.4.44-21.el7_6
nss-pam-ldapd.x86_64          0.8.13-16.el7_6.1

В некоторых местах я читал, что когда slapd использует GnuTLS, "tls_cacertdir" игнорируется. но затем я проверил slapd [см. дамп ниже]. он не использовал GnuTLS. Затем я просто удалил каталог «/ etc / pki / tls» и попытался войти в систему. тогда «сервер B» не разрешал пользователям входить в систему. LDAPS-соединение не удалось. Может кто-нибудь объяснить, почему это происходит?

[root@xxx-xxx-xx ~]$ ldd /usr/sbin/slapd
    linux-vdso.so.1 =>  (0x00007ffc7ed3a000)
    libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f58caea9000)
    liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f58cac9a000)
    libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f58ca8dc000)
    libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f58ca6bf000)
    libnss3.so => /lib64/libnss3.so (0x00007f58ca392000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f58ca176000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f58c9f3f000)
    libslapi-2.4.so.2 => /lib64/libslapi-2.4.so.2 (0x00007f58c9d1f000)
    libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f58c9b15000)
    libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f58c990a000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f58c953d000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f58c9324000)
    libssl3.so => /lib64/libssl3.so (0x00007f58c90d2000)
    libsmime3.so => /lib64/libsmime3.so (0x00007f58c8eab000)
    libnssutil3.so => /lib64/libnssutil3.so (0x00007f58c8c7c000)
    libplds4.so => /lib64/libplds4.so (0x00007f58c8a78000)
    libplc4.so => /lib64/libplc4.so (0x00007f58c8873000)
    libnspr4.so => /lib64/libnspr4.so (0x00007f58c8635000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f58c8431000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f58cb573000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007f58c822e000)
    libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f58c8014000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f58c7e0c000)
0
задан 18 July 2019 в 17:39
1 ответ

Вы не сказали нам, какой дистрибутив Linux вы используете. Но большинство из них поставляется с пакетом под названием ca-сертификаты (или аналогичным именем), в котором есть инструмент для создания общесистемного хранилища доверенных сертификатов (каталог CA и файл пакета CA). libldap используется в качестве хранилища доверенных сертификатов по умолчанию, если не указано иное.

Поэтому я подозреваю, что в ваших двух системах были разные хранилища доверенных сертификатов по умолчанию.

0
ответ дан 23 November 2019 в 22:47

Теги

Похожие вопросы