Простейший конфиг выглядит в случае, когда нельзя проводить поиск в 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
И всё. Авторизация заработала. Правда, заказчик недоволен тем, что в браузере всё равно появляется модельное окно с просьбой ввести логин и пароль, но это уже совсем другая история (которая ещё на самом деле не закончилась).