Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 "apache@myDomain.com"
                AuthLDAPBindPassword "someSuperSecretPassword"
                AuthLDAPUrl "ldap://pdc.myDomain.com:3268/dc=myDomain,dc=com?samAccountName?sub?(objectCategory=person)(objectClass=User)"
                Require valid-user
</Location>
share|improve this question

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.