Re: Outlook LDAP Addressbook Browsing - Add ORDERING caseIgnoreOrderingMatch on CN or NAME core attributes without source code modification and re-compilition

On Fri, Dec 5, 2014 at 1:23 PM, Howard Chu hyc@symas.com wrote:

Richard LEGER wrote:

...

On Thu, Jul 10, 2014 at 10:00 PM, Quanah Gibson-Mount <quanah@zimbra.com mailto:quanah@zimbra.com> wrote:

--On Thursday, July 10, 2014 2:58 PM +0100 Richard LEGER
<richard.leger@gmail.com <mailto:richard.leger@gmail.com>> wrote:

    Is there other way(s) via a local schema or else to modify/extend
    definition of OpenLDAP core attributes without modifying source
    code and
    recompiling?


No.  You shouldn't be using the garbage OpenLDAP build shipped with
Ubuntu anyway.

--Quanah

For information to those that may interested (and for the record)...

Here is a simple description of the openldap <-> Outlook ldap addressbook issue: Source: http://victor-sudakov.livejournal.com/124269.html Translation: http://translate.google.co.uk/translate?hl=en&sl=ru&u=http:/ /victor-sudakov.livejournal.com/124269.html&prev=search

In addition, for the address list organization to be displayed in Outlook, it seems necessary to patch the file /etc/openldap/schema/core.schema in order to add 'company' attribute as alias to 'o', something like:

attributetype ( 2.5.4.10 NAME ( 'company' 'o' 'organizationName' ) DESC 'RFC2256: organization this object belongs to' SUP name )

Nonsense. This is why we have the rewrite module and attribute mapping functions.

Modifying IETF published schema is prohibited.

Thanks for the info. That make sense. I wasn't aware of this functionality.

Just thought that may be helpful to know and record on the forum...

...

No. Breaking the server is not the way to adapt schema for broken clients.

I understand this policy and I agree with it in theory but in practice once sometime has to be pragmatic when it needs to implement local exceptional work around for the sake of functionality and end-users life :)

They are situations where you have no control over the broken client nor you can have it changed. Therefore you can only try to apply solution via what is in your control, the server side in a given environment.

Those minor changes in core.schema discussed here won't really break the server, only remove full compliance with RFC while adding interoperability with some broken clients.

In a closed private managed environment without external interaction that can be viewed as an acceptable temporary solution until broken clients are fixed.

Thanks for your support.