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]