[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapadd: Naming violation & alias

Dustin Doris wrote:

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



OK. It is a solutition. But it forces us to change our applications code...
So I'd prefer that openldap 2.1.22 behaves like openldap 2.0 for this point => patch.

Another question: Does someone use alias with openldap 2.1? How?

Thanx,

Manu.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature