Аутентификация Apache через LDAP не удается для паролей с умлаутами.

Вопрос или проблема

При аутентификации через LDAP (Active Directory, Server 2008) с сервера Apache в журнале ошибок появляется следующее сообщение:

authentication failure for "https://serverfault.com/": Password Mismatch

Это происходит только тогда, когда пароль содержит немецкие умлауты (ä, ö, ü). После смены пароля или попытки войти с другой учетной записью без умлатов аутентификация работает нормально.

Вот моя конфигурация:

AuthType Basic
AuthzLDAPAuthoritative off
AuthLDAPURL "ldap://[SERVER]:3268/DC=[DOMAIN]?sAMAccountName?sub?(objectClass=user)"
AuthLDAPBindDN       "user"
AuthLDAPBindPassword "pass"
require valid-user

Я использую Apache2 (2.2.16-6+squeeze1) под управлением Debian (2.6.26-2-686). Забавно, что приведенная выше конфигурация работала до вчерашнего дня (даже с паролями с умлатами), и я её не трогал (клянусь 😉 ). Я уже нашёл других людей с такой же проблемой, но без решения.

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

С наилучшими пожеланиями,
Стефан

Похоже, что где-то происходит проблема с кодировкой. Я не могу сказать вам, где именно, но могу предложить, как это найти.

Насколько я понимаю, есть 5 мест, где кодировка может обрабатываться или интерпретироваться неправильно. Это:

  1. Браузер, преобразующий символы в байты для отправки на веб-сервер
  2. Apache, понимающий эти байты для формирования строки пароля
  3. Apache + OpenLDAP, преобразующие строку пароля в байты для отправки на LDAP сервер
  4. Active Directory, преобразующий байты в запросе привязки LDAP в нечто, что можно сравнить с его базой данных паролей
  5. Active Directory, преобразующий символы в байты при установке пароля пользователя

Предполагая, что вы можете войти в Windows как этот пользователь, мы знаем, что пункт #5 не является вашей проблемой. Вам нужно выяснить, на каком этапе возникает проблема. Мое предположение, что это происходит на шагах 2 или 3, но я не могу быть уверен.

Сначала убедитесь, что вы не используете https для общения с веб-сервером, и не используете ldaps для связи с LDAP сервером. (Возможно, вам этого не нужно для производственной среды, но это упрощает работу). Теперь используйте Wireshark для анализа трафика на двух участках, браузер -> Apache и Apache -> AD. Вы видите там правильную информацию?

Затем установите уровень логирования в Apache на debug и посмотрите, что там печатается. Это не покажет вам пароль, но на уровне отладки должно показывать другую информацию, такую как имя пользователя. Если вы используете фиктивное имя пользователя с акцентами, правильно ли они отображаются?

Как только вы определите шаг, на котором происходит сбой кодирования, вы будете на 90% близки к решению!

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

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

В mod-enabled/ldap.conf у меня установлена директива AuthLDAPCharsetConfig

LDAPVerifyServerCert on
LDAPTrustedMode TLS
LDAPTrustedGlobalCert CA_BASE64 /etc/apache2/certs/ca-chain.crt
AuthLDAPCharsetConfig conf-enabled/charset.conv
<Location /ldap-status>
        SetHandler ldap-status
        Require local
</Location>

Но файл charset.conv содержал что-то вроде этого (вероятно, из примера, который я нашёл в интернете)

# Lang-abbv Charset     Language
#---------------------------------
en          ISO-8859-1  English
UTF-8       utf8        UTF-8
Unicode     ucs         Unicode
th          Cp874       Thai
ja          SJIS        Japanese
ko          Cp949       Korean
zh          Cp950       Chinese-Traditional
zh-cn       GB2312      Chinese-Simplified
zh-tw       Cp950       Chinese
cs          ISO-8859-2  Czech
hu          ISO-8859-2  Hungarian
hr          ISO-8859-2  Croation
...
uk          ISO-8859-5  Ukrainian
ca          ISO-8859-1  Catalan
de          ISO-8859-1  German
...

После некоторых попыток и ошибок, и выяснив, что браузер отправляет пароль в кодировке utf-8, следующий содержимое charset.conv работает для умлатов и других специальных символов в паролях:

