Re: ldapadd: Naming violation & alias

[Dustin Doris <openldap@mail.doris.cc>]

On Fri, 22 Aug 2003, Emmanuel.Leguy wrote:

> Hello,
>
> I checked the core.schema the code of slapd and the rfc 2256: an alias
> must not contain a cn attribute.
> But, as I said, ldapadd complains because he needs a cn attribute.
> If I add a cn attribute, ldapadd complains because this attribute (cn)
> is not allowed in aliases.
> A dirty solution is to add an ObjectClass like this:
>
> objectclass ( x.x.x.x NAME 'myAlias'
>        DESC 'not RFC2256: an alias'
>        SUP alias STRUCTURAL
>        MUST cn )
>
> or change the alias definition in slapd code:
>
> objectclass ( 2.5.6.1 NAME 'alias'
>        DESC 'not RFC2256: an alias'
>        SUP top STRUCTURAL
>        MUST aliasedObjectName $ cn )
>
> A better solution (so the rfc should be respected) is to pach ldapadd.
> In fact, the function entry_naming_check() in servers/slapd/schema_check.c.
>
> What do you thing? Am I wrong?
>
> Thanx,
>
> Manu.
>

Interesting, I never looked into alias.  I think that creating a new
objectclass that is sup alias, isn't a bad idea.  The link below to a
draft actually has MAY *, in its newly created objectclass.

http://www.globecom.net/ietf/draft/draft-byrne-ldap-alias-00.html