I'm setting up LDAP authentication for our Subversion repository hosted through Apache on a RHEL 5 system. I run into two different issues when I try to authenticate against Active Directory.

<Location /svn/>
Dav svn
SvnParentPath /srv/subversion
SVNListParentPath On
AuthType Basic
AuthName "Subversion Repository"

AuthBasicProvider ldap

AuthLDAPBindDN "cn=userfoo,ou=Service Accounts,ou=User Accounts,dc=my,dc=example,dc=com"
AuthLDAPBindPassword "mypass"

AuthLDAPUrl "ldap://my.example.com:389/ou=User Accounts,dc=my,dc=example,dc=com?sAMAccountName?sub?(objectClass=user)" NONE

Require valid-user
</Location>

If I use the above configuration it continually prompts me with the Basic prompt and I have to eventually select Cancel, which returns a 401 (Authorization Required). If I comment out the bind parts it returns 500 (Internal Server Error), griping that authentication failed:

[Mon Nov 02 12:00:00 2009] [warn] [client x.x.x.x] [10744] auth_ldap authenticate: user myuser authentication failed; URI /svn [ldap_search_ext_s() for user failed][Operations error]

When I perform the bind using ldapsearch and filter for a simple attribute it returns correctly:

ldapsearch -h my.example.com -p 389 -D "cn=userfoo,ou=Service Accounts,ou=User Accounts,dc=my,dc=example,dc=com" -b "ou=User Accounts,dc=my,dc=example,dc=com" -w - "&(objectClass=user)(cn=myuser)" sAMAccountName

Unfortunately I have no control or insight into the AD part of the system, only the RHEL server. Does anyone know what the hang up is here?

link|improve this question
What does apache error_log say? – Rilindo Oct 23 '11 at 0:22
It's the code block just after the griping that authentication failed: statement. – Erik Nov 7 '11 at 22:45
feedback

4 Answers

Comparing your configuration to a working configuration with Active Directory on Apache 2.2.3 the only differences I'm seeing are:

  • I am using the "DOMAIN\sAMAccountName" style username for my AuthLDAPBindDN
  • I do not have NONE after my AuthLDAPURL

Aside from those suggestions, I'd recommend running tcpdump on the conversation between Apache and Active Directory to see what might be transpiring there, too.

link|improve this answer
feedback

I dont know about LDAP as I have used SSPI auth for my setup. But I found these pages with nice details on LDAP configuration. (Just in case you havent yet gotten to them):

http://blogs.open.collab.net/svn/2009/03/subversion-with-apache-and-ldap-updated.html

http://www.novell.com/communities/node/5679/installing-and-configuring-subversion-server-and-apache2-ldap-authentication-against-edire

The apache version seems to make a difference to the syntax.

Also the order in which the LDAP modules are loaded.

link|improve this answer
1  
I found these docs as well. unfortunately they didn't provide any insight as to the underlying issue – Erik Apr 20 '10 at 17:37
feedback

Your LDAPUrl makes apache create query: &(objectClass=user)(sAMAccountName=myuser)

And your command line query is: &(objectClass=user)(cn=myuser)

Which one is correct? If you say your command line test works ok, then you probably need:

AuthLDAPUrl "ldap://my.example.com:389/ou=User Accounts,dc=my,dc=example,dc=com?cn?sub?(objectClass=user)" NONE

link|improve this answer
cn or SAMAccountName are both available, and in the case of our network interchangeable. – Erik Dec 21 '09 at 18:45
Can you access the AD logs? It would be good to confront what apache asks the AD. I have similar configuartion with OpenLDAP and it is working fine. So a problem musy lay somewhere else. Maybe some SE extensions or sth? Maybe apache process is not able to open sockets? No other ideas. – silk Dec 21 '09 at 23:30
I spoke with the LDAP admin and they couldn't identify anything in the logs. Also problematic is the LDAP instance deals with logins from nearly 13,000 accounts daily. A proverbial needle. – Erik Apr 20 '10 at 17:38
Couldn't identify anything? This seems strange :) At least he should be able to tell you if the apach at least connects, and later what queries it issues. – silk May 3 '10 at 20:39
feedback

I had the same problem. The identical configuration i tested on Ubuntu did not work on RHEL5. I ended up changing from port 389 to 3268 after reading this and that fixed my problem.

link|improve this answer
Hi Kieren, can you please include some of the salient details of that discussion (like what specific steps you took to resolve the problem) in your answer? This makes your answer useful if that form post ever goes away (see here for more info) – voretaq7 Jan 23 at 21:57
feedback

Your Answer

 
or
required, but never shown

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