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.