[Auth_ldap] LDAP searches too large?

[Steven Hajducko]

We're having an issue when dealing with too large of a search, it seems.
 
When we issue the search -
 
ldap://corpdc.corp.ad.diginsite.com/ou=users,ou=corporate,dc=corp,dc=ad,dc=d
iginsite,dc=com?sAMAccountName?sub?(objectClass=user
<ldap://corpdc.corp.ad.diginsite.com/ou=users,ou=corporate,dc=corp,dc=ad,dc=
diginsite,dc=com?sAMAccountName?sub?(objectClass=user> )
 
Everything works fine.
 
When increase the broadness of the search with the following url, apache
fails to process:
 
ldap://corpdc.corp.ad.diginsite.com/dc=corp,dc=ad,dc=diginsite,dc=com?sAMAcc
ountName?sub?(objectClass=user
<ldap://corpdc.corp.ad.diginsite.com/dc=corp,dc=ad,dc=diginsite,dc=com?sAMAc
countName?sub?(objectClass=user> )
 
The lines in the log leading up to this are:
 
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(66): version 1.6.0:
Trying to parse an url
`ldap://corpdc.corp.ad.diginsite.com/dc=corp,dc=ad,dc=diginsite,dc=com?sAMAc
countName?sub?(objectClass=user)'
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(87): Url parse: Host:
corpdc.corp.ad.diginsite.com
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(89): Url parse: Port:
389
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(91): Url parse: DN:
dc=corp,dc=ad,dc=diginsite,dc=com
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(93): Url parse:
Attrib: sAMAccountName
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(95): Url parse: Scope:
subtree
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(100): Url parse:
Filter: (objectClass=user)
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap_config.c(147): {11023} not
requesting secure LDAP
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(480): [client 10.201.250.159]
{11023} Entering ldap_authenticate_basic_user
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(306): [client 10.201.250.159]
{11023} Entering auth_ldap_find_connection
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(498): [client 10.201.250.159]
{11023} authenticate: using URL
<ldap://corpdc.corp.ad.diginsite.com/dc=corp,dc=ad,dc=diginsite,dc=com?sAMAc
countName?sub?(objectClass=user>
ldap://corpdc.corp.ad.diginsite.com/dc=corp,dc=ad,dc=diginsite,dc=com?sAMAcc
ountName?sub?(objectClass=user)
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(432): [client 10.201.250.159]
{11023} inserting
`ldap://corpdc.corp.ad.diginsite.com/dc=corp,dc=ad,dc=diginsite,dc=com?sAMAc
countName?sub?(objectClass=user)' into URL cache
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(551): [client 10.201.250.159]
{11023} entry for `stha3155' is not in the cache
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(145): [client 10.201.250.159]
{11023} Entering auth_ldap_connect_to_server
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(165): [client 10.201.250.159]
{11023} Opening connection to ldap server(s) `corpdc.corp.ad.diginsite.com'
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(168): [client 10.201.250.159]
{11023} LDAP OP: init
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(262): [client 10.201.250.159]
{11023} Binding to server `corpdc.corp.ad.diginsite.com' as
cn=skynet,ou=Special,ou=Corporate,dc=corp,dc=ad,dc=diginsite,dc=com/########
##########
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(272): [client 10.201.250.159]
{11023} LDAP OP: simple bind
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(577): [client 10.201.250.159]
{11023} Peforming a search (scope=2) with filter
(&(objectClass=user)(sAMAccountName=stha3155))
[Thu Jun 16 09:35:54 2005] [debug] auth_ldap.c(581): [client 10.201.250.159]
{11023} LDAP OP: search
[Thu Jun 16 09:35:54 2005] [error] [client 10.201.250.159] LDAP search for
(&(objectClass=user)(sAMAccountName=stha3155)) failed: LDAP error:
Operations error; URI /bin/view/Documentation/WebHome
 
If we change the scope back to be more specific, it works.  Normally this
wouldn't be an issue, but our MIS department has setup the different offices
into their own containers, which prevents us from specifying a single
container as the scope to search.
 
On a side note, doing the broad search from the command line works fine.  I
thought the filtering process would take place on the server, not within the
client, but is this the case?  If so, is there anything we can do to fix
this issue?
 
--
sh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.rudedog.org/pipermail/auth_ldap/attachments/20050616/cf97c8c5/attachment.htm