Как отладить аутентификацию SASL через LDAP в направлении активного каталога
Я пытаюсь настроить SASL, работающий на Centos 6.5, чтобы разрешить аутентификацию на корпоративном сервере активных каталогов. Конечная цель - аутентифицировать доступ к некоторым репозиториям 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?
2 ответа
В конце концов я не смог заставить 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 прошла успешно.
Даже с-d, saslauthd не записывает отладочную информацию в стандартный вывод. Вместо этого он регистрируется в системном журнале с помощьюAUTHсредство.