Falhas intermitentes do Subversion (Apache auth_ldap contra o AD)

Question

O problema:
Meu subversion começou a parar de funcionar periodicamente (a cada uma ou duas horas), isso parece ter começado quando um controlador de domínio falhou (ainda não fiz uma limpeza de metadados). O que falhou, no entanto, não é o especificado no diretório AuthLDAPUrl.

Minhas perguntas:
Alguém tem alguma idéia do que pode estar causando isso, é possível que o controlador de domínio que os contatos auth_ldap enviar uma resposta dizendo auth_ldap para usar o controlador de domínio que agora se foi?

Além disso, existe uma maneira de despejar todas as senhas de autenticação do ldap para os usuários no AuthzSVNAccessFile para um arquivo local como uma solução temporária?

Parece que estou usando o Catálogo Global, porta 3268, seria melhor usar 636 ou 389. O que significa usar um desses? Alguns dos meus outros DC's não estão ouvindo em 3268, mas estão nessas outras portas, então talvez eu possa especificar AuthLDAPUrls reduntant?

Material de referência:
Mensagem de erro:

[warn] [client 192.168.80.80] 
[22364] auth_ldap authenticate: user aUserName authentication failed; 
URI /svn/someRepo/trunk [LDAP: ldap_simple_bind_s() failed]
[Can't contact LDAP server]

configuração auth_ldap:

<Location /svn> 
                DAV svn
                SVNParentPath /var/svn
                AuthzSVNAccessFile /etc/httpd/authfiles/authz_svn_access
                AuthType Basic
                AuthBasicProvider ldap
                AuthName "Company's Software Repository"
                AuthLDAPBindDN "[email protected]"
                AuthLDAPBindPassword "someSuperSecretPassword"
                AuthLDAPUrl "ldap://pdc.myDomain.com:3268/dc=myDomain,dc=com?samAccountName?sub?(objectCategory=person)(objectClass=User)"
                Require valid-user
</Location>

    

Answer 1

O uso da porta 3268 indica que a pesquisa LDAP deve ser feita "em toda a floresta" e executada no próprio catálogo global, em vez de em um controlador de domínio específico.

Isso pode ser parte do problema - alternar para 636 ou 389 alternaria para uma consulta LDAP executada apenas nos objetos replicados para o servidor LDAP local / controlador de domínio.

Eu acho que a solução 'certa' é simplesmente limpar o AD - o DC ausente provavelmente está causando todos os outros tipos de problemas com sincronização e similares.

Quanto a senhas de despejo - com bons diretórios LDAP, o atributo de senha é somente gravação (SunONE, Novell eDirectory e MS Active Directory fazem isso), especificamente para evitar que as pessoas os joguem fora e usem mal.

Se fosse uma emergência, você poderia usar uma ferramenta como pwdump para despejar as senhas do SAM do controlador de domínio e quebrá-las com tabelas rainbow ou algo assim, mas acho que se você limpasse seus metadados e sua floresta, vai ficar bem.

    

Answer 2

quais versões do apache e do svn você está usando? Existem problemas conhecidos com versões anteriores do apache e do ldap / AD ... corrigidos no 2.2.8 (acredito) link