[OpenAFS] Re: LDAP backend for PTS?
Fri, 20 Nov 2009 10:12:14 -0600
On Fri, 20 Nov 2009 13:30:59 +0100
Holger Rauch <firstname.lastname@example.org> 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
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