11:25 a.m.
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/
1022
days inactive
1022
days old
0 comments
1 participants
participants (1)
-
hyc＠symas.com