Bug 26538 - windows 2003 active directory - [ldap_search_ext_s() for user failed][Referral]
windows 2003 active directory - [ldap_search_ext_s() for user failed][Referral]
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_ldap
2.0.48
PC All
: P3 enhancement with 10 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: FixedInTrunk, PatchAvailable
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-01-29 22:03 UTC by Andrew Blyler
Modified: 2012-01-04 15:16 UTC (History)
4 users (show)



Attachments
Changes required to make referrals optional via module configuration (24.52 KB, application/zip)
2006-11-21 08:10 UTC, Aaron Siri
Details
A code patch to add support for turning on and off referral following (8.40 KB, patch)
2007-04-26 07:54 UTC, Aaron Siri
Details | Diff
APR-util updates to provide rebind callback. (9.71 KB, patch)
2007-07-17 05:27 UTC, Paul J. Reder
Details | Diff
Apache updates to provide rebind callback for MSAD 2003 referrals. (9.36 KB, patch)
2007-07-17 05:29 UTC, Paul J. Reder
Details | Diff
Updated patch: fix namespace (11.01 KB, patch)
2007-12-03 09:09 UTC, Graham Leggett
Details | Diff
APR-util updates to provide rebind callback (for apache 2.0.x) (12.71 KB, patch)
2008-02-22 02:43 UTC, Alan D. Salewski
Details | Diff
Apache updates to provide rebind callback for MSAD 2003 referrals (for apache 2.0.x) (8.79 KB, patch)
2008-02-22 02:47 UTC, Alan D. Salewski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Blyler 2004-01-29 22:03:44 UTC
I have been chatting with someone on a linux user group about this.  It seems
that mod_auth_ldap doesn't like multiple references.  The email thread follows:


I am not sure either.  I just set up mod_auth_ldap on the Windows 2000
domain and it works like a champ.  :-)  I guess mod_auth_ldap doesn't
like how Windows 2003 works with returning the three references.  :-/

- Andy

