Re: OpenLDAP as an address book for MS Outlook

[Philip Guenther <guenther+ldaptech@sendmail.com>]

On Mon, 10 Dec 2012, Victor Sudakov wrote:
> You have lost me. The bad Outlook request is not about filtering, it's 
> about sorting (ordering). It is ordering that is denied by the server. 
> There is nothing about ordering in the link you have given.

Let's look back at the message you're replying to, Michael Ströder's:

> Since you insist on using a rather unusable feature you should probably 
> dive into RFC 2891 and look at this:
> 
>       SortKeyList ::= SEQUENCE OF SEQUENCE {
>                  attributeType   AttributeDescription,
>                  orderingRule    [0] MatchingRuleId OPTIONAL,
>                  reverseOrder    [1] BOOLEAN DEFAULT FALSE }
> 
> The LDAP client can (optionally) define which ordering matching rule to 
> use for a particular attribute type. So ask M$ to send 'orderingRule' in 
> the SSS request control if they do not send it yet. I'm too lazy to 
> check in the PCAP data you posted before.

That "orderingRule [0] MatchingRuleId OPTIONAL" line means that after each 
attributeType to sort on, the client can indicate what orderingRule should 
be used to do the ordering for that attribute.

So, it would seem that a client should be able to portably request sorting 
on the cn attribute in a case-insensitive fashion by sending the control 
with that optional orderingRule filled in.  That should work against any 
server that supports the control and the desired case-insensitive rule.

It should be possible to test this against OpenLDAP with something like:

	ldapsearch -E sss=cn:caseIgnoreOrderingMatch '(cn=*)' cn

(plus whatever binding option you need, of course)


However, that's not what Outlook does.  To quote the dump you showed:
            Control
                controlType: 1.2.840.113556.1.4.473 (sortKeyList)
                criticality: True
                SortKeyList: 1 item
                    SortKeyList item
                        attributeType: cn
            Control
                controlType: 2.16.840.1.113730.3.4.9 (LDAP_CONTROL_VLVREQUEST VLV)
                controlValue: 308400000012020100020127a08400000006020101020100

Note that an orderingRule is not given, thus unnecessarily making the 
client dependent on the server extending a standard schema.


Philip Guenther