Chapter 26 Using Kerberos Applications (Tasks)

This chapter is intended for anyone on a system with the Kerberos service configured on it. This chapter explains how to use the “Kerberized” commands and services that are provided. You should already be familiar with these commands (in their non-Kerberized versions) before you read about them here.

Because this chapter is intended for the general reader, it includes information on tickets: obtaining, viewing, and destroying them. This chapter also includes information on choosing or changing a Kerberos password.

This is a list of the information in this chapter:

• Kerberos Ticket Management

• Kerberos Password Management

• Kerberos User Commands

For an overview of the Solaris Kerberos product, see Chapter 21, Introduction to the Kerberos Service.

Kerberos Ticket Management

This section explains how to obtain, view, and destroy tickets. For an introduction to tickets, see How the Kerberos Service Works.

Do You Need to Worry About Tickets?

With any of the SEAM releases or the Solaris 10 release installed, Kerberos is built into the login command, and you will obtain tickets automatically when you log in. The Kerberized commands rsh, rcp, rdist, telnet, and rlogin are usually set up to forward copies of your tickets to the other machines, so you don't have to explicitly ask for tickets to get access to those machines. Your configuration might not include this automatic forwarding, but it is the default behavior. See Overview of Kerberized Commands and Forwarding Kerberos Tickets for more information on forwarding tickets.

For information on ticket lifetimes, see Ticket Lifetimes.

Creating a Kerberos Ticket

Normally, if PAM is configured properly, a ticket is created automatically when you log in, and you need not do anything special to obtain a ticket. However, you might need to create a ticket if your ticket expires. Also, you might need to use a different principal besides your default principal, for example, if you use rlogin -l to log in to a machine as someone else.

To create a ticket, use the kinit command.

% /usr/bin/kinit
 

The kinit command prompts you for your password. For the full syntax of the kinit command, see the kinit(1) man page.

Example 26–1 Creating a Kerberos Ticket

This example shows a user, jennifer, creating a ticket on her own system.

% kinit
Password for jennifer@ENG.EXAMPLE.COM:  <Type password>
 

Here, the user david creates a ticket that is valid for three hours with the -l option.

% kinit -l 3h david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:  <Type password>
 

This example shows the user david creating a forwardable ticket (with the -f option) for himself. With this forwardable ticket, he can, for example, log in to a second system, and then telnet to a third system.

% kinit -f david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:     <Type password>
 

For more information on how forwarding tickets works, see Forwarding Kerberos Tickets and Types of Tickets.

Viewing Kerberos Tickets

Not all tickets are alike. One ticket might, for example, be forwardable. Another ticket might be postdated. While a third ticket might be both forwardable and postdated. You can see which tickets you have, and what their attributes are, by using the klist command with the -f option:

% /usr/bin/klist -f

The following symbols indicate the attributes that are associated with each ticket, as displayed by klist:

A

Preauthenticated

D

Postdatable

d

Postdated

F

Forwardable

f

Forwarded

I

Initial

i

Invalid

P

Proxiable

p

Proxy

R

Renewable

Types of Tickets describes the various attributes that a ticket can have.

Example 26–2 Viewing Kerberos Tickets

This example shows that the user jennifer has an initial ticket, which is forwardable (F) and postdated (d), but not yet validated (i).

% /usr/bin/klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: jennifer@ENG.EXAMPLE.COM
 
Valid starting                 Expires                 Service principal
09 Mar 04 15:09:51  09 Mar 04 21:09:51  nfs/EXAMPLE.SUN.COM@EXAMPLE.SUN.COM
        renew until 10 Mar 04 15:12:51, Flags: Fdi
 

The following example shows that the user david has two tickets that were forwarded (f) to his host from another host. The tickets are also forwardable (F).

% klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: david@EXAMPLE.SUN.COM
 
Valid starting                 Expires                 Service principal
07 Mar 04 06:09:51  09 Mar 04 23:33:51  host/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 17:09:51, Flags: fF
 
Valid starting                 Expires                 Service principal
08 Mar 04 08:09:51  09 Mar 04 12:54:51  nfs/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 15:22:51, Flags: fF

The following example shows how to display the encryption types of the session key and the ticket by using the -e option. The -a option is used to map the host address to a host name if the name service can do the conversion.

