Я пытаюсь настроить SASL, работающий на Centos 6.5, чтобы разрешить аутентификацию на корпоративном сервере Active Directory. Конечная цель - аутентифицировать доступ к некоторым репозиториям Subversion, которые работают на этом сервере, но на данном этапе я просто пытаюсь заставить saslauthd аутентифицироваться и тестирую его с помощью testsaslauthd.
Аутентификация не выполняется каждый раз, и в журнале записывается следующее:
saslauthd[20843] :do_auth : auth failure: [user=MYUSER] [service=svn] [realm=MYREALM] [mech=ldap] [reason=Unknown]
saslauthd[20843] :do_request : response: NO
Это мой /etc/saslauthd.conf:
ldap_auth_method: bind
ldap_servers: ldaps://ldap.ad.mycompany.com:3269/
ldap_bind_dn: MYBINDDN
ldap_password: xxxxxxxxxx
ldap_search_base: DC=mycompany,DC=xx
ldap_filter: (&(cn=%u)(objectClass=person))
ldap_referrals: yes
log_level: 10
Обратите внимание, что я знаю, что URI сервера ldap, DN привязки, пароль, база поиска и фильтр верны, потому что у меня есть сценарий Perl, который использует их для аутентификации на веб-сайте, и он отлично работает. Сценарий perl использует Net :: LDAP, связывается с AD, ищет пользователя, используя базу поиска и фильтр, а затем пытается выполнить привязку, используя DN пользователя и пароль. Насколько я понимаю, это именно то, что SASL должен пытаться делать так, как я его настроил.
Мое первое наблюдение заключается в том, что, несмотря на то, что для log_level установлено значение 10, я получаю только одну строку, сообщающую мне, что произошел сбой по неизвестной причине. Я запускаю saslauthd из оболочки с параметром -d (отладка). Что еще я могу сделать, чтобы получить больше отладочных данных?
Есть ли способ зарегистрировать взаимодействие LDAP?
Наконец, может ли кто-нибудь увидеть что-нибудь не так с моей конфигурацией? Возможно, есть какие-то причуды AD, требующие особых настроек в конфигурации SASL?
В конце концов, я не смог заставить saslauthd выводить какую-либо лучшую отладочную информацию, но на случай, если это поможет кому-то еще, вот процесс, которому я следовал, чтобы решить свою проблему.
Сначала я запустил saslauthd с помощью strace, вот так:
# strace -f saslauthd -d -a ldap
Тогда я мог видеть все системные вызовы, сделанные saslauthd. Похоже, что при первоначальном обмене с сервером AD произошел сбой, возможно, во время согласования TLS.
Я решил посмотреть, смогу ли я воспроизвести подобное поведение с помощью инструмента командной строки ldapsearch, поставляемого с openldap. Я дал такую команду:
$ ldapsearch -d 9 -H ldaps://ldap.ad.mycompany.com:3269/ -D MYBINDDN -w xxxxxx \
-b DC=mycompany,DC=xx '(&(cn=myuser)(objectClass=person))'
Наконец, -d 9 дала мне полезный результат отладки:
TLS: certificate [CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US] is not valid - error -8179:Peer's Certificate issuer is not recognized..
Читая страницу руководства для ldap.conf, я обнаружил, что мне следует установить TLS_CACERT и / или TLS_CACERTDIR, чтобы они указывали на пакеты и файлы сертификатов. Я использую Centos 6, у которого они есть в / etc / pki / tls / certs /, поэтому я установил следующее:
TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt
TLS_CACERTDIR /etc/pki/tls/certs/
После этого ldapsearch работал, и после перезапуска saslauthd аутентификация на сервере AD прошла успешно.