DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=26538>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=26538
------- Additional Comments From webmaster042@gmail.com 2006-03-29 08:21 -------
i think there is an workaround for the problem.
AuthLDAPURL ldap://<IP_ADDRESS/HOSTNAME>:3268/dc=<DOMAIN>,dc=com,dc=au?
sAMAccountName
Port 3268 is the global catalog which doesen't return references.
How to create or move a Global Catalog in Windows 2000 (the same for 2003)
http://support.microsoft.com/kb/313994/en-us
(In reply to comment #7)
> Is this bug fixed?
> I have the same symptoms as my directory is partition according to my
business
> model like finance, hr, etc.. This is best practices to partition your
> directory and wonder why this bug is still there. My auth_ldap generate the
> same attempt to conect to the like
>
ldap://DomainDnsZones.<DOMAIN>.com.au/DC=DomainDnsZones,DC=<DOMAIN>,DC=com,DC=a
> u when looking at the packet over the network.
> You are the only reference to this bug that I saw on the net and welcome your
> input. You mention to use multiple AuthLDAPURL directives to workaround but
> it is not clear. Do I write multiple AuthLDAPURL statement in a row in the
> config file or I separate the search criteria over the same line?
> If you had tested this proposed workaround, I would appreciate an example.
> If you know if there a release of the auth_ldap module with a fix, I would
> appreciate a reference to it.
> Thanks in advance for your time.
> (In reply to comment #6)
> > This bug still exists. People below have simply changed their LDAP search
> path
> > so that they no longer see the referrals.
> > Essentially if your AuthLDAPURL is:
> > ldap://<IP_ADDRESS/HOSTNAME>/dc=<DOMAIN>,dc=com,dc=au?sAMAccountName
> > Your search will return three references:
> > eg:
> > -----------------
> > # search reference
> > ref:
> >
>
ldap://ForestDnsZones.<DOMAIN>.com.au/DC=ForestDnsZones,DC=<DOMAIN>,DC=com,DC=a
> u
> > # search reference
> > ref:
> >
>
ldap://DomainDnsZones.<DOMAIN>.com.au/DC=DomainDnsZones,DC=<DOMAIN>,DC=com,DC=a
> u
> > # search reference
> > ref: ldap://<DOMAIN>.com.au/CN=Configuration,DC=<DOMAIN>,DC=com,DC=au
> > # search result
> > search: 2
> > result: 0 Success
> > # numResponses: 5
> > # numEntries: 1
> > # numReferences: 3
> > -------------
> > auth_ldap will attempt to contact these references to perform a search.
> > From my research OpenLDAP will attempt an anonymous bind to these
referrals,
> it
> > will not use the BindDN (Active Directory doesn't allow anonymous binds)
> > So looking up these referrals will always fail.
> > Most of the time this can be worked around by changing the AuthLDAPURL to
> start
> > searching deeper down in the tree, thereby avoiding the referrals.
> > eg:
> > cn=Users,dc=<DOMAIN>,dc=com
> > OR
> > ou=something,dc=<DOMAIN>,dc=com
> > Unfortunately however, when you need to search two OUs, eg:
> > ou=A,dc=<DOMAIN>,dc=com AND ou=B,dc=<DOMAIN>,dc=com
> > you have no choice but to start search at the top of the tree.
> > Suggested fixes:
> > 1.) Allow multiple AuthLDAPURL directives, which will be searched in turn.
> > 2.) Add a directive to disable following referrals. By default ldap_init()
> (In
> > the OpenLDAP library) sets LDAP_OPT_REFERRALS (follow referrals).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
|