Re: back-ldap problem with Win2000 Active Directory

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:39 AM 10/25/00 +0200, Bertrand Croq wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>>  From -bugs...
>> 
>> At 03:44 PM 10/23/00 +0200, Bertrand Croq wrote:
>> >  I have tested the modifications and it looks good: the referal is
>> >still buggy but slapd doesn't crash... instead, the ldap client (I used
>> >ldapsearch) receives a search result with resultCode 52 telling that
>> >slapd cannot follow the referal "ldap://thehost.com??base";.
>> 
>> This is an invalid LDAP URL.  The only character which may
>> follow the hostpart of the URL is "/".
>
>Here is a resume about this problem (for the complete story, have a look
>at the archive of openldap-bugs):
>
>slapd (back-ldap) -> AD:
>- Search:
>   host = thehost.com
>   DN: dc=thehost,dc=com
>   scope: single
>
>AD -> slapd:
>- Search entry
>- ...
>- Search entry:
>   resultCode: 9
>   error: referral
>ldap://thehost.com/CN=Configuration,dc=thehost,dc=com??base

9 is partial results, an LDAPv2+ result code.  Historically,
LDAPv2+ referrals NEVER provide any search options other
than the DN.  The U-Mich SDK doesn't handle it and likely
most SDKs derived from U-Mich don't as well.  In fact, I
am sure older Microsoft SDKs don't handle these referrals
as well.  AD would gain much better interoperability by
not providing an explicit scope.  New SDKs *should* imply
the appropriate scope based upon the operation which
resulted in the continuation.

Anyways, OpenLDAP needs some work in this area. It should
better handle both implicit and explicit scoping.  BTW,
the implicit scoping should be:
   continue subtree as subtree
   continue one as base
   continue base as base

As the default scope is base (per RFC2255), the special case is
actually subtree.

>when the client receives this, it parses the referral url and gets:
>* lpda server = thehost.com
>* DN = CN=Configuration,dc=thehost,dc=com??base
>I don't think this is what the Active Directory means. Then, slapd sends
>another search request:
>
>slapd -> AD:
>- Search:
>   host = thehost.com
>   DN: CN=Configuration,dc=thehost,dc=com??base
>   scope: single
>
>As active directory doesn't handle search requests for
>"dc=thehost,dc=com??base", it sends another referral to point to what it
>thinks is the good server: "thehost.com??base".

And how does it know this is the correct server name?  dc=foo,dc=bar
doesn't imply that the host foo.bar operates an LDAP server
holding the "dc=foo,dc=bar".  The server should locate the LDAP
server holding "dc=foo,dc=bar" using DNS.  In the above case,
DNS should have returned an error, which should then resulted
in an error being returned by AD.  An LDAP server should only
redirect clients based upon knowledge it holds directly or
indirectly (eg. DNS).

Anyways, here OpenLDAP should fail to parse the URL and not
attempt to chase it.

>So, I agree that Active
>Directory shouldn't send a referral with such a server address, but it
>happens because slapd sends a wrong DN, which happens because Active
>Directory sends the referral in a strange way (I don't know if it is a
>wrong way)... The problem is that we can't change Active Directory

You can be reporting bugs to Microsoft.

> so we
>have to handle such referrals :-(

I agree we should make some changes to improve our handling...

But note that this won't fix all the clients out there which
use SDKs with historical behavior.  This is why you need to
work with your server vendor to affect change.

>> Before modifying OpenLDAP client software, I think it important to
>> ensure that you have correctly configured server.  Servers generally
>> just echo whatever they are configured with.  In fact, servers
>> shouldn't muck with URL to be returned except as required by
>> the specifications (which are, of course, ''works in progress'').
>
>  Well, we don't know a lot about Active Directory (our task is to make
>slapd work with an already installed Active Directory). We have worked
>on the problem and we are close to a solution: we modified
>ldap_chase_referrals() so that it uses ldap_url_parse(), just like
>ldap_chase_v3referrals(). To handle the scope, we also had to modify
>re_encode_request(). I attach libraries/libldap/request.c to this mail;

If you'd like code reviewed, please submit an ITS with a
suitable patch (unified diff) per our contributing guidelines
<http://www.openldap.org/devel/contributing.html>.

>it was modified from OpenLDAP 2.0.4;

IIRC, there have been changes to referral handling since 2.0.4.
I suggest you acquire HEAD branch sources via CVS, forward port
your patches, and then use 'cvs diff -u' to generate a patch for
review.

>it might not be the best solution
>but it seems to work (no memory leak, DN and scope ok). Please tell me
>if you find problems.