% klist -fea
Ticket cache: /tmp/krb5cc_74287
Default principal: david@EXAMPLE.SUN.COM
 
Valid starting                 Expires                 Service principal
07 Mar 04 06:09:51  09 Mar 04 23:33:51  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 17:09:51, Flags: FRIA
        Etype(skey, tkt): DES cbc mode with RSA-MD5, DES cbc mode with CRC-32
        Addresses: client.example.com

Destroying Kerberos Tickets

If you want to destroy all Kerberos tickets acquired during your current session, use the kdestroy command. The command destroys you credential cache, which destroys all your credentials and tickets. While this is not usually necessary, running kdestroy reduces the chance of the credential cache being compromised during times that you are not logged in.

To destroy your tickets, use the kdestroy command.

% /usr/bin/kdestroy

The kdestroy command destroys all your tickets. You cannot use this command to selectively destroy a particular ticket.

If you are going to be away from your system and are concerned about an intruder using your permissions, you should use either kdestroy or a screen saver that locks the screen.

Kerberos Password Management

With the Kerberos service configured, you now have two passwords: your regular Solaris password and a Kerberos password. You can make both passwords the same, or they can be different.

Advice on Choosing a Password

Your password can include almost any character that you can type. The main exceptions are the Control keys and the Return key. A good password is a password that you can remember readily, but no one else can easily guess. Examples of bad passwords include the following:

• Words that can be found in a dictionary

• Any common or popular name

• The name of a famous person or character

• Your name or user name in any form (for example: your name spelled backward, repeated twice, and so forth)

• A spouse's name, child's name, or pet's name

• Your birth date or a relative's birth date

• Your social security number, driver's license number, passport number, or other similar identifying number

• Any sample password that appears in this manual or any other manual

A good password is at least eight characters long. Moreover, a password should include a mix of characters, such as uppercase and lowercase letters, numbers, and punctuation marks. Examples of passwords that would be good if they didn't appear in this manual include the following:

• Acronyms, such as “I2LMHinSF” (which is recalled as “I too left my heart in San Francisco”)

• Easy-to-pronounce nonsense words, such as “WumpaBun” or “WangDangdoodle!”

• Deliberately misspelled phrases, such as “6o'cluck” or “RrriotGrrrlsRrrule!”

Don't use these examples. Passwords that appear in manuals are the first passwords that an intruder will try.

Changing Your Password

If PAM is properly configured, you can change your Kerberos password in two ways:

• With the usual UNIX passwd command. With the Kerberos service configured, the Solaris passwd command also automatically prompts for a new Kerberos password.

  The advantage of using passwd instead of kpasswd is that you can set both UNIX and Kerberos passwords at the same time. However, you generally do not have to change both passwords with passwd. Often, you can change only your UNIX password and leave the Kerberos password untouched, or vice-versa.

  ---

  Note –

  The behavior of passwd depends on how the PAM module is configured. You might be required to change both passwords in some configurations. For some sites, the UNIX password must be changed, while other sites require the Kerberos password to change.

  ---

• With the kpasswd command. kpasswd is very similar to passwd. One difference is that kpasswd changes only Kerberos passwords. You must use passwd if you want to change your UNIX password.

  Another difference is that kpasswd can change a password for a Kerberos principal that is not a valid UNIX user. For example, david/admin is a Kerberos principal, but not an actual UNIX user, so you must use kpasswd instead of passwd.

After you change your password, it takes some time for the change to propagate through a system (especially over a large network). Depending on how your system is set up, this delay might take anywhere from a few minutes to an hour or more. If you need to get new Kerberos tickets shortly after you change your password, try the new password first. If the new password doesn't work, try again using the old password.

Kerberos V5 protocol enables system administrators to set criteria about allowable passwords for each user. Such criteria is defined by the policy set for each user (or by a default policy). See Administering Kerberos Policies for more on policies.

For example, suppose that user jennifer's policy (call it jenpol) mandates that passwords be at least eight letters long and include a mix of at least two types of characters. kpasswd will therefore reject an attempt to use “sloth” as a password.

% kpasswd
kpasswd: Changing password for jennifer@ENG.EXAMPLE.COM.
Old password:   <Jennifer types her existing password>
kpasswd: jennifer@ENG.EXAMPLE.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password: <Jennifer types  'sloth'>
New password (again):  <Jennifer re-types 'sloth'>
kpasswd: New password is too short.
Please choose a password which is at least 4 characters long.

