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). _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
