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/