[OpenAFS] AFS, Kerberos, NSS, etc. on Debian (was: Debian - openafs -noauth problems)
Fri, 26 Aug 2005 19:54:12 -0400
Thanks for the response and the suggestions.
> > One question here :
> > My setup :
> > Realm A
> > User set b \in B (cell omega - uses A for authentication)
> > User set c \in C (a foreign cell that also uses A for authentication)
> > b is a (very small) proper subset of c.
> > I would like (this is not essential, but preferable) to allow clients to
> > do some client-side configuration (I was previously advised on this list
> > that it is possible) so as to allow them to be simultaneously
> > authenticated to B and C (their passwords are obviously identical). In
> > such a scenario, does it matter if the UIDs of members of the set b are
> > the same as their UIDs in set c ?
> Nope. The aklog magic there only cares that the Kerberos identity is the
> same in both cells.
Good. This simplifies things.
> > I do not intend to have any of the users in b (see above) in the local
> > /etc/passwd but instead have them all authenticate via MIT Kerberos 5
> > mechanism.
> It's important to realize here (and this is something that Unix guides
> often don't explain very well) that /etc/passwd serves two purposes. It
> is both an authentication mechanism (via /etc/shadow these days) *and* a
> database of UIDs, account names, shells, home directories, etc.
> The latter database is what I've been calling NSS (Name Service Switch,
> the lookup process for that information which is controlled by
> What you're saying is that you don't want these accounts to have passwords
> in /etc/shadow, which is good (use Kerberos, it's better). However, you
> still do need the NSS information if you want those users to be able to
> log in. The system needs to know their home directories, their shells,
> etc. You can provide that information either in /etc/passwd (locking the
> accounts from the local system perspective by using adduser
> --disabled-password) or by using some other supported NSS mechanism (LDAP,
> for instance). But you do need something.
One more question :
Will it be useful to have a script that creates the pts membership, group
membership, sets the ACLs, volume ownership etc. and copies files over
from /etc/skel to the volume ? I am thinking of writing one (along the lines
of the uss command suite that the Admin Guide refers to but I can't seem to
find a Debian package for).