Re: OpenLDAP as an address book for MS Outlook

[Victor Sudakov <vas@mpeks.tomsk.su>]

Michael Str?der wrote:
> > Michael Str?der wrote:
> >>> "Be liberal in what you receive and conservative in what you send" is
> >>> a good old rule.
> >>
> >> If you change the subschema subentry you change something sent to the client.
> > 
> > I still don't understand what's so bad about being able to request the
> > ordering of the 'cn' attribute.
> 
> Actually the client could request that.

The client does request that, it seems, but OpenLDAP produces an error. 
It requests a SortKeyList control on the attribute 'cn'. But OpenLDAP
returns an error.
> 
> >> I'd argue: Ask Microsoft to make it configurable.
> > 
> > Not that I very much like Microsoft or am trying to defend them, but
> > they *have* made it configurable. You can set DisableVLVBrowsing=1 and
> > Outlook becomes compatible with OpenLDAP. It turns off addressbook
> > browsing, of course, but searching still works.
> 
> 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.

Here is the conversation for you inline:


Request:

Lightweight Directory Access Protocol
    LDAPMessage searchRequest(11) "dc=dtdm,dc=tomsk,dc=ru" wholeSubtree
        messageID: 11
        protocolOp: searchRequest (3)
            searchRequest
                baseObject: dc=dtdm,dc=tomsk,dc=ru
                scope: wholeSubtree (2)
                derefAliases: neverDerefAliases (0)
                sizeLimit: 0
                timeLimit: 0
                typesOnly: False
                Filter: (&(mail=*)(cn=*))
                    filter: and (0)
                        and: (&(mail=*)(cn=*))
                            and: 2 items
                                Filter: (mail=*)
                                    and item: present (7)
                                        present: mail
                                Filter: (cn=*)
                                    and item: present (7)
                                        present: cn
                attributes: 20 items
        [Response In: 7]
        controls: 2 items
            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

Response:


Lightweight Directory Access Protocol
    LDAPMessage searchResDone(11) inappropriateMatching (serverSort control: No ordering rule) [0 results]
        messageID: 11
        protocolOp: searchResDone (5)
            searchResDone
                resultCode: inappropriateMatching (18)
                matchedDN: 
                errorMessage: serverSort control: No ordering rule
        [Response To: 6]
        [Time: 0.002066000 seconds]

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru