Strong Authentication at Fermilab |
|||||||||||
Chapter 9: Using Kerberos
|
|||||||||||
Chapter 9: Using Kerberos
This chapter provides the information you need in order to manage your Kerberos tickets and work in a Kerberized environment. In particular, we cover ticket options and management, account access files and /root principal tickets. The Kerberos commands and features of Kerberized network programs are documented in Chapter 12: Kerberos Command Descriptions and Chapter 13: Network Programs Available on Kerberized Machines, respectively.
9.1 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 Chapter 13: 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.
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 obtain Kerberos credentials (or forward them to an AFS system), you also automatically get an AFS token. The other operations described in this chapter (e.g., listing, destroying tickets) also 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 TGT.1 (Note that if you're editing a file when the AFS token expires, it will suddenly become write-protected!)
9.1.1 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 are typically set via a more user-friendly interface.) The maximum renewable ticket lifetime is seven days. We discuss the krb5.conf file in Chapter 16: The Kerberos Configuration File: krb5.conf.
9.1.2 Credential Caches
A credential cache is a file containing your tickets and session keys. Each window on your desktop that is running a remote session has a separate credential cache2, with a separate expiration. The variable $KRB5CCNAME points to the credential cache in use on each host.3 Note that forwarded tickets and tickets obtained via kinit are stored in different caches.
9.1.3 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 9.4.1 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.
9.2 Ticket Management
9.2.1 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.
As of Kerberos v1_5, the kinit program is equipped with a warning that appears if the userid issuing the command doesn't own the console device. It is designed to help users avoid typing their password inadvertently over then network.
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.
9.2.2 Viewing Tickets
The way to view your tickets depends on your operating system and software. Valid and expired tickets alike will be displayed.
About the klist Command
The command klist displays your tickets (the -f option displays the flags set for the tickets), e.g.,:
% klist -fThis 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 12/08/99 11:29:48 12/09/99 00:29:47 afs/fnal.gov@FNAL.GOV Flags: FA
- The first listed ticket is a Kerberos TGT (krbtgt) for the service principal krbtgt/FNAL.GOV@FNAL.GOV4. Underneath it the flags are listed. This ticket has flags set for "forwardable", "initial", and "preauthenticated".
- The second listed ticket indicates that AFS is running on this machine and that an AFS token has also been granted; this is again followed by a list of the flags associated with the ticket.
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.
9.2.3 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.
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.
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).
9.2.4 Forwarding Tickets
You can use your current, valid credentials on your desktop to get valid credentials on another machine by forwarding them.5 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) and/or if you need an AFS token. To forward tickets, there are two steps:
- you must first obtain a forwardable ticket,
- 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 Chapter 13: Network Programs Available on Kerberized Machines and at http://hoth.stsci.edu/public/krb5/user-guide.html#SEC16.
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.
Telnet, rsh and rcp and ftp work without strictly requiring that credentials be forwarded. These programs always present a service-specific credential to get access, but don't necessarily forward it to the remote system.
- For telnet, you typically want to forward your credential (and automatically obtain an AFS token as needed), in order to avoid running kinit over the network. But if you don't plan to make any further connections from the remote host, and AFS is not running, forwarding is not strictly necessary.
- For rsh you'd only need to forward if the remote process you're invoking might need to make a further network access, or access files in an AFS file system.
- For rcp and ftp only the AFS case would lead you to want to forward credentials.
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 telnet, the telnetd 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 telnetd 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 telnetd exits, telnetd destroys the credential cache it created -- unless the host's /etc/krb5.conf tells telnetd "retain_ccache = true". 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.
9.2.5 Renewing Tickets
In order to support both long interactive sessions and batch jobs, tickets can be issued as renewable6, 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. The lifetime of the AFS token that you get is equal to the Kerberos ticket's renewable lifetime.
Make sure you read about k5push in section 9.2.6 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 4dPassword 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 -RThe ticket will remain active an additional 26 hours or until its original four day term expires, whichever comes first.
9.2.6 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 run kinit over the network! 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.
- From Windows (using WRQ® Reflection) you need to connect to a remote UNIX host first and run k5push from there, as we'll show you.
- For a session authenticated using a CRYPTOCard, use new-portal-ticket, as described in section 5.7 Reauthenticate using your CRYPTOCard.
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 product as of v1_5. It is also available from http://www.fnal.gov/docs/strongauth/misc/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>Using k5push from Windows with WRQ®
As usual, use the WRQ® Reflection Host - UNIX and Digital program to run your remote VT100 sessions. Use the WRQ® Reflection X Client Manager to run the k5push command on a remote UNIX host session. If you use the -f option with a file, the file must exist on this UNIX host.
To update tickets on a single remote session:
- verify that the k5push program exists on the remote UNIX host, and find its path (usually /usr/krb5/bin)
- invoke the WRQ® Reflection X Client Manager, if it's not already running
- on the right half of the X Client Manager window (as displayed in the default "Split Window Vertically" view), do the following:
- Still on the X Client Manager window, click Advanced...
- On Advanced Client Connection Settings, make sure the prompt symbol you need is shown; also check Never close client starter connection (and if shown, check Host Response).
- Click Configure Kerberos.
- On Security Properties, verify that Reflection Kerberos, Mutual authencation, and Forward ticket are checked. Verify that principal, realm and User ID are correct. Click OK.
- Back on Advanced Client Connection Settings, click OK.
- Back on the X Client Manager window, if necessary, open Connection > Host Response to monitor the process. Click Connect.
In the Host Response window, you should see a session open to the remote host and see that it runs the k5push command as you entered it:
If you have multiple remote sessions and want to update credentials on all of them simultaneously:
- first choose one of your remote VT100 sessions as the "primary"
- on the primary host, verify that the k5push program exists, and find its path (usually /usr/krb5/bin)
- create a file on the primary host with all the necessary hostnames, as described above
- invoke the WRQ® Reflection X Client Manager, if it's not already running
- fill in the right half of the X Client Manager window as described above, including the Advanced... options. Replace the command with:
9.3 Account Access by Multiple Users
Kerberos provides a way to grant account login access to multiple users, each with his/her own principal. There must be a .k5login file in the account's home directory and the principals must obtain credentials before logging into the shared account.
9.3.1 The .k5login File
The .k5login file is a text file that may exist in an account's home directory on a UNIX machine. It contains a list of the principals who have permission log into the account. Authenticated principals that are listed in the file can log in and use the account without limitations. A .k5login file is valid only on the individual strengthened host on which it resides.
Do you need a .k5login file?
As long as the only principal to log into 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 login access to the account, and/or if your login id doesn't match your principal, you need one. And it must include your own principal!
Sample .k5login
xsmith@FNAL.GOV qjones@FNAL.GOV jenniferp@FNAL.GOV jpedersen@MYUNIV.EDU9.3.2 About Group Accounts
Sharing of any Kerberos password is a violation of Fermilab policy. Therefore, 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.
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.,
- 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.
9.3.3 The .k5users File
If you want to give restricted super user access to your account to another principal (access method limited to ksu; see section 12.5 Kerberized su (ksu)), you can create a .k5users file. The .k5users file is similar to the .k5login file, except that each principal is optionally followed by a list of commands which restricts the principal to those commands, and the file is only consulted by the ksu command.
Here is a sample .k5users file:
firstuser@MYUNIV.EDU /bin/ls /usr/bin/more seconduser@MYUNIV.EDU /bin/ls jenniferp@FNAL.GOV jpedersen@MYUNIV.EDUThis restricts the first and second listed principals to the shown commands, and prohibits jenniferp@FNAL.GOV and jpedersen@MYUNIV.EDU from executing any command.
- Be aware that arbitrary flags and arguments may be given to the listed commands by the authorized ksu user.
- If you list a principal more than once in this file, only the first entry is used.
9.4 Using Root Instance of your Principal
9.4.1 What is a Root Instance of a Principal?
A Kerberos principal has three parts and is of the form primary/instance@REALM. For a user, the instance portion is generally null, and the principal is of the form primary@REALM. If the instance is not null, the instance portion gives information that qualifies the primary, and is generally used to describe the intended use of the corresponding credentials. The root instance of a principal is also called a /root principal. The word root in <username>/root@FNAL.GOV need not have anything to do with the UNIX root account, although that is presumed to be one of the most common uses. All /root principals are created with the DISALLOW_FORWARDABLE flag set so that tickets are always unforwardable. The tickets also have a shorter default lifetime.
A root instance of your principal is only useful if your system administrator wants to make use of its restrictive ticket properties to protect sensitive accounts. Typically these accounts are set up with a .k5login file containing only /root principals. Your system administrator should inform you if you need to obtain a /root principal.
9.4.2 How do You Use your /root Principal?
To connect to such an account via a network connection from your desktop, you need to first kinit on your local machine as <user>/root (we use me/root as an example) and specify "nonforwardable ticket" with the -F flag7:
% kinit -F me/root[@FNAL.GOV]Now, connect to the sensitive account on the remote host using all of the options shown here:
% telnet -x -N -l <sensitive_account_name> <remote_host>
- -x encrypts the connection (generally a good idea)
- -N tells the program not to forward tickets (you'll get an error if you fail to include this)
- -l <sensitive_account_name> logs you in directly to the named account. If you didn't include this, the remote host would try to log you into an account with the same name as your local UNIX username.
Note that once you're logged in remotely, you have no tickets. You cannot use any Kerberized services from here to connect to other accounts or machines.
9.4.3 How Should You NOT Use It?
There are some limitations associated with the use of /root principals for access to privileged accounts, and that is why their use is not mandatory.
- You can't use ksu (or other Kerberized client) on a remote machine under your /root principal because you don't have tickets on that machine.
- Never type your /root principal password over the network except on rare, necessary occasions; always authenticate on your desktop machine.
9.4.4 How do you Maintain Credentials for your Normal Principal while Using the /root Principal?
To maintain tickets on your desktop machine for both instances of your principal, you must keep the ticket caches separate. First authenticate under your normal principal, e.g.,:
% kinit [me[@FNAL.GOV]]This gets you a ticket cache in the default area. You may find it useful to pick one of your local xterm windows to use for your /root principal (maybe give it a special title bar or color) and set a separate ticket cache file there. In that window, reset the environment variable KRB5CCNAME to a location for the /root principal ticket cache, then authenticate under your /root principal to get (nonforwardable) tickets for this instance without overwriting the ones you got as "yourself":
% setenv KRB5CCNAME /tmp/krb5cc_me_root_$$ % kinit -F me/root[@FNAL.GOV]When you request a Kerberized service, Kerberos will look at the credential cache to which KRB5CCNAME points, and assume that the principal holding this cache is the requestor. Reset this variable to the other cache as necessary.
1Because AFS uses the Kerberos V4 ticket format, which squeezes the ticket lifetime into a small field, the expiration time of the AFS token may not exactly coincide with the end of the Kerberos ticket's renewable lifetime.
3Tickets generated by kinit end up in /tmp/krb5cc_[UID], forwarded tickets go to /tmp/krb5cc_p[PID], and hardware token tickets go into /tmp/krb5cc_[ttyname].
5The KDC administrator has the option of disallowing forwardable tickets on a per-site or per-principal basis.
6If 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. The Fermilab template for this file does not set renewable=true, but the system administrator can change this.
7If the Kerberos configuration file (/etc/krb5.conf) specifies forwarding "on" and you leave off the -F, you'll get an error.
|
|||||||||||
| View/print PDF file | Back to Strong Auth Index Page | Computing Division | Fermilab at Work | Fermilab Home | |||||||||||
