Назад | Перейти на главную страницу

Невозможно использовать ВНЕШНЮЮ аутентификацию после включения TLS в ldap-2.4

Я использовал следующий файл LDIF, чтобы активировать поддержку TLS для сервера LDAP:

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL 
-
add: olcTLSCRLCheck
olcTLSCRLCheck: none
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/CA.crt
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/key.pem

и принудительно использовать TLS для клиентских подключений со следующим LDIF:

dn: cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

После этого я больше не могу использовать «-Y EXTERNAL» для чтения или изменения схемы конфигурации. Например, я получаю ошибку SASL, если запускаю:

$ sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
    additional info: SASL(-4): no mechanism available: 

и если я проверю поддерживаемые механизмы SASL:

$ sudo ldapsearch -x -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

Я действительно не вижу ВНЕШНЕГО, включенного в список. Что мне здесь не хватает?

Это на Ubuntu-12.04 и slapd-2.4.31.

Без доступа к работающей конфигурации вам придется остановить slapd и отредактируйте конфигурацию в автономном режиме.

  1. стоп slapd: service slapd stop
  2. выгрузите базу данных конфигурации в текстовый файл: slapcat -F /etc/ldap/slapd.d -b cn=config -l config.ldif
  3. переместите существующую базу данных конфигурации в сторону: mv /etc/ldap/slapd.d{,.old}
  4. создайте новую пустую базу данных конфигурации:

    mkdir /etc/ldap/slapd.d chown --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d chmod --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d

  5. редактировать сброшенные config.ldif убрать твой olcSecurity установка (или добавить olcRootDN и olcRootPW к cn=config, или любые другие изменения, которые вам нравятся)
  6. загрузить отредактированный LDIF в новую пустую базу данных: slapadd -F /etc/ldap/slapd.d -b cn=config -l config.ldif

(Выше предполагается, что ваша конфигурация находится в /etc/ldap/slapd.d, который используется по умолчанию в Debian и Ubuntu.)

Обратите внимание, что slapadd полный LDIF всегда должен выполняться в пустую базу данных; так что если вы ошиблись и slapadd не удается, обязательно очистите частичную базу данных перед повторной попыткой.

Вы можете найти больше информации в Руководство администратора OpenLDAP а также соответствующие страницы руководства.

Заглянем в код: на стороне сервера, в серверы / slapd / daemon.c, authid для EXTERNAL настраивается с использованием uid и gid вскоре после того, как входящее соединение accept()изд. Позже в серверы / slapd / connection.c, если TLS активен, он заменяет его именем из сертификата клиента. Поскольку вы не предоставляете клиентский сертификат, на этом этапе authid перезаписывается на NULL, что делает EXTERNAL недоступным.

Короче говоря, если TLS активен, то аутентификационный идентификатор uid + gid не используется. В зависимости от вашей точки зрения это можно считать ошибкой; в идеале он должен вернуться к указанному идентификатору.

Тем не менее, TLS на ldapi действительно не нужен, поскольку локальный сокет уже обеспечивает полную конфиденциальность; чтобы вы могли установить olcSecurity только в вашей базе данных, оставив его не настроенным для интерфейса и cn=config (см., например, эта почта), или вы можете использовать ssf= вместо того tls= и установить olcLocalSSF соответственно. Или вы можете использовать другой DN в качестве менеджера для cn=config, чтобы не зависеть от переданной функции.

Спасибо, rtandy. Я действительно не хотел устанавливать его на ldapi, но не знал, что это тоже повлияет.

Проблема в том, что ВНЕШНИЙ был единственным способом изменить cn=config так как я потерял этот доступ и не создавал другого cn=config admin, как было предложено, есть ли другой способ решить эту проблему?

Использование ldappi: /// вместо ldap: // решило проблему для меня после активации starttls в моей системе

sudo ldapmodify -Y EXTERNAL -H ldapi://  -f pwd2.ldif 

работает, тогда как

sudo ldapmodify -Y EXTERNAL -f pwd2.ldif 

сообщил

SASL / EXTERNAL аутентификация запущена ldap_sasl_interactive_bind_s: Неизвестный метод аутентификации (-6) дополнительная информация: SASL (-4): механизм недоступен: