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?