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

[hyc@symas.com]

Philip Brusten wrote:
>=20
> On 25/10/2019 18:41, Howard Chu wrote:
>> philip.brusten@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/