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://10.10.10.11/DC=mycompany,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://10.10.10.11/DC=mycompany,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,
ldapsearchon the CentOS machine and see if you can reproduce the problem there. Something like: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:
which will go to port 389, always make sure you specify the Global Catalogue port:
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).
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!
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.