On Thu, 2004-01-29 at 16:11, Andrew Libby wrote:
> I'm unclear about why your directory server is sending
> references back when the entry has been located and returned
> to you.  In my dealings with SunOne (iPlanet) and OpenLDAP,
> I've not seen such a thing.
> 
> Andy
> 
> 
> Andrew Blyler wrote:
> 
> >I just set up a Windows 2000 domain and found that it only returns one
> >reference.  I didn't test mod_auth_ldap on Windows 2000 just yet, but
> >below is the results from my ldapsearch.
> >
> >[ablyler at laptop ablyler]$ ldapsearch -h domain_controler.domain.com -vx
> >-D "ablyler at domain.com" -b DC=domain,DC=com sAMAccountName=ablyler -W
> >
> ># extended LDIF
> >#
> ># LDAPv3
> ># base <DC=domain,DC=com> with scope sub
> ># filter: sAMAccountName=ablyler
> ># requesting: ALL
> >#
> > 
> ># Andrew Blyler, Users, domain.com
> >dn: CN=Andrew Blyler,CN=Users,DC=domain,DC=com
> ># there were a lot of attributes, but I removed them
> >whenCreated: 20040129194305.0Z
> > 
> ># search reference
> >ref: ldap://domain.com/CN=Configuration,DC=domain,DC=com
> > 
> ># search result
> >search: 2
> >result: 0 Success
> > 
> ># numResponses: 3
> ># numEntries: 1
> ># numReferences: 1
> >
> >
> >On Thu, 2004-01-29 at 14:42, Andrew Blyler wrote:
> >  
> >
> >>Okay, it looks like it is returning some references for the forest dns,
> >>domain dns, and configuration partitions.  I am guessing that
> >>mod_auth_ldap doesn't like the fact that it is getting some references. 
> >>:-(
> >>
> >>Note: in this email and previous emails I refer to the domain as
> >>domain.com and the dc/ldap server as domain_controler.
> >>
> >>ldapsearch -h domain_controler.domain.com -vx -D "CN=Andrew
> >>Blyler,OU=SI,OU=Mechanicsburg,DC=domain,DC=com" -b DC=domain,DC=com
> >>sAMAccountName=ablyler -W
> >># extended LDIF
> >>#
> >># LDAPv3
> >># base <DC=domain,DC=com> with scope sub
> >># filter: sAMAccountName=ablyler
> >># requesting: ALL
> >>#
> >> 
> >># Andrew Blyler, SI, Mechanicsburg, domain.com
> >>dn: CN=Andrew Blyler,OU=SI,OU=Mechanicsburg,DC=domain,DC=com
> >># there were a lot of attributes, but I removed them
> >>msExchMailboxGuid:: z73C+rf14UWMpPR+SkVOjA==
> >> 
> >># search reference
> >>ref: ldap://DomainDnsZones.domain.com/DC=DomainDnsZones,DC=domain,DC=com
> >> 
> >># search reference
> >>ref: ldap://ForestDnsZones.domain.com/DC=ForestDnsZones,DC=domain,DC=com
> >> 
> >># search reference
> >>ref: ldap://domain.Com/CN=Configuration,DC=domain,DC=com
> >> 
> >># search result
> >>search: 2
> >>result: 0 Success
> >> 
> >># numResponses: 5
> >># numEntries: 1
> >># numReferences: 3
> >>
> >>
> >>On Thu, 2004-01-29 at 13:33, Andrew Libby wrote:
> >>    
> >>
> >>>While I can't say for sure, I'll put in a few cents as to what
> >>>may be happening.
> >>>
> >>>The error message in the error.log indicates that the
> >>>client (Apache) got a referral from Active Directory.
> >>>Referral responses are provided to LDAP clients when
> >>>the DSA (LDAP server) does not have the base indicated
> >>>in the search, or if the request is a modification request
> >>>and the client is a replica.  If the replica case applies,
> >>>the referral will suggest the authoratative server to which
> >>>the client should issue the modification.  My hunch is that
> >>>this is not what is happening here.
> >>>
> >>>The other case is when the DSA does not provide service for the
> >>>base dn specified in the search.  Looking at the configuration
> >>>snippit you supplied, you're LDAP server is domain_controler.domain.com.
> >>>Is this valid?  It seems so since you're getting a referral back
> >>>but I thought I'd ask since it looks a lot like a configuration example
> >>>which might be posted in documentation.  The base dn you've listed
> >>>is DC=domain,DC=com.  Does the DSA at domain_controler.domina.com
> >>>serve this base dn?  If not then we've got the problem.
> >>>
> >>>To try to verify what's going on you could try some comand line searches 
> >>>from
> >>>another host (provided AD will respond to incomming LDAP search requests
> >>>from another host). 
> >>>
> >>>For example try:
> >>>
> >>>ldapsearch -LLLxh domain_controler.domaiin.com -b DC=domain,DC=com 
> >>>objectclass=\*
> >>>
> >>>This should give you lotts of entries.  Usually usernames are stored 
> >>>keyd based
> >>>on cn or uid attributes.  You could try searching for cn=username or 
> >>>uid=username
> >>>in place of objectclass=\*.  Replace 'username' with the username of a 
> >>>user you're
> >>>attempting to authenticate with.
> >>>
> >>>Depending on what vendor and version of ldapsearch you use, you may need 
> >>>to drop
> >>>the -x, or -LLL from the command line for it to work.  Depending on the 
> >>>version of
> >>>the libraries which Apache is linked with, and depending on how the auth 
> >>>module is
> >>>implemented, it may flat out not follow referrals.  My guess is that you 
> >>>don't
> >>>really want to follow referrals, you want to find out why you're getting 
> >>>a referral
> >>>and fix the issue.  The base dn is my bet. 
> >>>
> >>>Andy
> >>>
> >>>Andrew Blyler wrote:
> >>>
> >>>      
> >>>
> >>>>I know I am running this on Windows, but I thought someone might have
> >>>>some in sight on the issue.
> >>>>
> >>>>When tring to use Apache 2.0.48 on Windows 2003 to authenticate users
> >>>>in a Windows 2003 Active Directory LDAP server I get the following:
> >>>>
> >>>>error.log
> >>>>[Thu Jan 29 12:26:24 2004] [warn] [client 10.4.2.111] [4608] auth_ldap
> >>>>authenticate: user ablyler authentication failed; URI /test/index.html
> >>>>[ldap_search_ext_s() for user failed][Referral]
> >>>>
> >>>>The following is a section of the config:
> >>>>
> >>>>httpd.conf
> >>>><Directory />
> >>>>   Options FollowSymLinks
> >>>>   AllowOverride None
> >>>>
> >>>>   # LDAP Authentication & Authorization is final; do not check other
> >>>>databases
> >>>>   AuthLDAPAuthoritative on
> >>>>
> >>>>   # Do basic password authentication in the clear
> >>>>   AuthType Basic
> >>>>
> >>>>   # The name of the protected area or "realm"
> >>>>   AuthName "Test Realm"
> >>>>
> >>>>   # Active Directory requires an authenticating DN to access records
> >>>>   AuthLDAPBindDN CN=service_account,DC=domain,DC=com
> >>>>
> >>>>   # This is the password for the AuthLDAPBindDN user in Active
> >>>>Directory
> >>>>   AuthLDAPBindPassword service_account_password
> >>>>
> >>>>   # The LDAP query URL
> >>>>   AuthLDAPURL
>
>>>>"ldaps://domain_controler.domain.com/DC=domain,DC=com?sAMAccountName?sub?(objectClass=*)"
> >>>></Directory>
> >>>>
> >>>><Directory "C:/Program Files/Apache Group/Apache2/htdocs/test">
> >>>>  AuthName "Special User Area"
> >>>>  require valid-user
> >>>></Directory>
> >>>>
> >>>>Does anyone have any ideas of what is going on?
> >>>>
> >>>>Thanks,
> >>>>Andy Blyler
Comment 1 Andrew Blyler 2004-01-30 01:12:20 UTC
Just a side note: mod_auth_ldap works great with ADAM (Active Direction
Application Mode).  :-)
Comment 2 Graham Leggett 2004-05-21 01:46:11 UTC
It looks like the Microsoft LDAP SDK does not follow referrals by default. Maybe
adding an option to follow referrals would fix this problem.
Comment 3 Graham Leggett 2004-10-17 18:24:44 UTC
Is this problem still present or can I close this?
Comment 4 Andrew Blyler 2004-10-22 19:04:45 UTC
It is working great for me now.  Thanks for fixing this.
Comment 5 fugit 2005-03-30 00:10:02 UTC
I had this problem and after looking into it further, it turned out we had a
non-standard instalation of AD. With all users broken up into there own OU's. I
had to put the OU into the AuthLDAPURL 

