Kerberos Tickets and Credentials Cache
Kerberos uses tickets
, which are issued for a specific user, for a specific service, and for a specific period of time.
Once a user has completed an initial authenteication with Kerberos, it is possible to access additional services that use Kerberos authentication without re-typing your password. This is both more convenient, and more secure, as it prevents clear-text passwords
from being transmitted over the network, where they could be read by malicious users.
- The initial ticket is a ticket granting ticket, which is used to get additional tickets as needed (without typing the password again).
- When a ticket is issued, it is encrypted using the user's encryption key, which is based on the user's password. The ticket can therefore only be used by the intended user (or another user with the password).
- After the ticket is decrypted using the user's key, it is stored in a credentials cache, which must be protected so that others can not read it. The credentials cache is stored on the local file system, using the file protection mechanisms provided by the operating system (not AFS).
- Service specific tickets are issued for telnet, ftp, and other services that use Kerberos for authentication.
- Tickets are forwardable if they can be reused by the specified service to access additional services. This is used, for example, by the Kerberos telnet program to allow you to telnet without a password to a remote host, and also have Kerberos credentials and an AFS token on the remote host.
- The ticket lifetime limits the period of vulnerability if a ticket is stolen by another user -- the shorter the lifetime, the smaller the vulnerability.
- The contents of the credentials cache may be viewed with the
klist program. Use
klist -f to see the flags for each ticket. See the klist man page for more details.
Kerberos and AFS
- The AFS file system uses Kerberos IV for authentication. The CSL has configured our systems to convert Kerberos V credentials to Kerberos IV when needed for use by AFS.
- AFS uses a token, which is an AFS-specific version of a Kerberos ticket. Without a token, you can not access any parts of the AFS file system except those with access rights for
system:anyuser in the Access Control List.
- During the login process, an AFS token is automatically generated from your Kerberos ticket.
- To see the status of your AFS token, use the
tokens program on Unix, or the Security Panel on Windows NT.
- AFS tokens are issued and tracked on the basis of a Process Authentication Group (PAG). If you need to create a new PAG, use the
pagsh program. See the man page for details.
Kerberos Authenticated Services
In addition to the initial login and AFS, serveral CSL services use Kerberos authentication:
telnet between any CSL computers can use Kerberos for both authentication and creating a secure (encrypted) channel so that malicious users can not read your password or data.
- On Unix systems:
ktel is the same as
telnet with the following options:
- Automatic login as the same user name (
- Forward a forwardable ticket (
- To login to another CSL computer, use
ktel <remote-hostname>. You will not be prompted for a password. To add encryption, use the
- To login to another CSL computer as a different user, use
ktel -x -l <username remote-hostname>. You will be prompted for the password for <username>. Your session will be encrypted, so the password will not be sent over the network as clear-text.
- On Windows NT systems: The telnet program installed in the Start | Accessories menu uses Kerberos. You can select encryption and/or the user name to connect as in the dialog box.
- SSH (Secure Shell) between CSL Unix cimputers will by default forward any forwardable Kerberos tickets for authentication. You will not be prompted for a password. If you specify a username, then a Kerberos ticket will not be forwarded, and you will be prompted for a password.
- Web services on https://www-auth.cs.wisc.edu use Kerberos authentication. All traffic to this site uses SSL for session-level encryption, so your username and password are not send on the network as clear-text. This is the only site for which it is safe to use your regular CSL username and password.
Running Unattended Processes with Kerberos and AFS Authentication
On Unix Systems
Unattended processes (such as cron jobs or programs run from a .forward file) will by default not have Kerberos credentials or an AFS token. Therefore they will not have access to the file system or any other services that use Kerberos for authentication.
In order to solve this problem, the CSL has created a pair of programs:
stashticket saves ("stashes") a copy of your current credentials cache in a well-known location for later use. It is protected by the Unix filesystem permission system.
- If the stashed credentials expire, they will not be valid.
runauth uses the "stashed" credentials to generate an AFS token for use by the program being run.
to automatically filter your mail when it is received:
- Arrange for stashticket to be run regularly on the workstation where your mail is delivered. This can be done by adding code such as the following to your
if [ -x /s/std/bin/stashticket && "$HOSTNAME" == "<mailhost>" ] ; do
if (( -x /s/std/bin/stashticket ) && ( "$HOSTNAME" == "<mailhost>" )) then
- Substitute the fully qualified hostname of the computer where your mail is delivered for <mailhost>
- You can not use this method on the CSL IMAP or POP servers.
- CSL syntax is very picky: the if..then statement must all be on one line, or "continued" with the backslash as shown above.
- Put the following in your ~/public/.forward:
"| /s/std/bin/runauth -a /usr/bin/procmail #username"
- Warning: Make sure to put your username, not "username"
To run a program from cron:
- Arrange for stashticket to be run regularly on the workstation where the cron job is to be run. This can be done by adding code such as the following to your
if [ -x /s/std/bin/stashticket && "$HOSTNAME" == "<cronhost>" ] ; do
if (( -x /s/std/bin/stashticket ) &&
( "$HOSTNAME" == "<cronhost>" )) then
- Note: Substitute the fully qualified hostname of the computer where the cron job is to run for <cronhost>
- Add the following to the crontab as the command to run:
- Note: Substitute the program you want to run for <program-name>. Please see the runauth man page for details.
On Windows 95/98/ME/NT/2000 Systems:
Under Windows, it is also possible to run scheduled jobs with AFS authentication, using a similar method to what was described in the Unix section above. There are many caveats, which are listed after the instructions.
- Login to the Windows workstation, and use the Ctr-Alt-Del "Reauthenticate" button to get a token with the desired lifetime. It will need to be valid when the scheduled jobs will run.
- From the command prompt, run
stashticket, which copies your credentials to a location on the local disk only accessible by the current user.
- Create a script (or an executable) that performs the tasks that you want to schedule. Place this somewhere on the local disk, or in AFS where a token is not needed to access and run it.
- Create a script to run your job with
t:\cs\s\std\bin\runauth.exe. Do not use any AFS drive letters other than T:\, which maps to the AFS root. Use full path names.
- Schedule a job, using the Control Panel "Scheduled Jobs" item. Browse to find the script that calls
- Always use t:\ to refer to AFS paths. For instance, the home directory of user "frida" would be found under t:\cs\u\f\r\frida
- A user can only have a single active token on a given workstation at one time. Therefore, if the scheduled job starts while the user is logged in, the stashed token will supersede the token that the user got at login time. Also, if the user logs out while the scheduled job is running, the token will be removed and the scheduled job will lose the token.