Victor Sudakov wrote: > > I have been trying to investigate what is needed in OpenLDAP to have > Microsoft Outlook 2007 display a list of names in the addressbook when > first accessed in the same way that it does with ActiveDirectory/Exchange. Here is a dump of an LDAP session between Microsoft Outlook and a CommunigatePro server: http://zalil.ru/34017194 where a list of names is being displayed. Could someone with sufficient LDAP knowledge look at it and advise how to configure OpenLDAP to achieve the same result?

Howard Chu wrote: > > Victor Sudakov wrote: > >> > >> I have been trying to investigate what is needed in OpenLDAP to have > >> Microsoft Outlook 2007 display a list of names in the addressbook when > >> first accessed in the same way that it does with ActiveDirectory/Exchange. > > > > Here is a dump of an LDAP session between Microsoft Outlook and a > > CommunigatePro server: http://zalil.ru/34017194 where a list of names > > is being displayed. > > > > Could someone with sufficient LDAP knowledge look at it and advise how to > > configure OpenLDAP to achieve the same result? > > Your trace shows two supportedControls and two supportedCapabilities. The > controls are for server-side sorting and paged results. OpenLDAP supports > paged results intrinsically, and server-side sorting when the sssvlv overlay > is configured. If those aren't sufficient to make Outlook behave, then things > get trickier. Howard, I have enabled the sssvlv overlay and now I have them in the server: [vas@gw ~] ldapsearch -h localhost -b '' -s base + | egrep '1.2.840.113556.1.4.800|1.2.840.113556.1.4.1791|1.2.840.113556.1.4.319|1.2.840.113556.1.4.473' supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.319 [vas@gw ~] However, Outlook still does not show the list of addresses. So I think the next step is necessary. > > supportedCapabilities is not a standard attribute, it appears to be specific > to M$AD. The two supportedCapabilities in your trace are: > 1.2.840.113556.1.4.800 LDAP_CAP_ACTIVE_DIRECTORY_OID > 1.2.840.113556.1.4.1791 LDAP_CAP_ACTIVE_DIRECTORY_LDAP_INTEG_OID > > If your sssvlv is configured correctly, and Outlook sees both Server Side > Sorting and Paged Results in the supportedControls that OpenLDAP returns, but > it still doesn't do what you want, then apparently Outlook requires the server > to claim to be Active Directory. It seems to be so. I did not explicitely configure any sssvlv-* options however, I just enabled the overlay in slapd.conf. > > You could fake this, by copying the schema definition of the > supportedCapabilities attribute and loading it into slapd. You would also need > to populate the values. You can use the "rootdse" directive to do that. I > would guess you only need the first capability, but I don't use Outlook so > have no way to verify this. Could you please be more specific how I can load the attribute into slapd and populate it? Please refer me to an example. Thank you very much in advance.

Howard Chu wrote: > You could fake this, by copying the schema definition of the > supportedCapabilities attribute and loading it into slapd. You would also need > to populate the values. You can use the "rootdse" directive to do that. I > would guess you only need the first capability, but I don't use Outlook so > have no way to verify this. Could you please be more specific how I can load the attribute into slapd and populate it? Please refer me to an example.

I don't know why "SUPPORTEDCAPABILITIES" is all caps.

What I know is that the trick did not help, Outlook still does not produce a list of addresses in the addressbook.

Michael Str?der wrote: > Victor Sudakov wrote: >> I don't know why "SUPPORTEDCAPABILITIES" is all caps. > > Because it's not in the subschema. You have to add it there. Where could I obtain a .schema definition? "grep -i supportedCapabilities /usr/local/etc/openldap/schema/*" comes up with nothing.

Outlook does show contacts from the OpenLDAP addressbook when I specifically search for them, so my general setup (attributes etc) seems to be correct. But I want it to show all the contacts before any search is done. The user can them pick the contacts from the list with a mouse and send mail to them.

>> Victor Sudakov wrote: >>> I don't know why "SUPPORTEDCAPABILITIES" is all caps. >> >> Because it's not in the subschema. You have to add it there. > > Where could I obtain a .schema definition? > "grep -i supportedCapabilities /usr/local/etc/openldap/schema/*" > comes up with nothing. It's a vendor-specific attribute type defined in MS AD: http://msdn.microsoft.com/en-us/library/cc223359%28v=prot.20%29.aspx You might want to grab it from MS AD subschema subentry or from Samba sources.

When I try to browse an addresslist from Outlook, the OpenLDAP server gives the following error: 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] What is this error? Could someone please interpret it? I almost believe that if I can get rid of it, I will have a browseable addresslist in Outlook.

