Section by Section

The configuration files are divided into sections for the four PAM module types: auth, account, password, and session. The auth section defines two alternative authentication methods in order to determine whether the users are who they claim to be (lines 2 and 3). PAM prompts the user for a password once only, and Kerberos checks the credentials (line 2). If this step is successful, pam_krb5.so requests a TGT with a set forward-capable bit to use the ticket on a remote system.

If successful, the authentication process tags pam_krb5.so sufficient and terminates without processing any additional modules.

Second Chance

If authentication fails, PAM calls the second module, pam_unix.so, to check that the user account exists locally (line 3). If PAM fails to reach the authentication server, root can still log in. The module argument use_first_pass, means the second authentication method reuses the password entered by the user instead of prompting again. Thanks to nullok_secure, there is no need to set a password in the local password file. Although you can log in with a blank password, you can only do so on terminals listed in /etc/securetty.

After PAM has finished processing the auth type modules, it goes on to execute the next include. The common-account file again contains two modules, pam_krb5.so and pam_unix, and is responsible for handing system access.

The PAM account service checks the user's password to see if it is still valid or if user access to the system is restricted with respect to time, resource usage, or location.

If the user exists and is allowed to log in, PAM turns to the next stack of modules, which is described by the common-password file. These modules give users the ability to change their passwords. In contrast to the normal procedure on Linux, which only allows users to change their own passwords, the Kerberos module gives any user the ability to change any other user's password. However, to do so, the user needs to know the current password for the account they are changing.

Session Management

Finally, PAM calls the modules configured in common-session. The session type is responsible for all the additional authentication chores. The remaining steps can include setting variables or mounting directories. Within the scope of this PAM service, pam_krb5 fulfills a very important task: it deletes a user's tickets when the user logs off.

After completing the configuration, any PAM-capable program can use PAM to access Active Directory. For example, the GNU Display Manager (GDM) offers both local and domain user accounts as login candidates and launches the required session after authentication with the Kerberos server (Figure 5).

Figure 5: The Gnu Display Manager (GDM) displays both local and Active Directory users as login candidates.

As a final step, Active Directory users will need a home directory. If the NSS does not have any details on the directory, or if the directory does not exist, Linux will either send the user off to the root directory or it will not let the user access the system – despite successful authentication – because a desktop environment such as KDE needs to read and write to certain files that just do not exist.