This failed
AuthLDAPURL ldap://foo.xx.bar.com:389/DC=xx,DC=bar,DC=com?sAMAccountName?sub

This worked:
AuthLDAPURL
ldap://foo.xx.bar.com:389/OU=Systems,DC=xx,DC=bar,DC=com?sAMAccountName?sub

Hope this helps for anyone else that has this problem. 

Thanks, 
Fugit
Comment 6 Jeffrey 2006-03-09 08:42:55 UTC
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=au

# search reference
ref:
ldap://DomainDnsZones.<DOMAIN>.com.au/DC=DomainDnsZones,DC=<DOMAIN>,DC=com,DC=au

# 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).
Comment 7 carl 2006-03-16 14:00:18 UTC
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).

Comment 8 Lotto Fischer 2006-03-29 08:21:35 UTC
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).

Comment 9 Aaron Siri 2006-03-31 17:22:37 UTC
If I add the following lines to util_ldap.c right after the "ldap_set_option(
...LDAP_OPT_DEREF...);" line in uldap_connection_open() I can authenticate
against Active Directory 2003.

  /* Turn off referrals */
  ldap_set_option(ldc->ldap, LDAP_OPT_REFERRALS, (void *)LDAP_OPT_OFF);

I have code for 2.2.0 to make this a module option - "AuthLDAPFollowReferrals" -
which can be either "on" or "off" (defaults to on.)  Is this worth putting into
the source? 
Comment 10 Ray Van Dolson 2006-11-06 11:13:23 UTC
(In reply to comment #9)
> I have code for 2.2.0 to make this a module option - "AuthLDAPFollowReferrals" -
> which can be either "on" or "off" (defaults to on.)  Is this worth putting into
> the source? 

I think this would be a great addition.  Obviously a fairly simple patch, if you
upload it here maybe they'd be willing to merge it in?  I'd like to see RH get
this into their httpd RPM as well at some point.
Comment 11 Achim Grolms 2006-11-20 12:29:14 UTC
I have tested the

/* Turn off referrals */
ldap_set_option(ldc->ldap, LDAP_OPT_REFERRALS, (void *)LDAP_OPT_OFF);

idea on my local Apache, this works fine for me against Windows2003 DC
on port 389 (I know, using the GC on Port 3268 is the better solution in most 
cases.)

I think an  AuthLDAPFollowReferrals can be useful to make this
behaviour configureable.
Comment 12 Lieven Govaerts 2006-11-21 06:56:16 UTC
If you're using OpenLDAP you can also disable referral chasing in the OpenLDAP
config file (ldap.conf). Just add the line 'REFERRALS off'.

We have been using this successfully on SLES 9 with apache 2.0.54 and OpenLDAP
2.2.27 since our AD server was upgraded to Win2k3.
Comment 13 Aaron Siri 2006-11-21 08:10:50 UTC
Created attachment 19154 [details]
Changes required to make referrals optional via module configuration

The .zip file includes an altered mod_authnz_ldap.c and util_ldap.c.  I
downloaded the sources (httpd-2.2.3) instead of checking them out so I couldn't
easily do a diff.

The included code adds an option - AuthLDAPFollowReferrals - that can be set to
either on or off (defaults to on.)  I've been using the changed code for a
couple weeks now with no problems.

Let me know if I forgot anything.
Comment 14 Achim Grolms 2006-11-21 13:52:33 UTC
(In reply to comment #12)
> config file (ldap.conf). Just add the line 'REFERRALS off'.

Ah, an easy to use way, too :-)

Maybe the best idea is to patch the module's documentation, too?
I suppose many people use (or want to use) Win2003 as LDAP authentication backend.
So I think some "Windows2003 notes" in mod_auth_ldap documentation 
(hints to port 3268, ldap.conf an *why* there is an AuthLDAPFollowReferrals
directive ) are very useful.
Comment 15 Aaron Siri 2007-04-25 11:39:30 UTC
Is there any chance of getting the patch into the code?  Who do we have to
bother to get the patch included?
Comment 16 William A. Rowe Jr. 2007-04-25 12:30:46 UTC
First - this thread contains a fount of wisdom on ldap config for win32,
please note we now have a user-modifiable wiki community resource:

  http://wiki.apache.org/httpd/

if anyone has the time and gumption to turn all of these ideas into a win32
LDAP/AD cookbook.

About the patch...

I suggest you reattach your file as a patch (using diff or svn diff against
httpd-2.2) in plain text instead of a zip file.  Adding binary attachments
to a bug means the developers with limited time end up spending that time on
every bug with text patches that are easily identifed, and unfortunately ignore 
those that aren't viewable for consideration.

If I had free time I'd help you by whipping up that diff, but unfortunately
my time is -very- limited over the next weeks, I'll apply well thought out
patches but can't spend cycles right now to create your diffs for you.

Comment 17 Aaron Siri 2007-04-25 13:17:59 UTC
Are patches against 2.2.x good enough or do I have to create patches against
2.3.x as well?
Comment 18 Ruediger Pluem 2007-04-25 13:24:34 UTC
(In reply to comment #17)
> Are patches against 2.2.x good enough or do I have to create patches against
> 2.3.x as well?

Please create patches against trunk (aka 2.3) as all changes need to go to trunk
first. If you want to help backporting later once the patch is accepted for
trunk this is fine and you can add patches for 2.2.x then.
Comment 19 William A. Rowe Jr. 2007-04-25 13:27:35 UTC
Patches against any recent point in 2.2 or trunk would be just fine!

A patch against 2.0 would also be considered for 'backport' - because of the
module changes in ldap I'm speculating the backport to 2.0 is non-trivial.
But I could be off base.
Comment 20 Aaron Siri 2007-04-26 07:54:09 UTC
Created attachment 20053 [details]
A code patch to add support for turning on and off referral following

This code patches 2.3.x (trunk).  It adds an AuthLDAPFollowReferrals
configuration option that controls referral following.
Comment 21 Paul J. Reder 2007-07-12 12:52:48 UTC
I believe this is a partial fix for a bigger problem. MSAD 2003 stopped
accepting anonymous binds. This means that with other LDAP servers you can chase
referrals using anonymous binds and never know the difference. MSAD 2003
required that referral chasers provide credentials via the rebind callback.

You can get around this by turning off referrals (so it doesn't try to chase
referrals and then fail), and use the global catalog (thus no referrals). As I
understand it, this is a workaround with some downsides (possible performance
and accuracy issues).

The alternative it to chase referrals and provide a rebind callback function. I
will be attaching a patch providing this support shortly.
Comment 22 Eric Covener 2007-07-12 14:30:53 UTC
Another potential workaround is to access the AD service via an intermdiate 
ADAM server:

http://www.microsoft.com/downloads/details.aspx?familyid=9688f8b9-1034-4ef6-a3e5-2a2a57b5c8e4&displaylang=en
Comment 23 Paul J. Reder 2007-07-17 05:27:02 UTC
Created attachment 20522 [details]
APR-util updates to provide rebind callback.

This patch adds rebind support to APR so that Apache LDAP modules can now chase
refrerals on an MSAD 2003 server where anonymous binds are not allowed. MSAD
uses the rebind callback to obtain bindDN and bindPW credentials for all
subsequent referrals. There is an Apache patch that goes with this one.
Comment 24 Paul J. Reder 2007-07-17 05:29:23 UTC
Created attachment 20523 [details]
Apache updates to provide rebind callback for MSAD 2003 referrals.

This patch adds rebind support to Apache so that Apache LDAP modules can now
chase refrerals on an MSAD 2003 server where anonymous binds are not allowed.
MSAD uses the rebind callback to obtain bindDN and bindPW credentials for all
subsequent referrals. There is an APR-util patch that goes with this one.
Comment 25 Graham Leggett 2007-12-03 09:09:22 UTC
Created attachment 21222 [details]
Updated patch: fix namespace

Looking at this in more detail.

It took me a while to figure out exactly what the rebind code was trying to do
(as opposed to generally knowing what it does), and it seems to be "an
implementation of a callback mechanism able to take advantage of the LDAP
referral callback feature".

Or in other words, use of this particular API is optional, someone using the
APR interface may choose to use this particular implementation, or they may
choose some other implementation of their own.

Based on this, I think the API should all be in a namespace like
apr_ldap_rebind.

Looking further, unless I am missing something, I think this could probably be
significantly simplified.

In theory, the apr_ldap_set_rebind_callback() function can be called by
apr_ldap_xref_add(), hiding apr_ldap_set_rebind_callback().

In theory, there should be a way to register a pool cleanup for
apr_ldap_rebind_remove() as well.
Comment 26 Paul J. Reder 2008-01-23 10:24:25 UTC
This has been fixed in httpd trunk. Support for the rebind callback was added so
that proper credentials would be returned on a non-anonymous bind while chasing
referrals. Two new directives control the use of this feature. LDAPReferrals
[On|Off] determines if chasing referrals is supported. LDAPReferralHopLimit ##
specifies the maximum number of referral rebind hops that will be chased before
giving up on the search.
Comment 27 Alan D. Salewski 2008-02-22 02:43:46 UTC
Created attachment 21578 [details]
APR-util updates to provide rebind callback (for apache 2.0.x)

This patch is a direct backport of the above 20522 patch and code in the 2.2.x
trunk for use in httpd-2.0.x. This patch was created against the sources from a
stock httpd-2.0.63 tarball.
Comment 28 Alan D. Salewski 2008-02-22 02:47:55 UTC
Created attachment 21579 [details]
Apache updates to provide rebind callback for MSAD 2003 referrals (for apache 2.0.x)

This patch is a direct backport of the above 20523 patch and code in the 2.2.x
trunk for use in httpd-2.0.x. This patch was created against the sources from a
stock httpd-2.0.63 tarball.
Comment 29 Alan D. Salewski 2008-02-22 02:51:57 UTC
Reopening issue for consideration of the 2.0.x patches just attached.
Comment 30 Alan D. Salewski 2008-02-26 03:40:37 UTC
The above 2.0.x patches (21578 and 21579) seem to work fine with a non-threaded
APR, but I see deadlock when using them with a threaded APR on an SMP host.
Comment 31 Alan D. Salewski 2008-02-26 03:43:23 UTC
I should have mentioned in my previous comment that the APR used in my tests is
0.9.17
Comment 32 Eric Covener 2012-01-04 15:16:58 UTC
re-closing, no backport to Apache 2.0.x