Cl?ment OUDOT wrote: > > > > When I try to browse an addresslist from Outlook, the OpenLDAP server > > gives the following error: > > > > > > 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] > > > > > > What is this error? Could someone please interpret it? I almost believe that if I can get rid of it, I > > will have a browseable addresslist in Outlook. > > As I already replied : > > > the problem can be that Outlook use SSSVLV controls on attributes > without ordering rules in OpenLDAP. Unfortunately, the 'name' > attribute has no ordering rules, so you can't sort results on name > (this includes, cn, sn, gn attributes, because they inherit from > name). We do not have this limitation on AD (but it breaks LDAP > standard). I don't care about LDAP standard in this particular installation. I need an OpenLDAP server at this site only as a shared address book, it will perform no other function and will never interoperate with anything else. > > > You can't use server side sort control on cn or sn in OpenLDAP, this > will always return an error because there is no ordering rule for > these attributes. So if OpenLDAP can be tweaked to provide server side sort control on cn or sn, I would go for it. Can it be done by modifying the 'name' attribute in the core.schema? Or by a patch?

Cl?ment OUDOT wrote: [dd] >>> the problem can be that Outlook use SSSVLV controls on attributes >>> without ordering rules in OpenLDAP. Unfortunately, the 'name' >>> attribute has no ordering rules, so you can't sort results on name >>> (this includes, cn, sn, gn attributes, because they inherit from >>> name). We do not have this limitation on AD (but it breaks LDAP >>> standard). >> >> I don't care about LDAP standard in this particular installation. >> I need an OpenLDAP server at this site only as a shared address book, >> it will perform no other function and will never interoperate with >> anything else. >> >>> >>> >>> You can't use server side sort control on cn or sn in OpenLDAP, this >>> will always return an error because there is no ordering rule for >>> these attributes. >> >> So if OpenLDAP can be tweaked to provide server side sort control on >> cn or sn, I would go for it. Can it be done by modifying the 'name' >> attribute in the core.schema? Or by a patch? > > You can try to patch schema_prep.c in OpenLDAP source, find the 'name' > attribute definition and add caseIgnoreOrderingMatch ordering rule to > it. > > You then need to rebuild OpenLDAP from sources. Hurrah! It seems to be working. At least I can now browse the small test addressbook I have created for test purposes. Many thanks to you and to all the community for this advice. Should I expect any problems with slapd because of this patch? Like unexpected coredumps, corrupted database etc?

> > > >>>> the problem can be that Outlook use SSSVLV controls on attributes > >>>> without ordering rules in OpenLDAP. Unfortunately, the 'name' > >>>> attribute has no ordering rules, so you can't sort results on name > >>>> (this includes, cn, sn, gn attributes, because they inherit from > >>>> name). We do not have this limitation on AD (but it breaks LDAP > >>>> standard).

2012/12/7 Victor Sudakov <vas(a)mpeks.tomsk.su&gt;: >> > > >> > >>>> the problem can be that Outlook use SSSVLV controls on attributes >> > >>>> without ordering rules in OpenLDAP. Unfortunately, the 'name' >> > >>>> attribute has no ordering rules, so you can't sort results on name >> > >>>> (this includes, cn, sn, gn attributes, because they inherit from >> > >>>> name). We do not have this limitation on AD (but it breaks LDAP >> > >>>> standard). > > Mark, > > Could you be more specific which LDAP standard it breaks? Is there an > explicit prohibition for the 'name' attribute to have ordering rules? > In the RFCs somewhere? > See http://tools.ietf.org/html/rfc4519#page-11

>>>>>>>>> inherit from name). We do not have this limitation >>>>>>>>> on AD (but it breaks LDAP standard). >>> >>> Mark, >>> >>> Could you be more specific which LDAP standard it breaks? Is >>> there an explicit prohibition for the 'name' attribute to have >>> ordering rules? In the RFCs somewhere? >>> >> >> See http://tools.ietf.org/html/rfc4519#page-11 > > Yes, but why do you think it is a restrictive definition and no > more optional properties can be *added* (without removing the > mandatory ones, of course)? My best guess is that because this thinking leads to the very problems ("Embrace, Extend, Extinguish") that have plagued some notable implementations of certain standards. They have been harmful to interoperability for quite some time already.

> "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'd argue: Ask Microsoft to make it configurable.

> 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.

>> 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.

> 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. No, it is not requesting it. You can request the rule you want as part of the filter. See <http://www.openldap.org/software/man.cgi?query=slapcat&apropos=0&... for an example of a filter that specifies the matching rule in a filter.

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.

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.

Philip Guenther wrote:

> 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 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).

If I wanted to reproduce the Outlook's incorrect request, what ldapsearch command line should that be?

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?

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

> > 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

> 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).

> (plus whatever binding option you need, of course) > > However, that's not what Outlook does. To quote the dump you

> 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?

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?

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.

Here is the conversation for you inline: [..] 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

Mark Coetser wrote: >>> >>>>>> the problem can be that Outlook use SSSVLV controls on attributes >>>>>> without ordering rules in OpenLDAP. Unfortunately, the 'name' >>>>>> attribute has no ordering rules, so you can't sort results on name >>>>>> (this includes, cn, sn, gn attributes, because they inherit from >>>>>> name). We do not have this limitation on AD (but it breaks LDAP >>>>>> standard). Mark, Could you be more specific which LDAP standard it breaks? Is there an explicit prohibition for the 'name' attribute to have ordering rules? In the RFCs somewhere?

When I try to browse an addresslist from Outlook, the OpenLDAP server gives the following error: 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]