# Lang-abbv Charset     Language
#---------------------------------
en          utf8        English
UTF-8       utf8        UTF-8
Unicode     ucs         Unicode
th          Cp874       Thai
ja          SJIS        Japanese
ko          Cp949       Korean
zh          Cp950       Chinese-Traditional
zh-cn       GB2312      Chinese-Simplified
zh-tw       Cp950       Chinese
cs          utf8        Czech
hu          utf8        Hungarian
hr          utf8        Croation
pl          utf8        Polish
ro          utf8        Romanian
sr          utf8        Serbian
sk          utf8        Slovak
sl          utf8        Slovenian
sq          utf8        Albanian
bg          utf8        Bulgarian
be          utf8        Byelorussian
mk          utf8        Macedonian
ru          utf8        Russian
uk          utf8        Ukrainian
ca          utf8        Catalan
de          utf8        German
da          utf8        Danish
fi          utf8        Finnish
fr          utf8        French
es          utf8        Spanish
is          utf8        Icelandic
it          utf8        Italian
nl          utf8        Dutch
no          utf8        Norwegian
pt          utf8        Portuguese
sv          utf8        Swedish
af          utf8        Afrikaans
eu          utf8        Basque
fo          utf8        Faroese
gl          utf8        Galician
ga          utf8        Irish
gd          utf8        Scottish
mt          utf8        Maltese
eo          utf8        Esperanto
el          utf8        Greek
tr          utf8        Turkish
he          utf8        Hebrew
iw          utf8        Hebrew
ar          utf8        Arabic
et          utf8        Estonian
lv          utf8        Latvian
lt          utf8        Lithuanian

Примечание: Я не трогал восточноазиатские языки, поскольку они не актуальны для моего случая использования, и я не мог их протестировать.

Ответ или решение

Введение

Проблема аутентификации Apache с использованием LDAP (Active Directory, Server 2008) может иметь множество источников, особенно когда дело касается обработки паролей, содержащих специальные символы, такие как немецкие умлачты (ä, ö, ü). Когда возникает ошибка "Password Mismatch", это может быть связано с неверной кодировкой данных на одном из этапов обработки. В данной статье мы рассмотрим основные области, где может происходить сбой, и предложим решения, которые помогут вам успешно пройти аутентификацию.

Возможные источники проблемы

  1. Обработка на стороне браузера: Первым этапом является преобразование символов в байты для передачи на веб-сервер. Если браузер некорректно кодирует символы, это может привести к ошибке.

  2. Apache и преобразование пароля: Apache должен правильно интерпретировать байты, полученные от браузера, чтобы сформировать строку пароля. Неправильная обработка на этом этапе может вызвать ошибки аутентификации.

  3. OpenLDAP и передача пароля: Apache использует модуль OpenLDAP для взаимодействия с LDAP-сервером. Ошибка может произойти, если OpenLDAP некорректно преобразует строку пароля в байты для отправки на LDAP-сервер.

  4. Обработка на Active Directory: На стороне Active Directory пароли также преобразуются в байты для сравнения с базой данных паролей. Неверная интерпретация может привести к проблемам с аутентификацией.

  5. Задание пароля в Active Directory: Если при установке пароля не было учтено правильное кодирование, это может вызвать проблемы в будущем.

Шаги для диагностики и решения проблемы

  1. Подключение без шифрования: Оптимально временно отключить HTTPS для веб-сервера и LDAPS для LDAP-сервера, чтобы упростить диагностику.

  2. Сниффинг трафика: Используйте такой инструмент, как Wireshark, для анализа трафика между браузером и Apache, а также между Apache и Active Directory. Ознакомьтесь с передаваемыми данными, чтобы выявить возможные несоответствия.

  3. Уровень логирования Apache: Установите уровень логирования на debug, чтобы увидеть дополнительные сведения о транзакциях, такие как пользовательские имена. Это поможет выяснить, появляются ли ошибки при обработке специализированных символов.

  4. Проверка настройки кодировки: Ваша конфигурация Apache может нуждаться в корректировке. Один из ключевых параметров – это AuthLDAPCharsetConfig, устанавливающий правильную кодировку при взаимодействии с LDAP.

Рекомендация по настройке charset.conv

Для решения проблемы, связанной с умлачты в паролях, попробуйте обновить файл charset.conv следующим образом:

# Lang-abbv Charset     Language
#---------------------------------
en          utf8        English
UTF-8       utf8        UTF-8
Unicode     ucs         Unicode
...
de          utf8        German
...

Это гарантирует, что Apache будет ожидать входные данные в кодировке UTF-8, что позволяет корректно обрабатывать специальные символы и умлачты в паролях.

Заключение

Аутентификация через LDAP в Apache может быть сложной задачей, особенно когда дело касается многосимвольных паролей. Правильная диагностика проблемы и настройки конфигурации сервера могут значительно упростить процесс. Инструменты мониторинга и корректная установка кодировки обеспечат беспрепятственный доступ пользователей к вашим ресурсам.

Оцените материал
Добавить комментарий

Капча загружается...