I have a problem regarding my Subversion server installation with Apache (mod_ldap and mod_authnz_ldap) and my LDAP connection to a Microsoft Active Directory I am using a CentOS5 64Bit system with Collabnet Subversion EDGE.

The problem is the connection to my LDAP, because it needs for the first authentication exactly 30 seconds.

Here are the log file snippets.

First authentication with a myLdapUser:

==> /opt/csvn/data/logs/error_2012_04_24.log <==
[Tue Apr 24 10:42:00 2012] [debug] mod_authnz_ldap.c(403): [client xx.xx.xx.xx] [3122] auth_ldap authenticate: using URL ldap://,DC=com?sAMAccountName?sub

==> /opt/csvn/data/logs/access_2012_04_24.log <==
xx.xx.xx.xx - myLdapUser [24/Apr/2012:10:42:00 +0200] "GET /svn/ HTTP/1.1" 200 132

==> /opt/csvn/data/logs/error_2012_04_24.log <==
[Tue Apr 24 10:42:30 2012] [debug] mod_authnz_ldap.c(518): [client xx.xx.xx.xx] [3122] auth_ldap authenticate: accepting myLdapUser
[Tue Apr 24 10:42:30 2012] [info] [client xx.xx.xx.xx] Access granted: 'myLdapUser' GET (null)

As you can see there is a timegap of 30 seconds using the ldap URL and the accepted authentication. Do I reload the page after the first slow but successful authentication, everything is done in one second, see this log file snippet:

==> /opt/csvn/data/logs/access_2012_04_24.log <==
xx.xx.xx.xx - myLdapUser [24/Apr/2012:10:42:51 +0200] "GET /svn/ HTTP/1.1" 200 132

==> /opt/csvn/data/logs/error_2012_04_24.log <==
[Tue Apr 24 10:42:51 2012] [debug] mod_authnz_ldap.c(403): [client xx.xx.xx.xx] [3123] auth_ldap authenticate: using URL ldap://,DC=com?sAMAccountName?sub
[Tue Apr 24 10:42:51 2012] [debug] mod_authnz_ldap.c(518): [client xx.xx.xx.xx] [3123] auth_ldap authenticate: accepting myLdapUser
[Tue Apr 24 10:42:51 2012] [info] [client xx.xx.xx.xx] Access granted: 'myLdapUser' GET (null)

A look at the LDAP server: First it binds successfully, then it does very fast a search request and gets a search request entry with the full values of the user ´myLdapUser´, then, the user is not authenticated yet and after 30 seconds, it calls again the Active Directory with the user information of the search request entry and after that, the user is accepted.

Anyone an idea what's going wong?

I also post this question here, but it is not a subversion problem, it is related to Apache and mod_ldap, so I think I won't get help there: http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=417998


For the sake of completeness you should post your actual mod_authz_ldap configuration directives, not just the log snippets. For me this sounds like a DNS problem somewhere between Apache and AD, but without more info I can't be sure.

You should try to do the authentication manually using, for example, ldapsearch on the CentOS machine and see if you can reproduce the problem there. Something like:

ldapsearch -xLLLZ -D sAMAccountName=myLdapUSer,dc=mycompany,dc=com -W \
 -b dc=mycompany,dc=com -H ldap://
  • Where can I find these configuration directives? I did it manually and the result is this one with a valid user and password (the binding is done with a user which can connect to the sever and after that I take the username / password for a single user): ´ldap_start_tls: Server is unavailable (52) additional info: 00000000: LdapErr: DSID-0C090E17, comment: Error initializing SSL/TLS, data 0, v1db1 Enter LDAP Password: ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1´ – Tim Apr 24 '12 at 9:50
  • Maybe you mean this with the directives (it is automatically created by Subversion EDGE): LoadModule ldap_module lib/modules/mod_ldap.so LoadModule authnz_ldap_module lib/modules/mod_authnz_ldap.so <AuthnProviderAlias ldap ldap-users> AuthLDAPUrl "ldap://,DC=com?sAMAccountName?sub" "NONE" AuthLDAPBindDN "ldapAdmin@mycompany.cm" AuthLDAPBindPassword "password" </AuthnProviderAlias> LDAPVerifyServerCert Off <AuthnProviderAlias file csvn-file-users> AuthUserFile "/opt/csvn/data/conf/svn_auth_file" </AuthnProviderAlias> – Tim Apr 24 '12 at 9:56
  • 2
    +1 for the DNS suggestion. 30 seconds sounds eerily familiar for a number of related issues I've seen. – zigg May 1 '12 at 1:27

Given my experiences with Active Directory's "LDAP" (and I use the term loosely), it could be an issue of referrals.

By default, when you connect to port 389 on a Directory Controller, besides the regular LDAP answers you get from a referral to "directory.ads.example.com". Most LDAP clients (including Apache) follow referrals, and if you have many DCs—especially if they're geographically distributed—then your LDAP client can be sent off into the network. I once had a LDAP client in Montreal, Canada regularly go off to one of our DC in Sydney, Australia.

So, instead of having something like the following in your Apache configuration:

AuthLDAPURL ldap://mydc1.example.com/dc=example,dc=com?uid?one

which will go to port 389, always make sure you specify the Global Catalogue port:

AuthLDAPURL ldap://mydc1.example.com:3268/dc=example,dc=com?uid?one

If you need SSL, then that is port 3269. (Really wish MS wouldn't call their service LDAP, as it isn't it many ways, and it just causes confusion.)

P.S. In the future, please make a habit of posting the relevant parts of your config file/s (feel free to obfuscate any usernames, password, and/or domains).

  • I did it with port 3268, same result, slow authentication. – Tim May 1 '12 at 15:07

Looks like something wrong with DNS. 30 secs may be the timeout on some DNS query on Apache or LDAP server side. I'd double-check that!

  • How can I check that? – Tim May 6 '12 at 16:59

I would do a packet sniff on the network to see where the delay is occurring. It should show you if it's taking a long time for a DNS response to come back, or if the LDAP response is slow, or if there's some other delay you haven't anticipated, like an LDAP referral as DAM suggests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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