Re: extensible match quirks for Active Directory

[Ralf Haferkamp <rhafer@suse.de>]

On Thursday 20 October 2005 14:49, Kurt D. Zeilenga wrote:
> At 02:22 AM 10/20/2005, Ralf Haferkamp wrote:
> >we recently found out that some versions of Active Directory don't
> >accept some extensible matching filters.
>
> Old AD installs should be updated.  I believe MS has provided a fix
> for this problem.
Yes, to my knowledge they released fixes at least for some versions. But 
there still seem to be a lot of unfixed installations in the wild (for 
whatever reasons).

> If not or the fix flawed, folks should complain 
> to MS as the LDAP TS is quite clear that default values of BOOLEAN
> valued fields are absent in conformant PDU encodings (per
> Section 5.1(4) of RFC 2251).
I know.

> >(Newer Versions seem to work correctly.)
> >
> >
> >The problem is that AD seems to be unable to decode the extensible
> >match, when the "dnAttributes" field is missing in the request
> > (which means it's using the default value "false"). Explicitly
> > adding the boolean (with a false value) to the request makes AD
> > work as expected. Would you accept the addition of a workaround for
> > this problem to libldap (something that can be switched on by some
> > ldap_set_option() call)?
>
> You mean, something like:
>         LDAP_OPT_IGNORE_RFC2251_SECTION_5_1_ITEM_4_REQUIREMENT
Yes, maybe with an even more scary name ;-)

> In general, I am opposed to adding such an option as it
> would, in all likelihood, be enabled unconditionally, leading
> to significantly more non-conformant LDAP implementations in
> the wild. It would be counter to the old Internet 
> interoperability guideline "be liberal in what you accept,
> be conservative in what you send" in implementing protocols,
> as well as erode the value of standardized LDAP specifications.
Understood. So I guess we will work around this problem in some other 
way.

-- 
Ralf