Here, jennifer uses “slothrop49” as a password. “slothrop49” meets the criteria, because it is over eight letters long and contains two different types of characters (numbers and lowercase letters).

% kpasswd
kpasswd: Changing password for jennifer@ENG.EXAMPLE.COM.
Old password:  <Jennifer types her existing password>
kpasswd: jennifer@ENG.EXAMPLE.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password:  <Jennifer types  'slothrop49'>
New password (again):  <Jennifer re-types 'slothrop49'>
Kerberos password changed.

Example 26–3 Changing Your Password

In the following example, user david changes both his UNIX password and Kerberos password with passwd.

% passwd
	passwd:  Changing password for david
	Enter login (NIS+) password:         <Type the current UNIX password>
	New password:                        <Type the new UNIX password>
	Re-enter password:                   <Confirm the new UNIX password>
	Old KRB5 password:                   <Type the current Kerberos password>
	New KRB5 password:                   <Type the new Kerberos password>
	Re-enter new KRB5 password:          <Confirm the new Kerberos password>

Note that passwd asks for both the UNIX password and the Kerberos password. This behavior is established by the default configuration. In that case, user david must use kpasswd to set his Kerberos password to something else, as shown next.

This example shows user david changing only his Kerberos password with kpasswd.

% kpasswd
kpasswd: Changing password for david@ENG.EXAMPLE.COM.
Old password:           <Type the current Kerberos password>
New password:           <Type the new Kerberos password>
New password (again):   <Confirm the new Kerberos password>
Kerberos password changed.
 

In this example, user david changes the password for the Kerberos principal david/admin (which is not a valid UNIX user). He must use kpasswd.

% kpasswd david/admin
kpasswd:  Changing password for david/admin.
Old password:           <Type the current Kerberos password>
New password:           <Type the new Kerberos password>
New password (again):   <Type the new Kerberos password>
Kerberos password changed. 
 

Granting Access to Your Account

If you need to give someone access to log in to your account (as you), you can do so through Kerberos, without revealing your password, by putting a .k5login file in your home directory. A .k5login file is a list of one or more Kerberos principals corresponding to each person for whom you want to grant access. Each principal must be on a separate line.

Suppose that the user david keeps a .k5login file in his home directory that looks like the following:

jennifer@ENG.EXAMPLE.COM
joe@EXAMPLE.ORG  

This file allows the users jennifer and joe to assume david's identity, provided that they already have Kerberos tickets in their respective realms. For example, jennifer can remotely log in to david's machine (boston), as him, without having to give his password.

Figure 26–1 Using the .k5login File to Grant Access to Your Account

In the case where david's home directory is NFS-mounted, using Kerberos V5 protocols, from another (third) machine, jennifer must have a forwardable ticket in order to access his home directory. See Creating a Kerberos Ticket for an example of using a forwardable ticket.

If you will be logging in to other machines across a network, you'll want to include your own Kerberos principal in .k5login files on those machines.

Using a .k5login file is much safer than giving out your password for these reasons:

• You can take access away any time by removing the principal from your .k5login file.

• Although users principals named in the .k5login file in your home directory have full access to your account on that machine (or sets of machines, if the .k5login file is shared, for example, over NFS). However, any Kerberized services will authorize access based on that user's identity, not yours. So jennifer can log in to joe's machine and perform tasks there. However, if she uses a Kerberized program such as ftp or rlogin, she does so as herself.

• Kerberos keeps a log of who obtains tickets, so a system administrator can find out, if necessary, who is capable of using your user identity at a particular time.

One common way to use the .k5login file is to put it in root's home directory, giving root access for that machine to the Kerberos principals listed. This configuration allows system administrators to become root locally, or to log in remotely as root, without having to give out the root password, and without requiring anyone to type the root password over the network.

Example 26–4 Using the .k5login File to Grant Access to Your Account

Suppose jennifer decides to log in to the machine boston.example.com as root. Because she has an entry for her principal name in the .k5login file in root's home directory on boston.example.com, she again does not have to type in her password.

% rlogin boston.example.com -l root -x
This rlogin session is using DES encryption for all data transmissions.
Last login: Thu Jun 20 16:20:50 from daffodil
SunOS Release 5.7 (GENERIC) #2: Tue Nov 14 18:09:31 EST 1998
boston[root]% 

