As noted, the Cache Manager identifies user credential structures either by UNIX UID or by PAG. Using a PAG is preferable because it guaranteed to be unique: the Cache Manager allocates it based on a counter that increments with each use. In contrast, multiple users on a machine can share or assume the same UNIX UID, which creates potential security problems. The following are two common such situations:

Yet another advantage of PAGs over UIDs is that processes spawned by the user inherit the PAG and so share the token; thus they gain access to AFS as the authenticated user. In many environments, for example, printer and other daemons run under identities (such as the local superuser root) that the AFS server processes recognize only as the anonymous user. Unless PAGs are used, such daemons cannot access files for which the system:anyuser group does not have the necessary ACL permissions.

Once a user has a PAG, any new tokens the user obtains are associated with the PAG. The PAG expires two hours after any associated tokens expire or are discarded. If the user issues the klog command before the PAG expires, the new token is associated with the existing PAG (the PAG is said to be recycled in this case).

AFS-modified login utilities automatically generate a PAG, as described in the following section. If you use a standard login utility, your users must issue the pagsh command before the klog command, or include the latter command's -setpag flag. For instructions, see Using Two-Step Login and Authentication.

Users can also use either command at any time to create a new PAG. The difference between the two commands is that the klog command replaces the PAG associated with the current command shell and tokens. The pagsh command initializes a new command shell before creating a new PAG. If the user already had a PAG, any running processes or jobs continue to use the tokens associated with the old PAG whereas any new jobs or processes use the new PAG and its associated tokens. When you exit the new shell (by pressing <Ctrl-d>, for example), you return to the original PAG and shell. By default, the pagsh command initializes a Bourne shell, but you can include the -c argument to initialize a C shell (the /bin/csh program on many system types) or Korn shell (the /bin/ksh program) instead.

As previously mentioned, an AFS-modified login utility simultaneously obtains an AFS token and logs the user into the local file system. This section outlines the login and authentication process and its interaction with the value in the password field of the local password file.

An AFS-modified login utility performs a sequence of steps similar to the following; details can vary for different operating systems:

As indicated, when you use an AFS-modified login utility, the password field in the local password file is no longer the primary gate for access to your system. If the user provides the correct AFS password, then the program never consults the local password file. However, you can still use the password field to control access, in the following way:

Systems that use a Pluggable Authentication Module (PAM) for login and AFS authentication do not necessarily consult the local password file at all, in which case they do not use the password field to control authentication and login attempts. Instead, instructions in the PAM configuration file (on many system types, /etc/pam.conf) fill the same function. See the instructions in the OpenAFS Quick Beginnings for installing AFS-modified login utilities.

In cells that do not use an AFS-modified login utility, users must issue separate commands to login and authenticate, as detailed in the OpenAFS User Guide:

As mentioned in Creating Standard Files in New AFS Accounts, you can invoke the klog -setpag command in a user's .login file (or equivalent) so that the user does not have to remember to issue the command after logging in. The user still must type a password twice, once at the prompt generated by the login utility and once at the klog command's prompt. This implies that the two passwords can differ, but it is less confusing if they do not.

