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

не могу понять, почему не удается выполнить аутентификацию 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.

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

Вот раздел 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>

Трассировка пакета от httpd-сервера / LDAP-клиента выявила сообщение о том, что CA неизвестен.

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

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

  LDAPVerifyServerCert          off

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

У меня была проблема, аналогичная этой, раньше с AD в Windows 2003: я нашел решение не связывать с использованием полного DN, а вместо этого использовать синтаксис user @ domain:

AuthLDAPBindDN user@domain.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня только что возникла эта проблема («не могу связаться с сервером 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, и все будет в порядке.

У меня возникла такая же проблема после обновления с rhel6.6 до rhel7.5. Когда у меня не было идей, я пришел к выводу, что mod_ssl на apache 2.2.32 может быть не на 100% совместим с rhel7.4. Я обновился с Apache 2.2.32 до Apache2.4, включил SSL, и sldap работал.