[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