[OpenAFS] AFS, Kerberos, NSS, etc. on Debian (was: Debian - openafs -noauth problems)

[Madhusudan Singh]

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
> /etc/nsswitch.conf).
>
> 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.

Good point.

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).