This site requires JavaScript to be enabled

161 views

2.0 - Updated on 2021-02-23 by Carlos Salazar

1.0 - Authored on 2014-05-08 by Fang Wang

Using Kerberos Tickets

 

Intended for:

Kerberos users.

 


Scenario/Use case:

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

 


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 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:

 

UNIX desktop with Kerberos software and Kerberos login

Log in, and provide your Kerberos password. See section Logging In at the Console of a Kerberized UNIX Machine.

UNIX desktop with Kerberos and standard UNIX login program

Log in with your UNIX password, then run kinit. See section Logging In at the Console of a Kerberized UNIX Machine. Also see kinit.
Windows desktop with Kerberos for Windows Open the Ticket Manager window and select Get a Ticket. Enter the principal and password. See  KB011316 for more.

Macintosh desktop with Kerberos

For OS X, see section Authenticate to Kerberos.  Run kinit as under UNIX.

Remote UNIX host (from desktop with no Kerberos software installed)

Start an ssh (or telnet or FTP) session to a Kerberized host, use your RSA SecureID Token to generate a password, and log into the remote host using that one-time password. See section Connecting from a Non-Kerberized Machine: Portal Mode.


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:

 

UNIX desktop with Kerberos software

Run the klist command (-f option recommended to show ticket flags). See section klist.
Windows desktop with Kerberos forWindows Open the Ticket Manager window. Valid tickets will be displayed. Double click on the principal name for more details.

Macintosh desktop with Kerberos

For OS X, use the Unix method.

Remote Kerberized UNIX host

Run the klist command (-f option recommended to show ticket flags). See section klist.


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

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:

 

UNIX desktop with Kerberos software

Run the kdestroy command. This destroys all the tickets in the cache to which $KRB5CCNAME points. To automate this, add the command kdestroy to your .logout file. See section kdestroy or the man pages for a description of kdestroy.

If you're sharing a credentials cache among several login sessions (by setting the $KRB5CCNAME variable), issuing the kdestroy command on any of the sessions destroys the tickets for all of them.
Windows desktop with Kerberos for Windows
Open the Ticket Manager window. Select the credential that you want to destroy and click Destroy.

Macintosh desktop with Kerberos

For OS X, use the Unix method.

Remote Kerberized UNIX host

Run the kdestroy command.


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. Make sure the "forward" option is used by your connection program.

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

 

UNIX desktop with Kerberos software and Kerberos login

To obtain a forwardable ticket, the /etc/krb5.conf must show forwardable = true for login) under [appdefaults]). If not, check for forwardable = true for kinit. If this is true, run kinit. If false, run kinit -f.

To forward your forwardable ticket to a remote UNIX host, use a Kerberized connection program with ticket forwarding on (e.g., telnet -F).

UNIX desktop with Kerberos and standard UNIX login program

To obtain a forwardable ticket, check for forwardable = true for kinit in /etc/krb5.conf. If true, run kinit. If false, run kinit -f.

To forward your forwardable ticket to a remote UNIX host, use a Kerberized connection program with ticket forwarding on (e.g., telnet -F). (See footnote a.)
Windows desktop with Kerberos for Windows Open the Ticket Manager windows. When you are authenticating to get your ticket ensure that Forwardable and Proxiable is selected.

Windows desktop with Kerberos for Windows and PuTTY

Open the Ticket Manager windows. When you are authenticating to get your ticket ensure that Forwardable and Proxiable is selected.

See section Configuring the PuTTY Application. Then run the PuTTY client.

Macintosh desktop with Kerberos

For OS X, use the Unix method.

 

Check for forward = true in [appdefaults] section of /etc/krb5.conf for your program of choice (ssh has its own configuration). If false, use the program's command line option for ticket forwarding; hese are documented in Network Programs Available on Kerberized Machines.

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:

12/08/99 11:29:47 12/09/99 00:29:47 krbtgt/FNAL.GOV@FNAL.GOV
Flags: FIA

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

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 depends upon your OS and software:

 

UNIX desktop with Kerberos software

To request a renewable ticket, use kinit -r <renewable_lifetime>. This requires password entry, therefore it must only be performed at the keyboard of a strengthened machine or (infrequently) over an encrypted connection.

To renew the ticket, use kinit -R before the ticket expires. kinit -R does not require password entry.
Windows desktop with Kerberos for Windows
Open the Ticket Manager windows. Select the credential that you want to renew and click Renew Ticket.

Macintosh desktop with Kerberos

 For OS X, use the Unix method.

Remote Kerberized host via Portal Mode

 


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:

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: