Re: (ITS#9100) Issue with domainScope controlValue implementation

Monday, 28 October 2019

Philip Brusten wrote:
...
=20
 On 25/10/2019 18:41, Howard Chu wrote:
> philip.brusten(a)kuleuven.be wrote:
>> That fix was based on (old?) documentation of MS from
>> https://msdn.microsoft.com/en-us/library/aa366979%28v=3Dvs.85%29.aspx
>> The is no current version of this document.
> The above URL redirects me to https://docs.microsoft.com/en-us/previou=
s-versions/windows/desktop/ldap/ldap-server-domain-scope-oid
...
>
> Our implementation conforms to the above spec.
 Correct, but the URL path contains "previous-versions", hence I was loo=
king for the current version, which does not exist.
...
> This is the correct response to a malformed message according to
RFC45= 11.
...
=20
 Could you please quote the RFC4511 on this?=C2=A0 This is not 100% clea= r to
me...

This is simply the definition of the protocolError result code. RFC 4511 =
Appendix A, section A.2.

...
>> We observed that the controlValue is than missing via
Wireshark. So w= e see a
...
>> difference on the line for empty octet strings, but should it
matter?
> Yes, in ASN.1 "empty value" and "absent value" are not the same
thing.=  E.g., you can
...
> store zero-length strings as attribute values. Those values are
"prese= nt" even though
...
> they are empty.
=20
 IMHO Microsoft and OpenLDAP are doing the same thing on a protocol leve= l. You are
both setting the controlValue to a struct {0,NULL}.
...
=20
 However with Microsoft, this is still translated to the network level, = whereas
with OpenLDAP this controlValue is omitted.
...
=20
 The "value" of the "controlValue" struct is however still NULL. So
it's=  not clear to me why it's translated to empty, not null. (is there an
som=
ewhere an
...
 assumption that translates zero-length octet string to non null
values?= )

See the ASN.1 specification of controls, RFC 4511 section 4.1.11. The val=
ue must be absent
if there is no value information that is associated with a control of its=
 type.

...
> MS is playing fast and loose with their specifications and
implementat= ion. This is
...
> at the very least a doc bug in their control specification, if
it's no= t just a bug
...
> in their client libraries. You should at least open a bug report
with = them so that
...
> it's on the record somewhere (even if they ultimately ignore
it).
>
> We can alter our parser to relax this check, I guess. Along with a com= ment
explaining
...
> that this is done for compatibility with MS's broken clients.
This is = not the first
...
> time we've run into MS spec and implementation disagreeing
with each o= ther...
...
=20
 We will submit the issue to MS. But in the case of this domainScope con= trol, it
should not matter if the value is empty or missing, only the con=
trolType is
...
 relevant. Could Postel's law be applied in this case? 
As I already said, we can relax this check.

But considering that Microsoft are the authors of both the spec and their=
 implementation of
this control, and the two don't agree, and this is not the only instance =
of such occurrences
(the pagedResults control also comes to mind) you have to wonder - are th=
ey just too stupid
and incompetent to implement their own spec, or have they broken things i=
ntentionally, to
prevent their clients from working with non-Microsoft servers...

--=20
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006