не могу понять, почему 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>

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

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

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

  LDAPVerifyServerCert          off

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

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

AuthLDAPBindDN user@domain.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Убедитесь, что учетная запись привязанного пользователя не отключена в Active Directory, и что пароль, который вы указали как (AuthLDAPBindPassword), является правильным . Кроме того, убедитесь, что ваш пользователь bind имеет необходимые разрешения для поиска других пользователей (в нашем случае он должен быть членом 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 работал.