openldap root schema

[Tim Writer]

"Kihara Muriithi" <william.muriithi-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> writes:

> 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

This looks fine. There's no need for your root schema to have uid
attribute.  Typically, only your users need a uid attribute. You can store
users within any OU but typical Linux setups put users in the people us as
you show below. Mapping of LDAP to Linux user credentials is handled by
libnss-ldap and libpam-ldap, usually configured in /etc/libnss-ldap.conf
and /etc/pam_ldap.conf. These need to be consistent with your LDAP schema,
usually configured in /etc/ldap/slapd.conf.

> ## Build the people ou.
> dn: ou=people,dc=afsat,dc=com
> ou: people
> objectClass: organizationalUnit

Hmmm. There's no "objectClass: top" which is unusual.

> 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

Hmmm. I'm not sure why you would have object classes account and
posixAccount. Also, it's usual to have object class inetOrgPerson for
e-mail etc. support.

> 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

You appear to have a schema problem.

>  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.

No, you'll need the uid field.

>  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?

It's the same field. Since it's a component of the dn, you need it.  I
would focus on fixing your schema, getting a clean load, and making sure
password file, etc. lookups work with LDAP before worrying about SASL. You
can test this getent.

> Would this field exist on the output below?

No, because you haven't shown a user, i.e. an entry within the people ou.
If you showed a user, it should have a uid.

> # 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

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
647.722.5301                                      toronto, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists