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? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[email protected]
