Using Kerberos Tickets

Intended for: Kerberos users

Scenario/Use case:

This article provides instructions on how to use Kerberos tickets, including:

• Obtaining tickets (Authentication to Kerberos)
• Viewing tickets
• Destroying tickets
• Forwarding tickets
• Renewing tickets
• Updating tickets on remote terminal sessions

Instructions:

Ticket Properties and Options

Kerberos uses encrypted records called tickets to authenticate to Kerberized services (the terms tickets and credentials are used interchangeably). Tickets reside in a file called a ticket cache or credentials cache. Generally the only ticket you need to know about is the ticket-granting-ticket (TGT), which you obtain upon authentication to Kerberos. Kerberos tickets can be forwardable, renewable, post-dated and/or proxiable. The Kerberized versions of network programs generally provide options to exploit these features (see Network Programs Available on Kerberized Machines).

Forwardable

A forwardable ticket can be "passed on" to a remote host, thereby allowing the user to connect to the host without further authentication. Generally only the TGT is set forwardable, since it can be used to obtain other needed tickets.

Renewable

A renewable ticket can have its lifetime extended, by action of the user, beyond the initial lifetime, up to an established limit (seven days at Fermilab).

Post-dated

A post-dated ticket becomes valid at a specified time in the future.

Proxiable

A proxiable ticket is like a forwardable ticket, except that the new ticket with the new address list is not allowed to be a TGT, it must be for some other service.

Default Ticket Flags and Lifetimes

At Fermilab, the maximum ticket lifetime is set to 26 hours, and the default ticket lifetime as set on individual systems is constrained to be this value or less. The default flags and lifetimes of tickets obtained on a UNIX machine by login and kinit are set by entries in that machine's /etc/krb5.conf. (For other operating systems, the default values may be set via a more user-friendly interface.) The maximum renewable ticket lifetime is seven days. We discuss the krb5.conf file in The Kerberos Configuration File: krb5.conf.

Credential Caches

A credential cache is usually a file containing your tickets and session keys (on some systems the cache is in memory or some other structured storage). Each window on your desktop that is running a remote session has a separate credential cache (in some cases, there may be more than one per window), with a separate expiration. The variable $KRB5CCNAME points to the credential cache in use on each host. Tickets generated by kinit end up in /tmp/krb5cc_[UID] or in /tmp/krb5cc_[UID]_XXXXXX.

Tickets for Root Instance of Kerberos Principal

The system administrator of a strengthened machine may require that authorized users obtain a <username>/root instance of their Kerberos principal in order to access the root account (and/or other sensitive accounts) on the machine. This is described in section What is a Root Instance of a Principal? The /root instance has the properties of disallowing forwardable tickets and having a shorter default ticket lifetime.

Ticket Management

Obtaining Tickets (Authenticating to Kerberos)

The way to authenticate depends on your operating system and software. Upon authentication you get a Kerberos ticket-granting-ticket (TGT). As you access Kerberized services in the strengthened realm, the tickets needed for the services are granted automatically. As regular practice, authenticate locally and forward tickets to remote machines.

To authenticate:

When you're logging in as root you have to make sure you have tickets as some principal known to the KDC in order to access Kerberos network services. Whether you logged in as yourself and ran ksu to root, or logged in as <yourprincipal>/root over the network, you have credentials for the principal under which you previously authenticated.

If you have a laptop that you move from one network to another, then you will have to re-obtain your credentials when you move to a new network because the IP address changes. Similarly, if you use DHCP, every time your IP address changes you need to get new credentials.

Viewing Tickets

The way to view your tickets depends on your operating system and software. Valid and expired tickets alike will be displayed.

To view tickets:

About the klist Command

The command klist displays your tickets (the -f option displays the flags set for the tickets), e.g.,:

% klist -f

This produces output of the form:

Ticket cache: /tmp/krb5cc_6302
Default principal: aheavey@FNAL.GOV

Valid starting     Expires            Service principal
12/08/99 11:29:47  12/09/99 00:29:47  
krbtgt/FNAL.GOV@FNAL.GOV
        Flags: FIA

• The listed ticket is a Kerberos TGT (krbtgt) for the service principal krbtgt/FNAL.GOV@FNAL.GOV. See principal in the Kerberos Glossary for an explanation of the syntax. Underneath it the flags are listed. This ticket has flags set for "forwardable", "initial", and "preauthenticated".

If you have no tickets you will see output like this:

klist: No credentials cache file found (ticket cache /tmp/krb5cc_6302)

Several options are available for klist, as listed in section klist and in the man pages.

Destroying Tickets

Tickets can outlive an interactive session and they can be stolen. They are just encrypted records in a file. Therefore it's a good idea to explicitly destroy your tickets when you log out. Similarly, if you are going to be away from your machine but don't want to log out, it is safest to either destroy your tickets, or use a screensaver that locks the keyboard.

To destroy tickets:

Destroying Tickets Selectively

If you have several tickets in your cache and you run kdestroy, you'll destroy them all. But say you want to destroy only one or some of them. If your TGT is renewable, running kinit -R will discard all but the TGT, which gets renewed. If your tickets are forwardable, you can forward the TGT alone to your own machine by rsh or other program, and then overwrite your existing cache, e.g.,:

% rsh -F `hostname` cp \$KRB5CCNAME $KRB5CCNAME
 

(Backquotes around hostname) If the KRB5CCNAME value has FILE: on the front of it (true of the recent kerberos releases), the preceding command will fail; in this case, try:

% rsh -F `hostname` cp '`echo $KRB5CCNAME | sed -e sxFILE:xx`' `echo $KRB5CCNAME | sed -e sxFILE:xx`
 

(All the quotes are backquotes.) To do anything more specific you'd have to write a program with the credentials cache API (which is beyond the scope of this document).

