Strong Authentication Presentation: Managing Tickets

Strong Auth Index Page | Presentation Outline

Managing Kerberos Tickets

Ticket Options

Once you are authenticated to Kerberos, you get issued Kerberos tickets (also called credentials). This allows you to log in remotely to other strengthened hosts without typing your password again. You can request that certain options be set on your tickets:

Forwardable: Ticket can be forwarded to other hosts

Renewable: Ticket can be renewed before it expires, in order to extend its lifetime

Post-dated: Ticket becomes valid at a specified time in the future.

Proxiable: Like forwardable, but you can't use it to obtain a new ticket. (beyond scope)

Our Kerberos implementation is integrated with AFS. This means that if your machine is part of the strengthened realm and it runs AFS, then when you log on and get Kerberos credentials, you also automatically get an AFS token.

The ticket management operations (e.g., listing, destroying tickets) run on both the Kerberos tickets and the AFS token. The lifetime of the AFS token is set to the renewable lifetime of the Kerberos ticket.

Obtaining Tickets

"Authenticate to Kerberos" is equivalent to "obtain Kerberos ticket".

With rare exceptions, always authenticate to Kerberos on your local machine, and forward your tickets to remote hosts.

To obtain tickets

If your local UNIX machine runs the Kerberos login program, you use your Kerberos password to log in and you get tickets automatically.

If your local UNIX machine runs the standard UNIX login program, you use your UNIX password to log in, then run kinit (Kerberos password entry required).

Note that this is not a double-use of your Kerberos password. It is being used to authenticate you to Kerberos in both cases. In the first case, the login program is performing the equivalent of kinit for you.

Whenever you're about to run kinit, first verify that you're using the host's directly-connected keyboard! Only on rare, necessary occasions may you run this command over a network connection. When you do, verify that all connections in the chain are encrypted!
% kinit 
Password for username@FNAL.GOV:   <--- type your password here. 
Examples of kinit

No options: Request a 26-hour ticket with the flags FIA set by default (Forwardable, Initial, Preauthenticated:
% kinit 
-f option: Request a forwardable ticket
% kinit -f
-F option: Request a nonforwardable ticket
% kinit -F 
principal argument: Request ticket for specified principal.
% kinit my_principal_name@FNAL.GOV
-l option: Request a ticket with specified lifetime (less than 26 hrs), e.g., three hours
% kinit -l 3h 
Listing Tickets
% klist -f 
With -f , this produces output of the following form, which includes the ticket flags:
Ticket cache: /tmp/krb5cc_6302 
Default principal: aheavey@FNAL.GOV 
 
Valid starting     Expires            Service principal 
09/08/01 11:29:47  09/09/01 00:29:47  krbtgt/FNAL.GOV@FNAL.GOV 
        Flags: FIA 
09/08/01 11:29:48  09/09/01 00:29:47  afs/fnal.gov@FNAL.GOV 
        Flags: FA 
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 12.2 klist and in the man pages.

Destroying Tickets

Tickets can outlive an interactive session and they can be stolen. The command kdestroy destroys all your tickets. To automate this, add the command kdestroy to your .logout file.

Also, if you are going to be away from your machine and are concerned about an intruder using your permissions, it is safest to either destroy your tickets, or use a screensaver that locks the keyboard.

Forwarding Tickets

You can use your current ticket to get a valid ticket on a remote machine by forwarding your ticket. Your initial ticket must be set as forwardable.

The strengthened versions of programs such as ssh , slogin , scp , rsh , rcp , telnet , FTP and rlogin support forwarding copies of your tickets to the remote host. See Chapter 13: Network Programs Available on Kerberized Machines.

Run klist -f to verify that your ticket is forwardable (F flag)

Check /etc/krb5.conf, [appdefaults] to see if selected transport program forwards tickets by default (forward=true)

If not, include flag for forwarding in connection command, e.g., for telnet:

telnet -f: Forward ticket, but do not make it reforwardable from remote host

telnet -F: Forward ticket, and make it reforwardable from remote host

See Chapter 13: Network Programs Available on Kerberized Machines for command syntax.

Renewing Tickets

Tickets can be given a renewable lifetime less than or equal to the maximum allowable renewable lifetime (seven days). 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.

Request a Renewable Ticket

Run % kinit -r <renewable-life> to request a renewable ticket. This requires password entry.

Renew a Ticket

Run % kinit -R before the ticket expires. (No password entry.) This keeps ticket active for another 26 hours.

Example

Example: % kinit -r 4d requests ticket with renewable life of 4 days.

Before 26 hours has passed, run % kinit -R . Repeat every 26 hours or less until 4 day limit is reached.

The .k5login file and Group Accounts

The .k5login File

The .k5login file is a text file that may exist in an account's home directory. It contains a list of the principals who can be granted access to the account. This file overrides all other rules for granting access.

Do you need a .k5login file?

As long as the only principal to access your account is your own FNAL.GOV principal, and your principal matches your login id, you don't need a .k5login file.

If other principals need access to the account, you need one. Make sure that all principals that require access are listed in it, including your FNAL.GOV principal.

Sample .k5login Files

One user who belongs to different realms:
jpedersen@FNAL.GOV
jpedersen@MYUNIV.EDU
Multi-user account:
jpedersen@FNAL.GOV
xsmith@FNAL.GOV
qjones@FNAL.GOV
About Group Accounts

Kerberos passwords cannot be shared! A multiple user account must have a .k5login file in its home directory containing an entry for each user that needs to log into the account. The account may have but does not need a corresponding principal.

AFS ACLs should be set up so that everyone in the group can read (and write, if necessary) the files with his/her own AFS login and token. (This avoids the problem of running klog with a group AFS password.)

Users log in to the multiple-user account as follows:

Authenticate to Kerberos under your own account.

Log in to the multiple-user account, by identifying it on the connection program command line, and forward the ticket, e.g., telnet -f -l <group-account-name> <host>.

Assuming tickets are automatically forwarded, you're now logged on under the account name, but your Kerberos ticket and AFS token are associated with your principal name.

Run klog to get an AFS token for the group account.

Strong Auth Index Page