Kerberos User Commands

Kerberos V5 product is a single-sign-on system, which means that you only have to type your password once. The Kerberos V5 programs do the authenticating (and optional encrypting) for you, because Kerberos has been built into each of a suite of existing, familiar network programs. The Kerberos V5 applications are versions of existing UNIX network programs with Kerberos features added.

For example, when you use a Kerberized program to connect to a remote host, the program, the KDC, and the remote host perform a set of rapid negotiations. When these negotiations are completed, your program has proven your identity on your behalf to the remote host, and the remote host has granted you access.

Note that Kerberized commands try to authenticate with Kerberos first. If Kerberos authentication fails, an error occurs or UNIX authentication is attempted, depending on what options were used with the command. Refer to the Kerberos Security section in each Kerberos command man page for more detailed information.

Overview of Kerberized Commands

The Kerberized network services are programs that connect to another machine somewhere on the Internet. These programs are the following:

• ftp

• rcp

• rdist

• rlogin

• rsh

• ssh

• telnet

These programs have features that transparently use your Kerberos tickets for negotiating authentication and optional encryption with the remote host. In most cases, you'll notice only that you no longer have to type your password to use them, because Kerberos will provide proof of your identity for you.

The Kerberos V5 network programs include options that enable you to do the following:

• Forward your tickets to the another host (if you initially obtained forwardable tickets).

• Encrypt data transmitted between you and the remote host.

This section assumes you are already familiar with the non-Kerberos versions of these programs, and highlights the Kerberos functionality added by the Kerberos V5 package. For detailed descriptions of the commands described here, see their respective man pages.

The following Kerberos options have been added to ftp, rcp, rlogin, rsh, and telnet:

-a

Attempts automatic login using your existing tickets. Uses the username as returned by getlogin(), unless the name is different from the current user ID. See the telnet(1) man page for details.

-f

Forwards a non-reforwardable ticket to a remote host. This option is mutually exclusive with the -F option. They cannot be used together in the same command.

You'll want to forward a ticket if you have reason to believe you'll need to authenticate yourself to other Kerberos-based services on a third host. For example, you might want to remotely log in to another machine and then remotely log in from it to a third machine.

You should definitely use a forwardable ticket if your home directory on the remote host is NFS-mounted using the Kerberos V5 mechanism. Otherwise, you won't be able to access your home directory. That is, suppose you initially log in to System 1. From System 1, you remotely log in to your home machine, System 2, which mounts your home directory from System 3. Unless you've used the -f or -F option with rlogin, you won't be able to get to your home directory because your ticket can't be forwarded to System 3.

By default, kinit obtains forwardable ticket-granting tickets (TGTs). However, your configuration might differ in this respect.

For more information on forwarding tickets, see Forwarding Kerberos Tickets.

-F

Forwards a reforwardable copy of your TGT to a remote system. It is similar to -f, but it allows for access to a further (say, fourth or fifth) machine. The -F option can therefore be regarded as being a superset of the -f option. The -F option is mutually exclusive with the -f option. They cannot be used together in the same command.

For more information on forwarding tickets, see Forwarding Kerberos Tickets.

-k realm

Requests tickets for the remote host in the specified realm, instead of determining the realm itself using the krb5.conf file.

-K

Uses your tickets to authenticate to the remote host, but does not automatically log in.

-m mechanism

Specifies the GSS-API security mechanism to use, as listed in the /etc/gss/mech file. Defaults to kerberos_v5.

-x

Encrypts this session.

-X auth-type

Disables the auth-type type of authentication.

The following table shows which commands have specific options. An “X” indicates that the command has that option.

Additionally, ftp allows the protection level for a session to be set at its prompt:

clear

Sets the protection level to “clear” (no protection). This protection level is the default.

private

Sets the protection level to “private.” Data transmissions are confidentiality-protected and integrity-protected by encryption. The privacy service might not be available to all Kerberos users, however.

safe

Sets the protection level to “safe.” Data transmissions are integrity-protected by cryptographic checksum.

You can also set the protection level at the ftp prompt by typing protect followed by any of the protection levels shown above (clear, private, or safe).

Forwarding Kerberos Tickets

