|
Size: 1772
Comment: Remove incorrect last paragraph
|
Size: 4446
Comment: thoughts on updating our authentication infrastructure
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Authentication Scheme = | = New Authentication Scheme = |
| Line 3: | Line 3: |
| Regarding the exact authentication mechanism on HCoop: | == Name Switch Server == |
| Line 5: | Line 5: |
| We have Kerberos and LDAP working. Kerberos holds user "principals" (account names + passwords), while LDAP keeps account names plus everything else (such as UIDs, GIDs, home directories, real names, permissions etc.). General policy is: all users have LDAP accounts and a Kerberos principal. Admins have passwd file account and a Kerberos principal. When needed, admins can also create a pure local-files-based account. | Groups and users (`passwd`) should come from `files` and then a networked source on all machines. We can either use LDAP or user `libnss-afs` to grab this information from the AFS `ptserver`. There are advantages/disadvantages to either. |
| Line 7: | Line 7: |
| The whole authentication work is performed though a series of PAM (Pluggable Authentication Modules) configuration directives. PAM has four "management groups", listed in most-common order of execution: auth, account, session, and password. (The exact order of execution is controlled by the order of lines in /etc/pam.d/* files, with each file corresponding to a particular service). | ClintonEbadi is leaning toward `libnss-afs` after thinking about this--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. |
| Line 9: | Line 9: |
| * Auth is concerned with actual username/password verification in the database. * Account checks things like password aging etc. If the user has an LDAP account, then the Kerberos account module is invoked which checks for the list of allowed principals in ''~/.k5login''. Users with no LDAP account are just checked in the local password files. Currently, the pam_krb5 module we use does not check password aging information in Kerberos'''. Russ Allbery did a new module which will be in Debian Etch. * Session sets up session details, including limits. pam_krb5 is invoked and only succeeds if the user has a Kerberos principal. (If it has, it initializes the TGT ticket for them automatically). And then, finally, pam_unix_session is called which just logs session creation (and later session termination) to system log files. At that point, users are logged in. |
=== 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` Cons: * We have to keep LDAP and the pts database synchronized * `uid` and `gid`s * 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 === 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) == PAM == === Admin Only Nodes === Each admin should have a local user on every admin node and be listed in `/etc/login.restrict`. Using `pam_unix` authentication is fine, but it only does not permit authentication for networked users by an accident of implementation (neither LDAP nor pts store passwords and so attempting to authenticate against them will always fail). `pam_localuser` authentication '''should''' be used for the `login` and `sshd` services to ensure any future NSS configuration changes do not inadvertently grant networked users access. At least `ssh` needs to be explicitly instructed to consult `/etc/login.restrict` using `pam_listfile`. Other services may need to use `pam_krb5` (e.g. `imapd`, `ejabberd`) to actually authenticate as networked users. ==== Outstanding Issues ==== * `$USER_admin` users on each machine have different password on each machine which will quickly become a pain unless we set something up to keep them in sync === User Nodes === This is ''very'' tentative and won't apply to anything until we either acquire a replacement for `mire` or recommission `deleuze` as a user machine. `login` and `ssh` should authenticate with `pam_krb5` as `sufficient` and `pam_localuser` done afterward to permit admin users to login with a local account in case of Kerberos failure. Or should it be the other way around? The advantage to trying localuser first is that any admins would be less likely to forget their password. `pam_krb5` should also be provided as a `password` service with `pam_unix` later in the stack: if kerberos was not used to authenticate the module helpfully takes itself out of the `password` stack, and if a user does not have an entry in `passwd` failing to `pam_unix` after failing to change their kerberos password is harmless. = 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: 1. No user logins are allowed 1. User logins allowed, go through Kerberos and AFS 1. 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. ---- CategorySystemAdministration |
1. New Authentication Scheme
1.1. Name Switch Server
Groups and users (passwd) should come from files and then a networked source on all machines. We can either use LDAP or user libnss-afs to grab this information from the AFS ptserver. There are advantages/disadvantages to either.
ClintonEbadi is leaning toward libnss-afs after thinking about this--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.
1.1.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
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
1.1.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)
1.2. PAM
1.2.1. Admin Only Nodes
Each admin should have a local user on every admin node and be listed in /etc/login.restrict.
Using pam_unix authentication is fine, but it only does not permit authentication for networked users by an accident of implementation (neither LDAP nor pts store passwords and so attempting to authenticate against them will always fail). pam_localuser authentication should be used for the login and sshd services to ensure any future NSS configuration changes do not inadvertently grant networked users access. At least ssh needs to be explicitly instructed to consult /etc/login.restrict using pam_listfile.
Other services may need to use pam_krb5 (e.g. imapd, ejabberd) to actually authenticate as networked users.
1.2.1.1. Outstanding Issues
$USER_admin users on each machine have different password on each machine which will quickly become a pain unless we set something up to keep them in sync
1.2.2. User Nodes
This is very tentative and won't apply to anything until we either acquire a replacement for mire or recommission deleuze as a user machine.
login and ssh should authenticate with pam_krb5 as sufficient and pam_localuser done afterward to permit admin users to login with a local account in case of Kerberos failure. Or should it be the other way around? The advantage to trying localuser first is that any admins would be less likely to forget their password.
pam_krb5 should also be provided as a password service with pam_unix later in the stack: if kerberos was not used to authenticate the module helpfully takes itself out of the password stack, and if a user does not have an entry in passwd failing to pam_unix after failing to change their kerberos password is harmless.
2. 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.