openldap root schema
Kihara Muriithi
william.muriithi-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Tue Jan 16 16:15:34 UTC 2007
Hi all,
After the recent slides that were shared on this group, I made up my mind
to set up ldap, going as deep as I can. I have however hit a wall in the
last three days and don't seem to have an idea how to go around them. I am
humbly asking for help, so that I can move ahead hopefully.
The main problem started because my root schema don't have a "uid", and
this looks critical. I haven't figured how it should be added and my root
schema currently looks as below
dn: dc=afsat,dc=com
dc: afsat
objectclass: top
objectclass: dcObject
objectclass: organization
o: Afsat
## Build the people ou.
dn: ou=people,dc=afsat,dc=com
ou: people
objectClass: organizationalUnit
This was inserted successfully by slapadd tool. I then restarted openldap
and attempted populating it will user extracted from /etc/passwd file and
that is when I hit my first problem. The migration tool produced a ldif file
of the following format.
dn: uid=wmuriithi,ou=people,dc=afsat,dc=com
uid: wmuriithi
cn: William Muriithi
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}LnMJ/n2rQsR.c
shadowLastChange: 11108
shadowMax: 99999
shadowWarning: 7
shadowFlag: 134539460
loginShell: /bin/bash
uidNumber: 530
gidNumber: 530
homeDirectory: /home/wmuriithi
gecos: William Muriithi
Attempting to feed this data to ldap lead to this error
adding new entry "cn=William Muriithi,dc=afsat,dc=com"
ldap_add: Object class violation (65)
additional info: attribute 'uid' not allowed
I have rebuild the database a couple of time with varying schema in an
attempt to avoid the above issue without success. Eventually, I gave up,
stripped the uid field and feed it to ldap hoping it wouldn't haunt me
again. I was wrong, really wrong.
The simple setup was over, and I started to face sasl and that is when the
issue occured again. See, after configuring sasl, one has to go back to
slap.conf, comment out rootdn and insert the following line
saslRegexp uid=(.*),cn=localhost.localdomain,cn=DIGEST-MD5,cn=auth
uid=$1,ou=people,dc=afsat,dc=com
On closer observation, the above line has a field uid. Now, what is this
supposed to mean? Is it the same uid I left out when damping passwd file
content to ldap or what is it? Would this field exist on the output below?
# afsat.com
dn: dc=afsat,dc=com
dc: afsat
objectClass: top
objectClass: dcObject
objectClass: organization
o: Afsat
# people, afsat.com
dn: ou=people,dc=afsat,dc=com
ou: people
objectClass: organizationalUnit
# radius, afsat.com
dn: cn=radius,dc=afsat,dc=com
cn: radius
sn: Admin
userPassword:: cmFkaXVz
objectClass: person
On the side note, one has to insert users on sasldb. What is the idea
behind this action? I assume all the authentication data should be held by
ldap, what do we do with this sasl data, assuming the above assumption are
correct? I believe if I can be sure what these two database do, I can
progress. And finally, does a default ldap that come with fedora support
GSSAPI? I was forced to use DIGEST-MD5, as I didn't wish to install from
source. Installing from source would have required ACL configuration, and I
plan to avoid that untill I have messed up with ldap seriously.
Thanks in advance
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20070116/fd64ac70/attachment.html>
More information about the Legacy
mailing list