1. Current Authentication Scheme
1.1. Name Switch Server
Groups and users (passwd) come first from afs and then from files. This requires special trickery to ensure openafs starts before even the firewall.
We chose libnss-afs because there isn't really any point being able to query networked user and group information if openafs is not working since anything needing that info is going to rely on openafs anyway. Which is to say basically everything.
1.2. PAM
Using the standard Debian squeeze pam config framework, we have pam_krb5 and pam_afs_session enabled to permit Kerberos users to login. On admin nodes, login.restrict is used to only allow admins access.
2. Open Questions
Using libnss-afs is not without its disadvantages. We may want to use ldap again as the user directory for various reasons.
2.1. LDAP
Pros:
- Not dependent upon AFS running permitting networked user and group information to be found before the openafs client starts.
- Designed for such tasks and highly configurable
Other people maintain libnss-ldap
No need to start a large service during the rcS phase of booting just to have networked users available
Cons:
- We have to keep LDAP and the pts database synchronized
uid and gids
- home directory
- shell
- Yet another service to keep running (and a fairly complicated one at that)
- No clear advantage over using the afs pts db for our purposes
2.2. AFS PTS Server
Pros:
- No need to ensure the pts server information is in sync with another database
- Provides semi-readable names to AFS PAGs when queried from the group name
- DTRT with home directories and shell configuration (at least within our setup)
- We have a known good configuration
Cons:
- No networked user information is available until the openafs client starts
- If communication with the afs server is lost user and group info becomes unavailable
- We may need to keep LDAP around anyway for storing information such as the user real name
We effectively have to maintain libnss-afs (which may not be such a burden--the afs and nss interfaces are stable)
3. Old Authentication Scheme
This is how things are done on deleuze, mire, and hopper (hopper at least should be changed).
Regarding the exact authentication mechanism on HCoop. Each machine is unconditionally configured in one of the modes:
- No user logins are allowed
- User logins allowed, go through Kerberos and AFS
- User logins allowed, go through local Unix authentication, on local disk
All login configuration is done through PAM (/etc/pam.d/* files).
If /etc/login.restrict file is present, it automatically limits logins only to accounts listed in the file.
Speaking of Kerberos login, it's useful to mention/remind ourselves of the ~/.k5login feature (see manpage). We don't rely on this anywhere, but as said, useful to know about.