[OpenAFS] Re: LDAP backend for PTS?

[Andrew Deason]

On Fri, 20 Nov 2009 13:30:59 +0100
Holger Rauch <holger.rauch@empic.de> wrote:

> > Why do you care how many berkeley DB's you have?
> 
> Because I want to store all user/group/authentication related data in
> a centralized way via OpenLDAP, so that only one Berkeley DB is
> maintained.

Yes, but the question is still "why?". Is this because you want one
place to backup? Or because you want to be able to change all user/group
information with only LDAP-aware tools? Some other reason?

> > Also you might want to support "groups within groups".
> 
> While it certainly might be useful for some case, it looks like a
> rather special case to me.

Well, if you allow supergroups in your ptservers, you're going to need
to account for this, or something is going to break.

> > 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.
> 
> The interesting question is: Why do I have to support the pt rpcs if
> all I want to do is storing and querying pt data in an LDAP schema?

I believe Marcus was saying this assuming you were implementing a new
ptserver implementation that uses LDAP as its backend storage. You
obviously do not need to implement any of them if you have _both_ the
'normal' ptservers running and also have some LDAP server running that
allows you to query ptserver data.

> > 2/ ptserver front-end, ldap backend.
> > 	almost certainly useful to cache
> 
> Any more precise hints for this?

"It's a lot of work". What I believe Marcus is hinting at is basically
rewriting a large portion of the ptserver backend. This isn't something
you want to do unless you want to invest a lot of time or money in it.

> > 3/ ptserver "as is", ldap front-end into prdb.
> > 	Openldap provides some dandy frameworks for this.
> 
> Haven't yet come accross them. Any links.

We're not OpenLDAP developers :) (At least, I'm not). I don't have
information on the plugin APIs, but I would imagine something like this
would not be a difficult plugin to create.

> > 4/ use "pag" in kerberos ticket.  Like DCE and MS.
> 
> What's "pag"? Haven't heard about this one as of yet.

I think Marcus is referring to the MS (and DCE, apparently?) practice of
storing a bunch of authorization data in the kerberos ticket when you
acquire your ticket, instead of getting that information from a separate
server (in this case, ptserver). This route would require modifications
to the KDC, or some way of using Microsoft's PAC data or something along
those lines.

-- 
Andrew Deason
adeason@sinenomine.net