Text-only	Table of Contents (frame/ no frame)
(5) AFS authentication

AFS Authentication

The action of authenticating to a particular computer, and authenticating to AFS, are usually combined so that only one username and password are required. This requires that AFS usernames are used as the local usernames. No local password is used. In most cases enabling an AFS account on a client computer requires only creating a record in /etc/passwd, so account maintenance is greatly simplified. Once the user has been identified by the AFS system they are then allowed to use the computer and access the files in their home directory.

The main difference between an AFS user and a local user is that the AFS user is not tied or attached to a particular computer but instead has a global identity that allows the user to authenticate to multiple computers.

Computers can also use AFS without integrating the login procedure. In this case a local login is performed as usual and then the user runs klog -setpag to authenticate to AFS.

The -setpag option is used to generate a new PAG at the same time as authenticating. The pagsh command can also be used for this. Without a PAG, the token is attached to the local Unix UID of the user, which opens a security hole since local root processes could 'su' to the user and inherit the AFS token.
AFS token generation can also be integrated with other kerberos-based authentication schemes (e.g. the DND), but this is not currently used at Dartmouth.

AFS tokens

An important component of the authentication process is the granting of a token that is associated with the current process group (or login session). Tokens can be thought of as temporary identity cards that can be used to assure that a user's process does indeed have the correct permissions to access particular files. Tokens are based on Kerberos and have a finite lifetime (default 25 hours in the Northstar cell). The lifetime can be adjusted (per user), up to 30 days, but not eliminated completely. It is a design decision to increase system security. When a token expires, the user is still logged in and can run programs, but loses access priviledges (becomes a guest user in effect), so file read/write actions may fail.

The klog command can be used to renew a token at any time. The token applies to all programs in the same Process Authentication Group (PAG). With integrated logins, the PAG is a login session. The effect of this is that you may have multiple programs and shell windows associated with the same token, and refreshing the token in any one of them affects all the others.

The command tokens can be used to check the status and expiration times of your tokens. Only one token can be held at a time for a given cell in a given PAG. This is a consequence of the kerberos system and if it were not true, there would be ambiguity in the access control. However, if a user has an account in multiple cells, a separate token for each cell can be held.
Example: klog -cell thayer.dartmouth.edu
Separate PAGs can be started from a single login session to allow programs to run authenticated as different users, but typically this facility is only needed by administrators.

Discarding tokens

The command unlog explicitly discards one or more tokens. It is usually performed automatically when logging out, for added security.

AFS home directories

The major difference between an AFS home directory and local home directories is that an AFS home directory is shared between multiple computers. The user account is detached from the computer, making it much easier to retire old computers and bring new ones online. A complicating factor is that the shared home directory may be used for different operating systems (Linux, Solaris, Irix etc.) and so common configuration files like .cshrc and .login must be carefully crafted to produce the correct results on all operating systems in use.

Local (unauthenticated) processes on a computer cannot typically read or write files in a home directory. This is a problem for certain software such as mail delivery (forwarding, vacation messages, procmail) and cron jobs. Workarounds are usually possible. For example, if all mail delivery is performed only by a trusted computer (used for no other purpose), then that computer can be given special access.

Long running jobs

If your jobs might run for more then 24 hours contact the system manager to request a longer default token lifetime.
Run klog to refresh your token before starting a long job
Keep a terminal window open in which you can periodically (daily) run the klog command to refresh your token. Users who login each day do not need to use the "klog" command as they will receive a new token at each login.
If backgrounding a process and logging out, be sure that your account does not run unlog at logout.

Changing passwords

The kpasswd command is the AFS equivalent of the system passwd command. It may be integrated with passwd for users with AFS homes. There are cell-specific options on acceptable passwords, password lifetimes, bad password lockouts etc.

authentication.src last modified Sep 12, 2005

Introduction

Table of Contents
(frame/no frame)

Printable
(single file)