|
Size: 2622
Comment:
|
Size: 611
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| Regarding the exact authentication mechanism on HCoop: | Regarding the exact authentication mechanism on HCoop. Each machine is unconditionally configured in one of the modes: |
| 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. | 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 |
| Line 7: | Line 9: |
| 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). | All login configuration is done through PAM (/etc/pam.d/* files). |
| Line 9: | Line 11: |
| * Auth is concerned with actual username/password verification in the database. In our setup, when users type in the password, it is verified against the Kerberos database. If three attempts are unsuccessful, another prompt is displayed, allowing a user to enter Unix passwd file password. (Only administrators who create a local account would have one). Then, pam_env is invoked, which reads ''/etc/security/pam_env.conf''. That way you can initialize environment variables in the user session. * 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. Then, pam_access is invoked, which reads ''/etc/security/access.conf''. That way you can determine which users (and from where) are allowed to log in. * Session sets up session details. First pam_limits is invoked, imposing limits on users as defined in ''/etc/security/limits.conf''. Then pam_krb5 is invoked which will only succeed 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. * Password is the management group involved only in changing the password (or whatever the authentication mechanism is). Currently, by default, Kerberos password is changed. Running '''kpasswd''' will change the Kerberos password; running '''passwd''' will change the local-files password, and will only work for people with pure local accounts. |
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). |
1. Authentication Scheme
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).