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

Отладка тайм-аута с помощью 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 разрешается для нескольких контроллеров домена, но поведение остается таким же, если я подключаюсь к определенному DC.

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

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

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

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

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

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

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

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

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

LDAPConnectionPoolTTL 0

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

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