Como depurar a autenticação SASL via LDAP em direção ao diretório ativo

Question

Estou tentando configurar o SASL em execução no Centos 6.5 para permitir a autenticação em direção ao servidor de diretório ativo corporativo. O objetivo final é autenticar o acesso a alguns repositórios de subversão que estão sendo executados neste servidor, mas, neste estágio, estou apenas tentando fazer com que o saslauthd seja autenticado e testando-o usando o testsaslauthd.

A autenticação falha sempre com o seguinte no log:

saslauthd[20843] :do_auth         : auth failure: [user=MYUSER] [service=svn] [realm=MYREALM] [mech=ldap] [reason=Unknown]
saslauthd[20843] :do_request      : response: NO

Este é o meu /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

Note que eu sei que o URI do servidor ldap, o DN de ligação, a senha, a base de pesquisa e o filtro estão corretos porque tenho um script perl que os usa para executar a autenticação de um site e funciona bem. O script perl usa Net :: LDAP, liga-se ao AD, procura o usuário usando a base de pesquisa e o filtro e, em seguida, tenta se conectar usando o DN e a senha do usuário. Pelo que entendi, é exatamente isso que o SASL deve estar tentando fazer da maneira que eu configurei.

Minha primeira observação é que, apesar de ter definido log_level para 10, recebo apenas uma linha dizendo que ela falhou com uma razão desconhecida. Eu estou começando saslauthd do shell com a opção -d (depuração). O que mais posso fazer para obter mais resultados de depuração?

Existe alguma maneira de registrar a interação LDAP?

Finalmente, alguém pode ver algo errado com minha configuração? Talvez algumas peculiaridades do AD que exigem configurações especiais na configuração do SASL?

    

Answer 1

No final, eu não consegui fazer com que o saslauthd gerasse informações de depuração melhores, mas no caso de ajudar alguém aqui, é o processo que eu segui para resolver o meu problema.

Primeiro comecei saslauthd com strace, assim:

# strace -f saslauthd -d -a ldap

Eu pude ver todas as chamadas do sistema sendo feitas pelo saslauthd. Parecia que estava falhando durante a troca inicial com o servidor AD, possivelmente durante a negociação TLS.

Eu decidi ver se poderia reproduzir um comportamento semelhante usando a ferramenta ldapsearch da linha de comando fornecida com o openldap. Eu dei um comando assim:

$ ldapsearch -d 9 -H ldaps://ldap.ad.mycompany.com:3269/ -D MYBINDDN -w xxxxxx \
   -b DC=mycompany,DC=xx '(&(cn=myuser)(objectClass=person))'

O -d 9 finalmente me deu uma saída de depuração útil:

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..

Lendo a página man do ldap.conf, descobri que devo definir TLS_CACERT e / ou TLS_CACERTDIR para apontar para pacotes e arquivos de certificados. Eu estou usando o Centos 6, que tem estes em / etc / pki / tls / certs /, então eu defino o seguinte:

TLS_CACERT    /etc/pki/tls/certs/ca-bundle.crt
TLS_CACERTDIR /etc/pki/tls/certs/

Depois que o ldapsearch funcionou e depois de reiniciar o saslauthd, a autenticação em relação ao servidor do AD foi bem-sucedida.