Estou usando uma configuração Debian "Lenny", rodando o Apache2 / SVN com o LDAP sendo autenticado através do Apache diretamente no AD, enquanto também hospedo um site do Trac na mesma máquina. Vou dar uma cutilada nisso, mas preciso de mais algumas informações ...
O acesso ao SVN é o módulo embutido através do Apache, então a primeira pergunta que eu tenho é - você está executando isso como o processo independente do SVN, ou através do Apache (parece ser o Apache, mas eu só quero ser certo)? A segunda pergunta é: você está usando o Apache2 ou o Apache (1.x)? A terceira pergunta é: você usa autenticação LDAP por meio do PAM ou por meio do suporte integrado do Apache?
Apenas para referência, aqui está uma versão (desinfetada) da configuração do Trac, junto com as configurações do LDAP que autenticam através do AD (sim, é aberto a qualquer pessoa porque o Trac possui seu próprio sistema de permissões. somente para usuários autenticados):
#Rudimentary Apache2 authentication for Active Directory (without group controls)
<Location /trac>
SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /srv/trac
PythonDebug on
Order deny,allow
Deny from all
Allow from 10.0.0.0/8
AuthType Basic
AuthName "Trac Projects"
AuthBasicProvider "ldap"
AuthLDAPURL "ldap://enterprise-dc.mycompany.com:3268/DC=localsite,DC=mycompany,DC=com?sAMAccountName?sub?(objectClass=user)"
AuthLDAPBindDN [email protected]
AuthLDAPBindPassword "supersecretpasswordthatnoonewillguess"
authzldapauthoritative On
require valid-user
# require ldap-group "CN=Users,DC=local-site,DC=mycompany,DC=com"
</Location>
Mais importante, para os seus objetivos, usando essa forma de autenticação como modelo, podemos obter as configurações de /etc/apache2/mods-enabled/dav_svn.conf , que controlará seu acesso ao SVN:
<Location /svn>
DAV svn
SVNParentPath /srv/svn
SVNAutoversioning on
Order deny,allow
Deny from all
Allow from 10.0.0.0/8
AuthType Basic
AuthName "Subversion Repository"
AuthBasicProvider "ldap"
AuthLDAPURL "ldap://enterprise-dc.mycompany.com:3268/DC=local-site,DC=mycompany,DC=com?sAMAccountName?sub?(objectClass=user)"
AuthLDAPBindDN [email protected]
AuthLDAPBindPassword "supersecretpasswordthatnoonewillguess"
authzldapauthoritative On
require valid-user
</Location>
Nossos desktops têm controles bastante rígidos sobre a instalação do programa, então não estou tão preocupado com alguém (a) instalando um cliente SVN (b) descobrindo o nome exato do servidor para conectar (c) ao repo e mucky estragar tudo, e é por isso que a segurança é tão baixa. No entanto, com um pouco de ajustes, você deve ser capaz de reutilizar esse arranjo impondo um grupo AD (observe o comentário comentado no primeiro exemplo) e obtenha um controle muito mais rígido sobre o acesso.
Espero que isso seja de ajuda para você.
Atualização (com base em novas informações)
Eu acho que o problema é que você não está autenticando contra o Catálogo Global. Altere o número da porta para o que eu tenho no meu exemplo, e não se esqueça de apontá-lo em um controlador de domínio que está no nível "Enterprise", ou seja, não um membro de um domínio filho. Portanto, em vez de site.enterprise.com, aponte para enterprise.com no novo número de porta. Note que você pode não precisar especificar o nome de domínio em sua configuração para o nome de usuário, portanto, se ele se recusar a autenticar, não deixe de experimentá-lo sem o mesmo (veja o exemplo que postei); e use o nome da conta "estilo de e-mail", além do layout "estilo de domínio".
Minha suspeita: o Catálogo Global "nivela" o espaço de pesquisa para os usuários; mas perguntando uma consulta LDAP padrão no DC filho, acho que a falha inicial ocorre porque não há "resposta" a ser obtida inicialmente, até que o controlador de domínio no domínio filho possa ser executado e obter um. Na segunda tentativa, a resposta é armazenada em cache e você é bem-sucedido.