суббота, 30 марта 2013 г.

Apache и авторзация через NTLM

На днях настраивал авторизацию в Битриксе через NTLM у одного из заказчиков. Ну со стороны Битрикса всё просто, это не впервой. А вот со стороны веб-сервера всё оказалось значительно сложнее. К счастью, в Редхате оказался нужный модуль для апача нашёлся - это можуль mod_authnz_ldap. Есть ещё самопальный модуль, который называется mod_ntlm и который можно скачать с sourceforge, но его поддержка прекращена много лет назад и он не собирается из исходников - gcc говорит, что в исходниках ошибка. Итак, mod_authnz_ldap.

Простейший конфиг выглядит в случае, когда нельзя проводить поиск в AD анонимно, как-то так:
<Location />
AuthLDAPURL "ldap://ldap.server.local:389/DC=organization,DC=local?sAMAccountName?sub?(objectClass=*)" NONE
AuthLDAPBindDN "CN=poweruser,OU=ITDepartment,DC=organization,DC=local"
AuthLDAPBindPassword "пароль к AD"
require valid-user
</Location>
И он нифига не работает. Если просто так взять программу ldapsearch и посмотреть, что там лежит в AD, то всё работает. Апач найти не может ничего.

Кусок лога httpd:
[Fri Mar 29 18:08:12 2013] [debug] mod_authnz_ldap.c(403): [client 172.16.16.100] [4931] auth_ldap authenticate: using URL ldap://ldap.server.local/DC=organization,DC=local?sAMAccountName?sub?(objectClass=*)
[Fri Mar 29 18:08:18 2013] [info] [client 172.16.16.100] [4931] auth_ldap authenticate: user poweruser authentication failed; URI / [ldap_search_ext_s() for user failed][Operations error]

А вот то же самое, что должен делать апач, я делаю руками из консоли:
$ ldapsearch -v -x -W -D "CN=poweruser,OU=ITDepartment,DC=organization,DC=local" -h ldap.server.local -b "OU=ITDepartment,DC=organization,DC=local" "(objectClass=*)" sAMAccountName | grep poweruser
ldap_initialize( ldap://192.168.168.250 )
Enter LDAP Password:
filter: (objectClass=*)
requesting: sAMAccountName

poweruser, ITDepartment, organization.local
dn: CN=poweruser,OU=ITDepartment,DC=organization,DC=local
sAMAccountName: poweruser

То есть пользователь сам себя находит в AD, а вот апач его найти не может, хотя авторизуется под ним же. Какая-то странная ситуация. Я провёл несколько экспериментов и убедился, что на самом деле апач находит пользователя и работает нормально в том случае, если поиск проходит не по корню дерева AD!

AuthLDAPURL "ldap://ldap.server.local:389/OU=ITDepartment,DC=organization,DC=local?sAMAccountName?sub?(objectClass=*)" NONE

Это вот вполне работоспособный вариант, за исключением того, что авторизоваться смогут только пользователи, входящие в OU=ITDepartment. Чуть не плача я пошёл на stackoverflow ругаться на разработчиков апача, и обнаружил, что не я первый это обнаружил, а имеется целый археологический пласт под названием "как настроить NTLM-авторизацию в Apache и почему она не работает, хотя я сделал всё по мануалу". Там доходчиво объясняется, что апач действительно не может проводить поиск по корню дерева из-за каких-то там хреновин, которые там есть (я не очень хорошо понял, что имеется в виду), и которые можно отключить в настройках AD, либо - внимание, сейчас будет самое главное - использовать для поиска интерфейс глобального каталога для Microsoft(r)(tm)(c)(patent pending)(all rights reserved) AD, который расположен на порту 3268.

То есть вообще всё просто, надо было писать так:
AuthLDAPURL "ldap://ldap.server.local:3268/DC=organization,DC=local?sAMAccountName?sub?(objectClass=*)" NONE

И всё. Авторизация заработала. Правда, заказчик недоволен тем, что в браузере всё равно появляется модельное окно с просьбой ввести логин и пароль, но это уже совсем другая история (которая ещё на самом деле не закончилась).

Комментариев нет:

Отправить комментарий

Ублюдочный Гугл поломал форму комментариев. Извините.