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

[hyc@symas.com]

philip.brusten@kuleuven.be wrote:
> Full_Name: Philip Brusten
> Version: 2.4.47
> OS: 
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2a02:2c40:100:b210::1:c3bc)
> 
> 
> Hi
> 
> we are experiencing issues with MS LDAP clients that connect to our OpenLDAP
> servers since v2.4.47, because of the fix for issue ITS#8840
> 
> That fix was based on (old?) documentation of MS from
> https://msdn.microsoft.com/en-us/library/aa366979%28v=vs.85%29.aspx
> The is no current version of this document.

The above URL redirects me to https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ldap/ldap-server-domain-scope-oid

Our implementation conforms to the above spec.

> At
> https://docs.microsoft.com/en-us/windows/win32/api/_ldap/ there is a link to
> Lightweigt Directory Access Protocol
> (https://docs.microsoft.com/en-us/windows/desktop/ldap), but it gives a 404.
> 
> MS is the owner of that LDAPControl LDAP_SERVER_DOMAIN_SCOPE_OID
> 1.2.840.113556.1.4.1339. According to the RFC4511 [1] the controlValue is
> defined by its specification:
> 
>>   The controlValue may contain information associated with the
>>   controlType.  Its format is defined by the specification of the
>>   control.  Implementations MUST be prepared to handle arbitrary
>>   contents of the controlValue octet string, including zero bytes.  It
>>   is absent only if there is no value information that is associated
>>   with a control of its type.  When a controlValue is defined in terms
>>   of ASN.1, and BER-encoded according to Section 5.1, it also follows
>>   the extensibility rules in Section 4.
> 
> The latest specification can be found at:
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/ba5f20c6-7753-417c-b93d-e66e722458ed
> 
>> "When sending this control to the DC, the controlValue field of the Control
> structure is omitted."
> 
> We observed that whenever MS clients are sending the domainScope control they
> add an octet string as the controlValue with bytes "04 00". But this causes the
> OpenLDAP code 
> if ( !BER_BVISNULL( &ctrl->ldctl_value )) {
> to evaluate to true, which returns the LDAP_PROTOCOL_ERROR in OpenLDAP.

This is the correct response to a malformed message according to RFC4511.
> 
> The LDAP Extended Control spec of MS states [2]:
>> If the controlValue field contains data that is not in conformance with the 
>> specification of the control, including the case where the controlValue field
> contains 
>> data and the specification of the control states that the controlValue field
> is omitted, 
>> then if the control is marked critical the server returns the error 
>> unavailableCriticalExtension / ERROR_INVALID_PARAMETER. If the controlValue
> field is 
>> incorrect but the control is not marked critical, the server ignores the
> control.

MS seems to be inventing their own protocol here since RFC4511 contains no such language.
> So the server should only return an error when the control is marked critical.
> Otherwise it should *ignore* the control.
> 
> Is it possible to relax the validation of the LDAP control at [3]? Since there
> is no value associated with this control, it should not matter if the
> controlValue is missing or an empty octet string {0,NULL}... 
> 
> The ldapsearch code sets the controlValue to [4]:
>> c[i].ldctl_value.bv_val = NULL;
>> c[i].ldctl_value.bv_len = 0;
> We observed that the controlValue is than missing via Wireshark. So we 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 "present" even though
they are empty.

MS is playing fast and loose with their specifications and implementation. This is
at the very least a doc bug in their control specification, if it's not 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 comment 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 other...

> 
> Wireshark trace of MS LDAP client with domainScope control:
> https://i.imgur.com/gwBjLMr.png
> Wireshark trace of ldapsearch with domainScope control:
> https://i.imgur.com/2RbFkIY.png
> 
> Regards,
> Philip
> 
> 
> [1] https://tools.ietf.org/html/rfc4511#section-4.1.11
> [2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c5e87db-4728-4f29-b164-01dd7d7391ea
> [3] https://github.com/openldap/openldap/blob/master/servers/slapd/controls.c#L1717
> [4] https://github.com/openldap/openldap/blob/master/clients/tools/ldapsearch.c#L1154
> 
> 


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