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

[Russ Allbery]

Madhusudan Singh <singh.madhusudan@gmail.com> writes:

>> Correct.  You want to install libpam-krb5 and libpam-openafs-session
>> and call the former in common-auth and common-session and the latter in
>> common-session.  We can get into more detail if you want specifics on
>> order and configuration there.

> That would be nice.

I'll warn in advance that I don't actually use this configuration (we have
a weird legacy Kerberos setup), but it should at least be a starting point
for discussion.  In common-auth, use:

auth    [success=ok default=1]  pam_krb5.so
auth    [default=done]          pam_openafs_session.so
auth    required                pam_unix.so nullok_secure try_first_pass

and then in common-session:

session optional        pam_krb5.so
session optional        pam_openafs_session.so
session required        pam_unix.so

You probably also want to have in common-account:

account sufficient      pam_krb5.so
account required        pam_unix.so

so that .k5login files control whether someone can log in via Kerberos and
the standard Unix checks control whether they can log in via a local
password.  (If you want to check locally as well as in Kerberos, change
sufficient to required for pam_krb5.so.)

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

>> Right.  NSS lookups on your local system won't know about PTS and
>> therefore won't know how to map UIDs in AFS to usernames, so you'll get
>> strange results for anything that doesn't match your local passwd file
>> or other NSS source.  Most of us who have been running AFS for a while
>> have just gotten used to this and don't notice any more, but in general
>> you want to have the UIDs that AFS uses match as closely as possible
>> the UIDs that you put in your passwd file.

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

>> To see who has access to the files in a directory in AFS, including
>> groups, use fs listacl.  Those are the permissions that actually
>> matter.

> The 7 ACLs instead of the 3 unix permission bits.

Right.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>