1

The Problem:
My subversion has started to stop working periodically (every hour or two), this seems to have started when a domain controller failed ( I haven't done a metadata cleanup yet ). The one that failed though, is not the one specified in the AuthLDAPUrl directory.

My Questions:
Does anyone have any idea's what might be causing this, is it possible that the domain controller that auth_ldap contacts send a response telling auth_ldap to use the domain controller that is now gone?

Also, is there a way to dump all the ldap authentication passwords for the users in AuthzSVNAccessFile to a local file as a temporary workaround?

It looks like I am using the Global Catalog, port 3268, would I be better off using 636 or 389. What does it mean if I use one of those instead? Some of my other DC's are not listening on 3268 but are on those other ports, so maybe I could specify reduntant AuthLDAPUrls?

Reference Material:
Error Message:

[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]

auth_ldap configuration:

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

2 Answers 2

2

Using port 3268 indicates the LDAP search should be done 'forest wide' and is run against the global catalog itself, rather than a specific domain controller.

This might be part of the problem - switching to 636 or 389 would switch to an LDAP query run only against the objects replicated to the local LDAP server / domain controller.

I think the 'right' solution is to simply clean up the AD - the missing DC is probably causing all kinds of other problems with synchronization and the like as well.

As for dumping passwords - with good LDAP directories, the password attribute is write-only (SunONE, Novell eDirectory, and MS Active Directory all do this), specifically to prevent people from dumping them and misusing them.

If it was an emergency, you could use a tool like pwdump to dump the passwords from the domain controller SAM and then crack them with rainbow tables or something, but I think if you just cleaned up your metadata and forest, you'll be fine.

0

what versions of apache and svn are you using? There is known issues with earlier versions of apache and ldap/AD...fixed in 2.2.8 (I believe) http://www.apache.org/dist/httpd/CHANGES_2.2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .