Не могу понять, почему Apache LDAP аутентификации не удается

Внезапно вчера один из моих серверов apache не смог подключиться к моему серверу LDAP (AD). У меня на этом сервере работает два сайта, каждый из которых использует LDAP для аутентификации на моем сервере AD, когда пользователь входит в систему на любом из этих сайтов. Это работало нормально два дня назад. По неизвестным причинам со вчерашнего дня он перестал работать. Журнал ошибок только говорит это:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

Я подумал, что, возможно, срок действия моего самоподписанного сертификата SSL истек, поэтому я создал новый для mysite.com, но не для самого имени хоста сервера, и проблема осталась. Я включил ведение журнала уровня отладки. Он показывает полную SSL-транзакцию с сервером LDAP и завершается без ошибок до самого конца, когда я получаю сообщение "Не удается связаться с LDAP-сервером". Я могу запустить ldapsearch из командной строки на этом сервере и войти на него, который также использует LDAP, поэтому я знаю, что сервер может подключаться и запрашивать сервер LDAP/AD. Только Apache не может подключиться.

Погуглил для ответа ничего не получилось, поэтому и спрашиваю здесь. Кто-нибудь может дать представление об этой проблеме?

Вот раздел LDAP из конфигурации Apache:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>

13 ответов

Трассировка пакетов от сервера httpd / клиента LDAP обнаружила сообщение о том, что ЦС неизвестен.

Оповещение TLSv1 (уровень: фатальный, описание: неизвестный ЦС)

Я нашел и добавил следующую опцию в мой httpd.conf:

  LDAPVerifyServerCert          off

Это решило мою проблему под CentOS 6. Серверы CentOS 5 httpd не требовали каких-либо изменений и работали без опций.

У меня была проблема, похожая на эту, с AD в Windows 2003: решение, которое я нашел, состояло в том, чтобы не связывать с использованием полного DN, а вместо этого использовать синтаксис [email protected]:

AuthLDAPBindDN [email protected]

Для работы с LDAPS необходимо навязать сертификат LDAP CA

Я видел это, когда обновление пакета вызывает изменения в клиентском ldap.conf (обычно /etc/ldap.conf или /etc/openldap/ldap.conf) и сбрасывает параметр TLS_REQCERT в более строгую настройку. Он может правильно согласовать SSL, но в конце все равно не сможет выполнить проверку, поскольку не может проверить цепочку сертификатов из доверенного корня.

У вас есть доступ к журналам с вашего сервера LDAP? Они могут быть полезны для устранения этой проблемы.

Возможно, вы захотите проверить часы серверов. Если разница во времени превышает пару минут, билет аутентификации будет недействительным.

Хотя это не совсем сообщение об ошибке, часть "другой сервер внезапно получает ту же проблему" может указывать на такую ​​проблему.

У меня была похожая проблема. Я мог получить сертификат с openssl, я мог запросить Active Directory через SSL с ldapsearch на тех же портах. Наконец я переключился на порты глобального каталога Microsoft 3268 или 3269, и они оба работали. Серверы Microsoft Windows 2003 были исправлены, но это произошло за несколько дней до появления проблем.

Я только что имел эту проблему ("не могу связаться с сервером LDAP") на RHEL6, и это было результатом изменений в openldap. yum обновил файл конфигурации /etc/openldap/ldap.conf, но вместо того, чтобы перезаписать его (если он был настроен; в моем случае это не так), он создал файл ldap.conf.rpmnew.

Копирование версии.rpmnew поверх ldap.conf решило проблему.

(Я не могу согласиться с тем, что отключение проверки сертификата является ответом на это. Это позволяет избежать проблемы потенциально опасным способом.)

Мне удалось решить эту проблему, установив berkelydb а также openldap пакеты найдены здесь.

Разница в том, что RedHat начал связывать вещи против nss вместо openssl для поддержки SSL. В этом случае это ломает все вещи. Установка этих пакетов (которые связаны с openssl) решает проблему. Просто получите пакеты и запустите:

yum install berkeleydb-ltb* openldap-ltb*

Затем перезапустите Apache, и вы должны быть в бизнесе.

Я предполагаю, что в ваших экспериментах из командной строки использовался тот же "пользователь привязки", что и в ваших конфигах apache. Если нет, вы должны проверить, что у вас есть правильный текущий пароль.

Раньше мне приходилось использовать порт глобального каталога вместо стандартного порта LDAP для домена AD. Я не могу вспомнить причину почему. Для ldaps, как в вашем URL выше, это будет порт 3269.

Это работает так, что вашему веб-сайту необходимо сначала подключиться к AD, используя учетные данные вашего пользователя bind, а затем, как только это соединение будет установлено, он использует этот доступ для проверки учетных данных пользователя, пытающегося получить доступ к вашему веб-сайту.

Согласно вашему сообщению об ошибке, похоже, что процесс не может подключиться к AD как пользователь привязки (AuthLDAPBindDN).

Убедитесь, что учетная запись привязанного пользователя не отключена в Active Directory, и что пароль, который вы указали как (AuthLDAPBindPassword), является правильным. Кроме того, убедитесь, что ваш пользователь bind имеет необходимые разрешения для поиска других пользователей (в нашем случае он должен быть членом Domain Users)

У меня есть похожая проблема, которую я обнаружил, выполнив эту команду:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1, Я думаю, что mod_ldap использует openssl внизу, так что это должно быть достаточно согласованным для отладки.

Я сравнил его с другим зашифрованным сервером SSL, который, как я знал, работал. Правильно проверенное соединение SSL покажет цепочку, идущую к корневому ЦС, и вернет 0. Сбой проверки SSL даст номер и причину. Вы можете использовать вывод, чтобы определить, что происходит не так.

В моем случае сертификаты сервера LDAP подписаны Verisign, который использует сертификаты промежуточного ЦС. OpenSSL не может проверить сертификат, и в соединении отказано ("соединение отклонено сервером" бесполезно).

Я реализовывал LDAPS на всех наших серверах и столкнулся с этой проблемой. Исчезнет ли он, если вы вернетесь к незашифрованному LDAP (не идеально, но полезно знать источник проблемы). Если так, то мне еще предстоит найти решение, но, возможно, вместе мы сможем выделить ошибку в authnz_ldap.

Другие вопросы по тегам