As described in Overview of Kerberized Commands, some commands allow you to forward tickets with either the -f or -F option. Forwarding tickets allows you to “chain” your network transactions. You can, for example, remotely log in to one machine and then remotely log in from it to another machine. The -f option allows you to forward a ticket, while the -F option allows you to reforward a forwarded ticket.

In Figure 26–2, the user david obtains a non-forwardable ticket-granting ticket (TGT) with kinit. The ticket is non-forwardable because he did not specify the -f option. In scenario 1, he is able to remotely log in to machine B, but he can go no further. In scenario 2, the rlogin -f command fails because he is attempting to forward a ticket that is non-forwardable.

Figure 26–2 Using Non-Forwardable Tickets

In actuality, Kerberos configuration files are set up so that kinit obtains forwardable tickets by default. However, your configuration might differ. For the sake of explanation, assume that kinit does not obtain forwardable TGTs unless it is invoked with kinit -f. Notice, by the way, that kinit does not have a -F option. TGTs are either forwardable or not.

In Figure 26–3, the user david obtains forwardable TGTs with kinit -f. In scenario 3, he is able to reach machine C because he uses a forwardable ticket with rlogin. In scenario 4, the second rlogin fails because the ticket is not reforwardable. By using the -F option instead, as in scenario 5, the second rlogin succeeds and the ticket can be reforwarded on to machine D.

Figure 26–3 Using Forwardable Tickets

Using Kerberized Commands (Examples)

The following examples show how the options to the Kerberized commands work.

Example 26–5 Using the -a, -f, and -x Options With telnet

In this example, the user david has already logged in, and wants to telnet to the machine denver.example.com. He uses the -f option to forward his existing tickets, the -x option to encrypt the session, and the -a option to perform the login automatically. Because he does not plan to use the services of a third host, he can use -f instead of -F.

% telnet -a -f -x denver.example.com 
Trying 128.0.0.5... 
Connected to denver.example.com. Escape character is '^]'. 
[ Kerberos V5 accepts you as "david@eng.example.com" ] 
[ Kerberos V5 accepted forwarded credentials ] 
SunOS 5.9: Tue May 21 00:31:42 EDT 2004  Welcome to SunOS 
%

Notice that david's machine used Kerberos to authenticate him to denver.example.com, and logged him in automatically as himself. He had an encrypted session, a copy of his tickets already waiting for him, and he never had to type his password. If he had used a non-Kerberos version of telnet, he would have been prompted for his password, and it would have been sent over the network unencrypted. If an intruder had been watching network traffic at the time, the intruder would have known david's password.

If you forward your Kerberos tickets, telnet (as well as the other commands discussed here) destroys them when it exits.

Example 26–6 Using rlogin With the -F Option

Here, the user jennifer wants to log in to her own machine, boston.example.com. She forwards her existing tickets with the -F option, and encrypts the session with the -x option. She chooses -F rather than -f because after she is logged in to boston, she might want to perform other network transactions requiring tickets to be reforwarded. Also, because she is forwarding her existing tickets, she does not have to type her password.

% rlogin boston.example.com -F -x
This rlogin session is using encryption for all transmissions.
Last login Mon May 19 15:19:49 from daffodil 
SunOS Release 5.9 (GENERIC) #2 Tue Nov 14 18:09:3 EST 2003 
%

Example 26–7 Setting the Protection Level in ftp

Suppose that joe wants to use ftp to get his mail from the directory ~joe/MAIL from the machine denver.example.com, encrypting the session. The exchange would look like the following:

% ftp -f denver.example.com
Connected to denver.example.com
220 denver.example.org FTP server (Version 6.0) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type 
GSSAPI authentication succeeded Name (daffodil.example.org:joe) 
232 GSSAPI user joe@MELPOMENE.EXAMPLE.COM is authorized as joe
230 User joe logged in.
Remote system type is UNIX.
Using BINARY mode to transfer files.
ftp> protect private
200 Protection level set to Private
ftp> cd ~joe/MAIL
250 CWD command successful.
ftp> get RMAIL
227 Entering Passive Mode (128,0,0,5,16,49)
150 Opening BINARY mode data connection for RMAIL (158336 bytes).
226 Transfer complete. 158336 bytes received in 1.9 seconds (1.4e+02 Kbytes/s)
ftp> quit
% 

To encrypt the session, joe sets the protection level to private.