[Auth_ldap] LDAP searches too large?

Brent Putman putmanb at georgetown.edu
Fri Jun 17 09:21:16 PDT 2005


I don't know if this if your problem or not, but I had a similar problem 
which turned out to be interesting:

I was trying to perform an LDAP search against a Windows 2003 AD test 
server we had (not with auth_ldap, something Java JNDI-based, but it 
probably doesn't matter).  It worked fine with a search base of 
CN=users,DC=my,DC=domain,DC=edu.  However, it was failing when the 
search base was changed to DC=my,DC=domain,DC=edu.  After much 
consternation and modifying the code in question to emit a log more 
debug output, I determined the following:

When you search against the domain object directly 
(DC=my,DC=domain,DC=edu), the search results include - in addition to 
the LDAP object(s) which the search may have found - LDAP continuation 
references to other parts of the tree, such as for example 
DC=Configuration,DC=my,DC=domain,DC=edu.  Ok, fine, LDAP client libs 
should just automatically follow those recursively (and probably find 
nothing useful), and then you're done.  HOWEVER, the hostname for the 
LDAP server in the continuation references is not the one you originally 
searched against (server.my.domain.edu) - it is one of those other DNS 
names that AD likes to put in for various services it supports.  In this 
case, it was using my.domain.edu - the DNS entry for the domain 
*itself*, which in a real AD deployment would have to resolve to one or 
more of the domain controllers for that domain.  Since ours was a test 
server, the domain we were using as the AD tree structure was NOT in our 
DNS (we weren't using MS dynamic DNS, etc), and hence the automatic 
recursive search against the continuation references by the LDAP client 
libs failed when it couldn't connect to any LDAP server at 
my.domain.edu.  This caused the whole search to throw an exception and 
fail.  The solution was simply getting my.domain.edu to resolve properly 
against the AD domain controller with a local hosts file entry.  Voila!  
Then it worked fine.

So maybe this is helpful to you, maybe not.  I'd just thought I'd 
share.  BTW, this problem does not occur if you search against the AD 
Global Catalog - it doesn't return the continuation references. However, 
the GC doesn't necessarily contain all the attributes of a user's 
object, it is only a configured subset, so if that is important, be aware.

Oh, and for the record:  you can tell your MIS department to go do their 
homework.  You can bumb up AD's LDAP protocol logging to an extremely 
detailed level by setting registry entries.  Sorry, I don't have them 
handy, but I bet you can find them on the MS knowledgebase.

Thanks,
Brent


Steven Hajducko wrote:

>Cool, thanks for the info Dave.  Really appreciated it.
>
>I'm just going to setup a local ldap server so I can get the logging
>information and try to find the differences between the tools.  According to
>MIS, AD doesn't do much logging of the LDAP requests anywhere, which seems
>pretty bogus to me, but hey, departmental politics. :)
>
>At least we have some idea of what the cause 'probably' is, rather than
>shooting in the dark.
>
>I'll let you guys know the results.
>
>--
>sh
>
>-----Original Message-----
>From: Dave Carrigan [mailto:dave at rudedog.org] 
>Sent: Thursday, June 16, 2005 4:06 PM
>To: auth_ldap at rudedog.org
>Subject: Re: [Auth_ldap] LDAP searches too large?
>
>
>_______________________________________________
>Auth_ldap mailing list
>Auth_ldap at rudedog.org http://www.rudedog.org/mailman/listinfo/auth_ldap
>_______________________________________________
>Auth_ldap mailing list
>Auth_ldap at rudedog.org
>http://www.rudedog.org/mailman/listinfo/auth_ldap
>  
>



More information about the Auth_ldap mailing list