System Administration Guide: Security Services

Chapter 11 Using SEAM (Tasks)

This chapter is intended for anyone on a system with SEAM installed on it. This chapter 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:

For an overview of SEAM, see Chapter 6, Introduction to SEAM.

Ticket Management

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

Do You Need to Worry About Tickets?

With SEAM 1.0 or 1.0.1 installed, Kerberos is built into the login command, and you will obtain tickets automatically when you log in.

Most of the Kerberized commands also automatically destroy your tickets when they exit. However, you might want to explicitly destroy your Kerberos tickets with kdestroy when you are finished with them, just to be sure. See How to Destroy Tickets for more information on kdestroy.

For information on ticket lifetimes, see Ticket Lifetimes.

How to Create a Ticket

Normally, 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.

To create a ticket, use the kinit command.


% /usr/bin/kinit
 

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

Example—Creating a 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.


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

For more on how forwarding tickets works, see Types of Tickets.

How to View Tickets

Not all tickets are alike. One ticket might be, for example, 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:

Forwardable 

Forwarded 

Proxiable 

Proxy 

Postdateable 

Postdated 

Renewable 

Initial 

Invalid 

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

Example—Viewing 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: jenniferm@ENG.EXAMPLE.COM
 
Valid starting                 Expires                 Service principal
09 Mar 99 15:09:51  09 Mar 99 21:09:51  nfs/EXAMPLE.SUN.COM@EXAMPLE.SUN.COM
        renew until 10 Mar 99 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 99 06:09:51  09 Mar 99 23:33:51  host/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 99 17:09:51, Flags: fF
 
Valid starting                 Expires                 Service principal
08 Mar 99 08:09:51  09 Mar 99 12:54:51  nfs/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 99 15:22:51, Flags: fF

How to Destroy Tickets

Usually, tickets are destroyed automatically when the commands that created them exit. However, you might want to explicitly destroy your Kerberos tickets when you are finished with them, just to be sure. Tickets can be stolen. If tickets are stolen, the person who has stolen them can use them until they expire (although stolen tickets must be decrypted).

To destroy your tickets, use the kdestroy command.


% /usr/bin/kdestroy

kdestroy 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.


Note –

One way to help ensure that your tickets are always destroyed is to add the kdestroy command to the .logout file in your home directory.

In instances where the PAM module has been configured (which is the default and usual case), tickets are destroyed automatically upon logout. So, adding a call to kdestroy to your .login file is not necessary. However, if the PAM module has not been configured, or if you don't know whether it has been, you might want to add kdestroy to your .login file to ensure that your tickets are destroyed when you exit your system.


Password Management

With SEAM installed, 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.

Non-Kerberized commands, such as login, are typically set up through PAM to authenticate with both Kerberos and UNIX. If you have different passwords, you must provide both passwords to log on with the appropriate authentication. However, if both passwords are the same, the first password you enter for UNIX is also accepted by Kerberos.

Unfortunately, using the same password for both Kerberos and UNIX can compromise security. That is, if someone discovers your Kerberos password, then your UNIX password is no longer a secret. However, using the same passwords for UNIX and Kerberos is still more secure than in a site without Kerberos, because passwords in a Kerberos environment are not sent across the network. Usually, your site will have a policy to help you determine your options.

Your Kerberos password is the only way Kerberos can verify your identity. If someone discovers your Kerberos password, Kerberos security becomes meaningless, because that person can masquerade as you. That person can send email that comes from “you,” read, edit, or delete your files, or log into other hosts as you. No one will be able to tell the difference. For this reason, it is vital that you choose a good password and keep it secret. You should never reveal your password to anyone else, not even your system administrator. Additionally, you should change your password frequently, particularly any time that you believe someone might have discovered it.

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 which no one else can easily guess. Examples of bad passwords include the following:

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:


Caution – Caution –

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


Changing Your Password

You can change your Kerberos password in two ways:

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 allows 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 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 kinds 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 kinds 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.

Examples—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>

In the preceding example passwd asks for both the UNIX password and the Kerberos password. However, if try_first_pass is set in the PAM module, the Kerberos password is automatically set to the UNIX password. This is 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.