[OpenAFS] Re: LDAP backend for PTS?

[Marcus Watts]

Holger Rauch <holger.rauch@empic.de> wrote and
Andrew Deason <adeason@sinenomine.net> replied:
> Date:    Tue, 17 Nov 2009 10:33:36 CST
> To:      openafs-info@openafs.org
> From:    Andrew Deason <adeason@sinenomine.net>
> Subject: [OpenAFS] Re: LDAP backend for PTS?
> 
> On Tue, 17 Nov 2009 16:31:04 +0100
> Holger Rauch <holger.rauch@empic.de> wrote:
> 
> > Hi to everybody,
> > 
> > I already have an OpenLDAP server 2.4.x set up on a Debian Lenny
> > system and would like to all user, group, authentication (MIT
> > Kerberos related) info in one Berkeley DB. When using the pts
> > commands without any additional backend, a second Berkeley DB is
> > created and maintained.
> 
> The OpenAFS ptserver db? I don't think that's a berkeley db.

prdb is NOT berkeley db.

Why do you care how many berkeley DB's you have?

Are you planning to store vldb in ldap as well?

> 
> > Is there a PTS backend for OpenLDAP available and actively maintained
> > (in the sense that it can be used in conjunction with OpenAFS 1.4.x or
> > 1.5.x)?
> 
> Do you mean a way of storing ptserver data in an LDAP backend? Or a way
> to query ptserver information via LDAP queries?
> 
> I'm not aware of any stable/maintained implementations of either at the
> moment, but I'm pretty sure there's at least a patch to OpenLDAP for the
> latter floating around somewhere. When I wanted something like this, I
> just set up something to sync an LDAP subtree to match what was in the
> ptdb every so often (and triggered by a 'pts' wrapper, as well).

This has been bandied about for a while.  The basic problem is,
how to map (and represent) pt fields as ldap attributes.
So that means you have to manage

groupname	-viceid	--+
groupname #2	-viceid	-+ \ /  ...
 ...			  \ X /
			   * X
			  / X \
username #1	viceid	-+ / \ ...
username #2	viceid	--+
 ...

username is easy (uid.  or not.  cn?)
user viceid is easy (uidNumber.)
groupname is easy (cn, probably)
group viceid.  Um.  uidNumber?  Do your groups have numbers?
Then there's the intersection data.  members of groups?
Also you might want to support "groups within groups".
You should have an option to support kerberos 5 names.
You don't want to know about gssapi names.

For openafs/prdb, the important rpc you *have* to support
is GetCPS.  name goes in - list of all user and group viceids come out.
Note that an afs client may contact several servers in
rapid succession - caching results may be useful.

Unless you organize your ldap store to optimize this query, you
won't be doing this as one ldap call.  If you do optimize this
query, your ldap associates may question your sanity.

There are more pt rpcs you have to support if you want to provide read-only
query access (pts examine, members, etc.) - and even more if you want
to provide group read/write support as well.  If you don't
support group maintenance via pts, then you should provide this via ldap.

For ldap in general, and openldap in particular, you have 2 more
interesting issues:
	transactions
	referential integrity

Probably your identity management system (or strategy) has
additional constraints or properties that may matter here.
There has not been much commonality in identity management.

Some approaches

1/ sync ldap into ptserver (Andrew describes a low-tech way;
	higher tech approaches are also possible.)

2/ ptserver front-end, ldap backend.
	almost certainly useful to cache 

3/ ptserver "as is", ldap front-end into prdb.
	Openldap provides some dandy frameworks for this.

4/ use "pag" in kerberos ticket.  Like DCE and MS.

...

				-Marcus Watts