Dear Colleagues,
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.
From what I have found out from Web searching, MS Outlook requires a certain set of overlays, supportedCapabilities and supportedControls from the LDAP server to show the addressbook this way. The CommunigatePro LDAP server can emulate those.
Are there any success stories or recommendations or howtos how to setup OpenLDAP to provide such service?
I am running openldap-server-2.4.33 on FreeBSD. I have tried various combinations of sssvlv and valsort overlays to no avail.
Outlook does show contacts from the OpenLDAP addressbook when I specifically search for them, so my general setup (schema etc) seems to be correct.
Thank you very much in advance for any input.
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?
Thank you very much in advance.
Victor Sudakov 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.
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.
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.
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.
2012/11/30 Victor Sudakov vas@mpeks.tomsk.su:
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.
Hi,
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).
Clément.
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).
Can this be emulated in OpenLDAP?
Victor Sudakov wrote:
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.
Read the slapd.conf(5) or slapd-config(5) manpage. See test000 in the test suite for an example.
Howard Chu wrote:
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.
Read the slapd.conf(5) or slapd-config(5) manpage. See test000 in the test suite for an example.
I have added rootDSE /usr/local/etc/openldap/fakead.ldif to slapd.conf with the following contents:
dn: supportedCapabilities: 1.2.840.113556.1.4.800 supportedCapabilities: 1.2.840.113556.1.4.1791
Now the output from the server looks like this:
[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 SUPPORTEDCAPABILITIES: 1.2.840.113556.1.4.800 SUPPORTEDCAPABILITIES: 1.2.840.113556.1.4.1791 [vas@gw ~]
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.
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.
What I know is that the trick did not help, Outlook still does not produce a list of addresses in the addressbook.
I really wonder what the problem is.
Some customer users are using Outlook when querying a standard OpenLDAP server. No fakes in rootDSE were needed.
Some attributes might not be interpreted by Outlook like expected though. So for another customer we added a separate database (with slapd-relay) with attribute mapping via slapo-rwm especially for Outlook. So Outlook users simply configure a special search base and get roomNumber etc. mapped to attributes needed by Outlook.
Ciao, Michael.
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.
What I know is that the trick did not help, Outlook still does not produce a list of addresses in the addressbook.
I really wonder what the problem is.
Some customer users are using Outlook when querying a standard OpenLDAP server. No fakes in rootDSE were needed.
As I wrote in the first post, I want 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.
That is, before a customer searches for anything, she should already see a list of names. Do your customer users see that?
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.
I cannot find any other words to explain myself. Anyone who has ever seen the way the Outlook addressbook works with Exchange (and does not work this way with OpenLDAP) should probably understand me.
Victor Sudakov wrote:
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.
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.
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.
Sorry, missed that part of the discussion. Well, this is not usable at all anyway if the LDAP server contains more than a few dozens of contacts. So that's not a viable requirement for me.
Ciao, Michael.
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.
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.
Thanks, I will try.
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.
Sorry, missed that part of the discussion. Well, this is not usable at all anyway if the LDAP server contains more than a few dozens of contacts. So that's not a viable requirement for me.
Somehow it is quite usable with an Exchange or Communigate server containing thousands of contacts. I have seen it with my own eyes.
Outlook does not request all those contacts at once to populate the addresslist (what would be madness), it just shows the beginning of the list, and I think it requests additional entries as you scroll the list.
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.
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.
Neither in the link above nor in the samba-4.0.0alpha11 sources could I find the schema definition of the supportedCapabilities attribute.
If you know of one I could include into slapd.conf, please point it out.
I expect to find something like
attributetype ( blah blah NAME 'supportedCapabilities' ... EQUALITY ... )
but have not been able to find anything so far. I have also tried to google for something like "attributetype NAME supportedcapabilities" with no useful results
It still seems odd that noone has ever tried to achieve the behavior in question with Outlook+OpenLDAP.
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.
2012/12/6 Victor Sudakov vas@mpeks.tomsk.su:
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).
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.
Clément.
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?
2012/12/6 Victor Sudakov vas@mpeks.tomsk.su:
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?
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.
Clément.
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?
On 07/12/2012 08:48, Victor Sudakov wrote:
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?
Please can you post your patch file as well.
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).
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?
Please can you post your patch file as well.
It's outrageously simple. I was surprised I could not redefine the properties of the 'name' attribute in the runtime config and had to recompile slapd.
--- ./openldap-2.4.33/servers/slapd/schema_prep.c.orig 2012-12-07 09:54:56.000000000 +0700 +++ ./openldap-2.4.33/servers/slapd/schema_prep.c 2012-12-07 09:58:10.000000000 +0700 @@ -908,6 +908,7 @@ "DESC 'RFC4519: common supertype of name attributes' " "EQUALITY caseIgnoreMatch " "SUBSTR caseIgnoreSubstringsMatch " + "ORDERING caseIgnoreOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )", NULL, SLAP_AT_ABSTRACT, NULL, NULL,
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?
2012/12/7 Victor Sudakov vas@mpeks.tomsk.su:
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?
See http://tools.ietf.org/html/rfc4519#page-11
Clément.
Cl?ment OUDOT wrote:
2012/12/7 Victor Sudakov vas@mpeks.tomsk.su:
>> 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?
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)?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2012 10:51 AM, Victor Sudakov wrote:
Cl?ment OUDOT wrote:
2012/12/7 Victor Sudakov vas@mpeks.tomsk.su:
>>> 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?
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.
- -- Ondrej Kuznik
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
Ondrej Kuznik wrote:
[dd]
>>>> 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?
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.
What you say may be valid and reasonable. However I wanted to know if there is an explicit prohibition to add an additional functionality such as sorting to some object types.
There seems to be none.
"Be liberal in what you receive and conservative in what you send" is a good old rule. I don't see why answering this particular search request without generating an error should cause any problems. Maybe this is because I know little of LDAP, then enlighten me please about the technical details and what exactly would break.
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.
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.
Victor Sudakov 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.
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.
Ciao, Michael.
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]
--On Monday, December 10, 2012 8:59 AM +0700 Victor Sudakov vas@mpeks.tomsk.su wrote:
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&sektion=0&manpath=OpenLDAP+2.4-Release&format=html for an example of a filter that specifies the matching rule in a filter.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
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&sektion=0&manpath=OpenLDAP+2.4-Release&format=html 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.
--On Monday, December 10, 2012 11:49 AM +0700 Victor Sudakov vas@mpeks.tomsk.su 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.
Ah, sorry. Misread what you were going for.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
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
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. 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
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 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?
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?
On Tue, 11 Dec 2012, Victor Sudakov wrote:
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).
The request above says: "fetch all entries that match the filter and sort them on their cn attribute value using the rule called caseIgnoreOrderingMatch"
The Outlook request is "fetch all entries that match the filter and sort them on their cn attribute value using the default sorting rule for the cn attribute, whatever that happens to be on this server"
If I wanted to reproduce the Outlook's incorrect request, what ldapsearch command line should that be?
Just leave out the explicit rule: ldapsearch -E sss=cn '(cn=*)' cn
should do the trick.
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?
That's how I understand it.
Philip Guenther
2012/12/11 Philip Guenther guenther+ldaptech@sendmail.com
On Tue, 11 Dec 2012, Victor Sudakov wrote: [...]
If I wanted to reproduce the Outlook's incorrect request, what ldapsearch command line should that be?
Just leave out the explicit rule: ldapsearch -E sss=cn '(cn=*)' cn
-E '!sss=cn' The requested extension is critical in the dump.
Colleagues,
Thanks a lot for the comprehensive explanations and examples.
There is one thing left: I don't understand why expanding the schema is a violation of the RFC. Is it written somewhere that the list of properties in the RFC is exhaustive?
You're not expanding it, you're altering it. The 'name' attribute type is defined by X.520, and used as is by RFC45xx(19?). There's no default sorting rule for this attribute. Changing its definition is not an expansion.
The commonName attribute is an expansion of the name attribute (it is based on it). You could define your own attribute based on name and add a sorting rule, this will be an expansion. And a new attribute.
Le 12 déc. 2012 07:23, "Victor Sudakov" vas@mpeks.tomsk.su a écrit :
There is one thing left: I don't understand why expanding the schema is a violation of the RFC. Is it written somewhere that the list of properties in the RFC is exhaustive?
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: 308400000012020100020127a08400000006020101020100Note 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.
Quanah Gibson-Mount wrote:
--On Monday, December 10, 2012 8:59 AM +0700 Victor Sudakov vas@mpeks.tomsk.su wrote:
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&sektion=0&manpath=OpenLDAP+2.4-Release&format=html for an example of a filter that specifies the matching rule in a filter.
In this case 'orderingRule' in the SSS request control has to be set. The search filter is not relevant here.
Ciao, Michael.
Victor Sudakov wrote:
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 does not what I meant..
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
..as you can see above. Please read my posting more thoroughly.
Ciao, Michael.
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 does not what I meant..
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
..as you can see above. Please read my posting more thoroughly.
Please rephrase your posting in more mundane words.
On 07/12/2012 11:13, Victor Sudakov wrote:
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?
wasnt written by me.
2012/12/7 Victor Sudakov vas@mpeks.tomsk.su
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?
You saw it in your patch. RFC4519. If you read RFC4519, you can see the "name" definition is derived from X.520. So it breaks both RFC4519 and X.520.
Victor Sudakov 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]
(This looks like wireshark output.)
The message "No ordering rule" means that at least one of the attributes sent in the request control does not have an ORDERING matching rules defined. Without seeing the request control we can't say more.
Ciao, Michael.
Michael Str?der wrote:
Victor Sudakov 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]
(This looks like wireshark output.)
The message "No ordering rule" means that at least one of the attributes sent in the request control does not have an ORDERING matching rules defined. Without seeing the request control we can't say more.
Sorry, the complete packet dump is here: http://zalil.ru/34039384
openldap-technical@openldap.org
-
Clément OUDOT -
Erwann Abalea -
harry.jede＠arcor.de -
Howard Chu -
Mark Coetser -
Michael Ströder -
Ondrej Kuznik -
Philip Guenther -
Quanah Gibson-Mount -
Victor Sudakov