Forwarding Tickets

You can use your current, valid credentials on your desktop to get valid credentials on another machine by forwarding them (the KDC administrator has the option of disallowing forwardable tickets on a per-site or per-principal basis). You should forward tickets if you plan to use Kerberized services on the remote host (e.g., if you plan to connect from there to another remote Kerberized machine). To forward tickets, there are two steps:

1. you must first obtain a forwardable ticket,
2. and then make sure the "forward" option is used by your connection program.

The way to do this of course depends on your OS and software:

Descriptions of the forwarding option (and other Kerberos functions) added to the connection programs in the Kerberos V5 package can be found in Network Programs Available on Kerberized Machines or at http://web.mit.edu/kerberos/www/krb5-1.2/krb5-1.2.6/doc/user-guide.html#SEC15 (documentation for an older MIT Kerberos version).

Tickets and IP Addresses: How forwarding works

The IP address (or list of IP addresses) of the client is encoded inside of every Kerberos ticket. This information is used by application servers and the KDC to verify the address of the client. By default, then, a ticket that was acquired on one host cannot be used on another. This is where forwarding comes in. A forwardable ticket (usually a TGT) can be used to request a new ticket, but with a different IP address.

The new IP addresses to be included in a forwarded ticket are determined from the DNS entry for the target hostname. If that host turns out to have other IP addresses which are not listed under that name, the forwarded ticket may or may not be usable, depending on how that host routes packets to the KDC or to the other nodes you try to access.

A Word about Ticket Caches and Forwarding

Forwarding actually involves asking the KDC to rewrite the ticket to be valid from the remote machine instead of from your desktop. In the case of ssh, the sshd process on the remote host receives the forwarded ticket, creates a credential cache file in /tmp and puts its name into the variable $KRB5CCNAME. The shell spawned by sshd inherits this variable, so any Kerberos client programs you run in that shell will use the forwarded ticket in that cache. If you then start an xterm process, it and the shell (or other process) it spawns inherit this environment variable and therefore know where to find your ticket. When the shell process created by sshd exits, sshd destroys the credential cache it created -- unless the host's sshd configuration says otherwise. As a user, you have no control over that setting.

Example (UNIX)

You will automatically obtain a forwardable ticket if under [appdefaults] in /etc/krb5.conf you see forward=true set for kinit or login, depending on how you got your ticket. You can always run klist -f and look for the F flag in the output if you're not sure:

If you need to replace your ticket with a forwardable one, run kinit -f.

Now, to forward this ticket to a remote host via telnet, first check under [appdefaults] in /etc/krb5.conf to see if forward=true is set for telnet. If so, just run telnet <host>. If not, run telnet -f <host> or telnet -F <host>. With -f, the forwarded ticket on the remote host is not set as reforwardable, and thus you can't forward it from that host to another. With -F, the forwarded ticket is marked as reforwardable from that host.

Renewing Tickets

In order to support both long interactive sessions and batch jobs, tickets can be issued as renewable (if the /etc/krb5.conf file on the machine sets renewable=true and default_lifetime=<value greater than 26 hours>, the user will get a renewable ticket by default when they first log in), and given a renewable lifetime. This lifetime must be less than or equal to the maximum allowable renewable lifetime, which is set to seven days at Fermilab. A renewable ticket still has the normal lifespan (up to 26 hours), but before it expires it can be renewed as long as its renewable life has not expired. Once the ticket expires, new connections cannot be opened, but existing connections are not terminated. 

Make sure you read about k5push in section Update Tickets on Remote Terminal Sessions, which renews tickets on multiple remote sessions simultaneously. For a local session, how you go about requesting a renewable ticket and renewing it depend upon your OS and software:

Example

Request a renewable ticket with a maximum renewable lifetime of four days using the -r option:

% kinit -r 4d
Password for aheavey@FNAL.GOV:  <--- type your password here. 

Then, before the default lifetime of 26 hours has passed (you cannot renew an expired ticket), and before four days expire, renew the ticket using the -R option:

% kinit -R

The ticket will remain active an additional 26 hours or until its original four day term expires, whichever comes first.

Update Tickets on Remote Terminal Sessions

What do you do when you have connections open to remote machines, and your tickets on these machines expire? Well, you most certainly don't want to run kinit over the network (beware of unencrypted connections). And it turns out you don't have to exit and restart each session, either:

• You can push your valid tickets from your local machine to these remote machines via a script called k5push.

k5push

Authenticate to Kerberos locally first before using k5push. The k5push script connects to an open session on a remote UNIX system using Kerberized rsh, and updates the remote ticket cache file in /tmp with the new tickets from your desktop machine. k5push does not create a ticket cache; one must already exist on the remote node. To run the script, type this command at your local session prompt:

% k5push <host1> [ <host2> <host3>...]

The script makes quite a few checks to make sure that the ticket file is really one of yours, and belongs to a running session. The k5push script is included in the Fermi
Kerberos RPM package krb5-fermi-base and is installed as /usr/krb5/bin/k5push.

It is also available from http://metrics.fnal.gov/authentication/downloads/k5push_script.txt.

k5push options

1. You can run this to an account with a different name:

% k5push <username>@<host> [ [<username>@]<host2> ...]

but be aware that if the target account is a shared account, you might update other users' ticket files with your tickets.

2. You can keep a list of systems to update in a text file, and run:

% k5push -f <file>

to update them simultaneously. (From UNIX, this file must be local; from Windows, this file must be on the UNIX host to which you connect.) The text file must list hosts and/or accounts on hosts each on a separate line, e.g.,:

<host>.fnal.gov
<host>.<domain>
<account>@<host>.<domain>

See Also:

• Strong Authentication at Fermilab
• Kerberos account access by multiple users
• Using root instance of your Kerberos principal