I am about to set up a LDAP directory. It is used as a tool to communicate user permissions from a web application to WebDav file system access, e.g. adding a user to the web platform shall allow login to the file system with the same credentials. There are no other usages intended. Following this German tutorial which encourages the use of the attributes c
, o
, ou
etc. over dc
, I configured the following suffix and root:
suffix "ou=webtool,o=myOrg,c=de"
rootdn "cn=ldapadmin,ou=webtool,o=myOrg,c=de"
Server starts and I can connect to it by LDAP Admin, which reports “LDAP error: Object lacks”. Well, there aren’t any objects yet.
I now want to create the root and admin elements from shell. I created an init.ldif
file:
dn: ou=webtool,o=myOrg,c=de
objectclass: dcObject
objectclass: organization
dc: webtool
o: webtool
dn: cn=ldapadmin,ou=webtool,o=myOrg,c=de
objectclass: organizationalRole
cn: ldapadmin
Trying to load the file runs into an error, telling me that ou
is not allowed:
server:~ # ldapadd -x -D "cn=ldapadmin,ou=webtool,o=myOrg,c=de" -W -f init.ldif
Enter LDAP Password:
adding new entry "ou=webtool,o=myOrg,c=de"
ldap_add: Object class violation (65)
additional info: attribute 'ou' not allowed
I am not using ou
anywhere except in the suffix, so the question: Isn’t it allowed here? What is allowed here?
There are numberous dependencies for the creation of elements, and error messages are rather confusing if you don’t know of the concept. The
objectclass
isn’t necessarilydcObject
for the databases’ root node, as it is likely to guess when you read several tutoriales. Instead, it must correspond to the object’s type: Here, for a name starting withou=
, it must beorganizationalUnit
. I found this piece of information in these tables. Further on, the object class dictates which properties must and can be added in the record. Here,organizationalUnit
must have anou:
entry and must not have neitherdc:
noro:
entries. Thus, the healthyinit.ldif
file looks like that:Note: The page also states: “While many objectClasses show no MUST attributes you must (ouch) follow any hierarchy […] to determine if this is the really case.” I thought that would mean my root record would have to provide the must fields for
c=
ando=
(c:
ando:
, respectively) but this is not the case.