Another effect of not using an AFS-modified login utility is that the AFS servers recognize the standard login program as the anonymous user. If the login program needs to access any AFS files (such as the .login file in a user's home directory), then the ACL that protects the file must include an entry granting the l (lookup) and r (read) permissions to the system:anyuser group.

When you do not use an AFS-modified login utility, an actual (scrambled) password must appear in the local password file for each user. Use the /bin/passwd file to insert or change these passwords. It is simpler if the password in the local password file matches the AFS password, but it is not required.

Once logged in, a user can obtain a token at any time with the klog command. If a valid token already exists, the new one overwrites it. If a PAG already exists, the new token is associated with it.

By default, the klog command authenticates the issuer using the identity currently logged in to the local file system. To authenticate as a different identity, use the -principal argument. To obtain a token for a foreign cell, use the -cell argument (it can be combined with the -principal argument). See the OpenAFS User Guide and the entry for the klog command in the OpenAFS Administration Reference.

To discard either all tokens or the token for a particular cell, issue the unlog command. The command affects only the tokens associated with the current command shell. See the OpenAFS User Guideand the entry for the unlog command in the OpenAFS Administration Reference.

To display the tokens associated with the current command shell, issue the tokens command. The following examples illustrate its output in various situations.

If the issuer is not authenticated in any cell:

   % tokens
   Tokens held by the Cache Manager:
          --End of list--

The following shows the output for a user with AFS UID 1000 in the Example Corporation cell:

   % tokens
   Tokens held by the Cache Manager:
   User's (AFS ID 1000) tokens for afs@example.com  [Expires Jun  2 10:00]
       --End of list--

The following shows the output for a user who is authenticated in Example Corporation cell, the Example Organization cell and the Example Network cell. The user has different AFS UIDs in the three cells. Tokens for the last cell are expired:

   % tokens
   Tokens held by the Cache Manager:
   User's (AFS ID 1000) tokens for afs@example.com  [Expires Jun  2 10:00]
   User's (AFS ID 4286) tokens for afs@example.org  [Expires Jun  3 1:34]
   User's (AFS ID 22) tokens for afs@example.net  [>>Expired<<]
       --End of list--

The Kerberos version of the tokens command (the tokens.krb command), also reports information on the ticket-granting ticket, including the ticket's owner, the ticket-granting service, and the expiration date, as in the following example. Also see Support for Kerberos Authentication.

   % tokens.krb
   Tokens held by the Cache Manager:
   User's (AFS ID 1000) tokens for afs@example.com [Expires Jun  2 10:00]
   User smith's tokens for krbtgt.EXAMPLE.COM@example.com [Expires Jun  2 10:00]
     --End of list--

The maximum lifetime of a user token is the smallest of the ticket lifetimes recorded in the following three Authentication Database entries. The kas examine command reports the lifetime as Max ticket lifetime. Administrators who have the ADMIN flag on their Authentication Database entry can use the -lifetime argument to the kas setfields command to set an entry's ticket lifetime.

Regular AFS users can change their own passwords by using either the kpasswd or kas setpassword command. The commands prompt for the current password and then twice for the new password, to screen out typing errors.

Administrators who have the ADMIN flag on their Authentication Database entries can change any user's password, either by using the kpasswd command (which requires knowing the current password) or the kas setpassword command.

If your cell does not use an AFS-modified login utility, remember also to change the local password, using the operating system's password-changing command. For more instructions on changing passwords, see Changing AFS Passwords.

You can help to make your cell more secure by imposing restrictions on user passwords and authentication attempts. To impose the restrictions as you create an account, use the A instruction in the uss template file as described in Increasing Account Security with the A Instruction. To set or change the values on an existing account, use the kas setfields command as described in Improving Password and Authentication Security.

By default, AFS passwords never expire. Limiting password lifetime can help improve security by decreasing the time the password is subject to cracking attempts. You can choose an lifetime from 1 to 254 days after the password was last changed. It automatically applies to each new password as it is set. When the user changes passwords, you can also insist that the new password is not similar to any of the 20 passwords previously used.

Unscrupulous users can try to gain access to your AFS cell by guessing an authorized user's password. To protect against this type of attack, you can limit the number of times that a user can consecutively fail to provide the correct password. When the limit is exceeded, the authentication service refuses further authentication attempts for a specified period of time (the lockout time). To reenable authentication attempts before the lockout time expires, an administrator must issue the kas unlock command.

In addition to settings on user's authentication accounts, you can improve security by automatically checking the quality of new user passwords. The kpasswd and kas setpassword commands pass the proposed password to a program or script called kpwvalid, if it exists. The kpwvalid performs quality checks and returns a code to indicate whether the password is acceptable. You can create your own program or modified the sample program included in the AFS distribution. See the kpwvalid reference page in the OpenAFS Administration Reference.

There are several types of quality checks that can improve password quality.

If your site is using standard Kerberos authentication rather than the AFS Authentication Server, use the modified versions of the klog, pagsh, and tokens commands that support Kerberos authentication. The binaries for the modified version of these commands have the same name as the standard binaries with the addition of a .krb extension.

Use either the Kerberos version or the standard command throughout the cell; do not mix the two versions. AFS Product Support can provide instructions on installing the Kerberos version of these four commands. For information on the differences between the two versions of these commands, see the OpenAFS Administration Reference.