[KLUG Members] ldap102 presentation

[Adam Tauno Williams]

> I looked for the ldap102 presentation on the past presentation page and
> on the ftp server.  Did not succeed at finding it.

Nope, I haven't posted it yet.  I lost my SSH key when my laptop
harddrive crashed and haven't heckled the sitemaster about installing a
new one yet.  Got to remember to backup those hidden files! :)

> Also was looking for the appropriate schema and migration script
> combination.  On a suse machine I did not succeed with groups from what
> was being output from migration scripts.
> Using the most recent download from padl
> ./migrate_group.pl /etc/group > group.ldif
> yields entries like
> dn: cn=root,ou=Group,dc=alum,dc=schupan,dc=com
> objectClass: posixGroup
> objectClass: top
> attempting an add
> cat group.ldif | ldapadd -v -h localhost -x -w gi8one2 -D
> "cn=Manager,dc=alum,dc=schupan,dc=com"
> gets the following output
> adding new entry "cn=root,ou=Group,dc=alum,dc=schupan,dc=com"
> ldapadd: update failed: cn=root,ou=Group,dc=alum,dc=schupan,dc=com
> ldap_add: Object class violation (65)
>         additional info: no structural object class provided

Yep, maybe I should have covered this one.  The RFC2307 schema is broken
in a couple of aspects.

I thing the correct solution is to use RFC2307BIS groups, which are
supported by recent versions of NSS, and make using groups to manage DSA
access much more straigh forward.

A BIS group looks like -

dn: cn=mygroup,....
objectclass: top
objectclass: posixGroup
objectclass: groupOfNames
cn: mygroup
gidNumber: 666
member: cn=Adam Williams,ou=People,ou=Entities,ou=SAM,dc=rss,dc=nw
....

Instead of using "memberuid: awilliam" to contain the username in the
group, it uses the DN of the entity that is a member of the group.  

You also get the advantage that current NSSs use a local db to cache
group membership with using BIS, which is a performance boost since
glibc's stupid getpwent and related calls always enumerate ALL members
of a group whenever a group or group membership is enquired.

> I understand what it is complaing about (structural vs auxiliary) but
> don't know what the group object entry should look like and was assuming
> the migration script would make an entry that would work.  

Yea, I know. Unfortunately PADL's script are a bit out of date;  but
they are still the best/only publically available start point.

> include   /etc/openldap/schema/core.schema
> include   /etc/openldap/schema/cosine.schema
> include   /etc/openldap/schema/inetorgperson.schema
> include   /etc/openldap/schema/rfc2307bis.schema

Note the "bis" in rfc2307bis

> include   /etc/openldap/schema/yast.schema