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

Question

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

8

linux apache-2.2 ldap authentication

Источник

SethG 02 окт '09 в 19:45

13 ответов

Другие вопросы по тегам linux apache-2.2 ldap authentication

dmourati 15 сен '11 в 18:10 2011-09-15 18:10 · Answer 1 · 2011-09-15 18:10

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

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

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

  LDAPVerifyServerCert          off

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

Sam Kingston 05 ноя '09 в 23:30 2009-11-05 23:30 · Answer 2 · 2009-11-05 23:30

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

AuthLDAPBindDN [email protected]

Ger Apeldoorn 25 ноя '09 в 07:55 2009-11-25 07:55 · Answer 3 · 2009-11-25 07:55

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

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

Sum Buddy 10 янв '12 в 23:12 2012-01-10 23:12 · Answer 4 · 2012-01-10 23:12

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

tore- 16 мар '10 в 13:36 2010-03-16 13:36 · Answer 5 · 2010-03-16 13:36

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

shollyman 16 ноя '09 в 22:50 2009-11-16 22:50 · Answer 6 · 2009-11-16 22:50

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

Eric Dennis 02 окт '09 в 23:56 2009-10-02 23:56 · Answer 7 · 2009-10-02 23:56

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

jldugger 03 апр '10 в 03:15 2010-04-03 03:15 · Answer 8 · 2010-04-03 03:15

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

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

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

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

Brent 23 ноя '09 в 22:37 2009-11-23 22:37 · Answer 9 · 2009-11-23 22:37

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

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

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

Zac Thompson 27 окт '09 в 06:36 2009-10-27 06:36 · Answer 10 · 2009-10-27 06:36

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

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

Kyle Smith 16 окт '09 в 02:03 2009-10-16 02:03 · Answer 11 · 2009-10-16 02:03

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

22 май '20 в 22:38 2020-05-22 22:38 · Answer 12 · 2020-05-22 22:38

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

qhartman 02 авг '13 в 21:52 2013-08-02 21:52 · Answer 13 · 2013-08-02 21:52

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

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

yum install berkeleydb-ltb* openldap-ltb*

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

manyon 23 май '13 в 12:15 2013-05-23 12:15 · Answer 14 · 2013-05-23 12:15

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

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

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