Отладка таймаута с помощью ldap auth на apache

Я пытаюсь отладить проблему тайм-аута, которая у меня есть с Apache, уже несколько месяцев.

Шаблон выглядит так:

При каждом первом запросе нового сеанса (или через некоторое время после последнего запроса) браузер немедленно запрашивает учетные данные, а затем отправляет запрос с базовой аутентификацией. Затем сервер ждет ровно 1 минуту перед отправкой результата.

Последующие запросы отвечают мгновенно, это происходит только для запросов через какое-то время (точно не могу определить это точно, между 5 и 15 минутами).

Тот факт, что время ожидания воспроизводимо ровно 60 секунд, пахнет для меня как тайм-аут. Если я отменяю запрос и нажимаю перезагрузить, я немедленно получаю запрошенный URL.

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

Обратите внимание, что аутентификация всегда проходит успешно, поэтому я могу исключить проблему "контроллер домена не ответил".

Apache 2.4 работает на Windows Server 2012 R2. Это настроено для аутентификации LDAP:

<Location />
    AuthType Basic
    AuthName "AD Login"
    AuthBasicProvider ldap
    LDAPReferrals Off
    #AuthLDAPUrl ldap://dc01.domain.de:3268/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*)
    #AuthLDAPUrl ldap://ad.domain.de:389/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*) STARTTLS
    AuthLDAPUrl ldap://ad.domain.de:389/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*) TLS
    AuthLDAPBindDN "service@domain.de"
    AuthLDAPBindPassword "secret"
    Require valid-user
    Require all denied
</Location>

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

ad.domain.de разрешается для нескольких контроллеров домена, но поведение такое же, если я подключаюсь к определенному контроллеру домена.

Нет записей в журнале ошибок LogLevel info Я пока не решаюсь увеличить его до debug, как я знаю из опыта, у меня проблемы с просеиванием сгенерированной отладочной информации.

Есть ли что-то, что я пропустил, но который я могу использовать для отладки проблемы, или мне нужно пройти протоколирование уровня отладки?

Источник

1 ответ

Решение

После увеличения уровня журнала для модулей authnz_ldap а также ldap следующее сообщение об ошибке появилось в журнале ошибок:

Тайм-аут для ldap_simple_bind() при повторном использовании соединения, сброшенный брандмауэром?

Это привело меня к этому отчету об ошибке mod_ldap, который, хотя и оказался ошибкой конфигурации, указал на реальную проблему:

Как сообщалось в другом месте, Windows закрывает соединение LDAP через 900 секунд, но поведение Apache по умолчанию, по-видимому, пытается повторно использовать соединение в течение неопределенного времени. Если Apache попытается использовать повторно после того, как Windows закроет соединение, существует 60-секундная задержка, ожидающая истечения времени ожидания соединения [...]

Выполните несколько быстрых проверок, чтобы подтвердить это:

Значение по умолчанию MaxConnIdleTime в Microsoft LDAP Policies это 900 секунд, что совпадает с моим наблюдением, что проблема появляется снова через 15 минут. 60-секундная задержка также точно соответствует моей проблеме.

Согласно этому сообщению об ошибке, проблема должна быть решена путем установки LDAPConnectionPoolTTL до значения ниже, чем MaxConnIdleTime и кроме значения по умолчанию -1, но это не сработало для меня. Я должен был установить значение 0, отключив повторное использование существующих подключений.

LDAPConnectionPoolTTL 0

Я не ожидаю каких-либо проблем с производительностью, поскольку результаты ldap все равно кэшируются.

Единственное, что остается загадкой, это то, почему эта проблема возникает только на нашем экземпляре Apache, работающем в Windows, но не на экземплярах Apache, работающих на Linux.

Источник
Другие вопросы по тегам