|
Hi *,
Using openLDAP 2.1.4, BDB Backend, I noticed that I
can create an organizationalUnit named "uid=myorg,o=myroot" although uid is
actually not an attribute of the organizationalUnit class.
To make it append, I only omitted the naming
attribute in the creation request. In LDIF for example :
dn:uid=myorg,o=myroot
objectclass: top objectclass: organizationalUnit ou: myorg I known that LDAPv3 states that I should have
included an "uid:myorg" line at the end of the previous LDIF record, and that in
this case, OpenLDAP would have complained about an objetclass violation or
something like that. But I found rather strange that OpenLDAP lets such weird
entries be created (If I try to modrdn the entry
with deleteoldrdn=false, I do get the objectclass violation error
!)
Now, let's assume I'm in a trouble with an
LDAP client application which is not so LDAPv3 compliant as it claims, delivered
without source code (it happens).
As this application has been developped, tested and
is anyway intented to work with an iPlanet directory, the applciation
creates LDAP entries without repeating the naming attribute in the entry
attributes. No problem from iPlanet point of view : it automatically extracts
the naming attribute from the dname and adds it to the attributes of the entry ;
no way to create uid=myorg,o=myroot" on it without disabling schema check, for
example !
When trying this application in front of an
OpenLDAP, slapd complains about object class violation since the
application does not include the 'ou' in the entry attributes when
creating an organizationalUnit unit.
I wonder whether this OpenLDAP behavior about
naming attributes is correct (sounds correct for me, but a little bit
strange too), and whether a code modification allowing an iPlanet-like
behavior would be a good thing (or maybe already exists : I dream of a
SLAPD_IPLANET_NAMING_COMPATIBLE define or whatever)
Has anybody here got a solution ?
Thanks in advance
Bruno Spieler
|