[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP as an address book for MS Outlook
Victor Sudakov wrote:
> Philip Guenther 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.
That is the hopsing point.
The client may or may not specify an orderingRule.
> > > 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.
And if the client does not specify an orderingRule, the Server MUST use
the default orderingRule for this attribute.
This is what openldap is doing.
> > 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
>
> Yes, this works on an unpatched slapd, even if I use "!sss". What is
> the difference between this request and the bad one from Outlook (in
> plain words, if you can, please).
The request from Outlook is NOT bad, nor wrong. It just depends on the
AD specific Schema implementation. And this HAVE an orderingRule
specified which violates the RFCs.
> > (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.
>
> If I wanted to reproduce the Outlook's incorrect request, what
> ldapsearch command line should that be?
Once again, Outlook does Not use an incorrect request.
> Also, do I understand correctly that if Outlook explicitely included
> an orderingRule in its request, there would be no error from the
> server even if the orderingRule for this attribute is not defined in
> the schema?
If Outlook would specify an orderingRule in the request, yes, then the
search would success. Even, if Outlook communicates with an RFC
compatible server.
The only way to make it working, is to follow M$s approach with non-
standard schemas. Either patch the schemas which openldap provides (what
you have already done) or use the AD schemas. Both will end up in a non
RFC conform LDAP server.
Other options:
- Ask the developer of Outlook, if they are willing to fix this.
- Use an alternate Mail Client.
--
Harry Jede