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 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 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 has of verifying your identity. If someone discovers your Kerberos password, Kerberos security becomes meaningless, for that person can masquerade as you -- send email that comes from "you," read, edit, or delete your files, or log into other hosts as you -- and 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. If you need to give access to your account to someone else, you can do so through Kerberos without revealing your password (See "Granting Access to Your Account"). You should never reveal your password to anyone else, not even your system administrator. Additionally, you should change your password frequently, particularly any time you believe someone might have discovered it.

Advice on Choosing a Password

Your password can include almost any character you can type (the main exceptions being control keys and the Return key). A good password is one that you can remember readily, but which no one else can easily guess. Examples of bad passwords include:

• Words that can be found in a dictionary

• Any common or popular name

• The name of a famous person or character

• Your name or username in any form (for example: backward, repeated twice, and so forth.)

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

• Your birth date or a relative's birth date

• Social Security number, driver's license number, passport number, or similar identifying number

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

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

• Acronyms, such as "I2LMHinSF" (recalled as "I too left my heart in San Francisco")

• Easy-to-pronounce nonsense words, like "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 ones an intruder will try.

Changing Your Password

You can change your Kerberos password in two ways:

• With the usual UNIX passwd command. With SEAM installed, 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 passwords (UNIX and Kerberos) at the same time. However, generally you 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 may be required to change both passwords in some configurations. For some sites the UNIX password must be changed, while others 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 might be anywhere from a few minutes to an hour or more. If you need to get new Kerberos tickets shortly after changing your password, try the new password first. If the new password doesn't work, try again using the old one.

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 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.ACME.COM.
Old password:   <jennifer enters her existing password>
kpasswd: jennifer@ENG.ACME.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 enters 'sloth'>
New password (again):  <jennifer re-enters '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.ACME.COM.
Old password:  <jennifer enters her existing password>
kpasswd: jennifer@ENG.ACME.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 enters 'slothrop49'>
New password (again):  <jennifer re-enters 'slothrop49'>
Kerberos password changed.

Examples -- Changing Your Password

The following example shows david changing both his UNIX and Kerberos passwords with passwd.

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

In the above example passwd asks for both the UNIX and Kerberos password; however, if try_first_pass is set in the PAM module, the Kerberos password is automatically set to be the same as the UNIX password. (That is the default configuration.) In that case, david must use kpasswd to set his Kerberos password to something else, as shown next.

This example shows him changing only his Kerberos password with kpasswd:

% kpasswd
kpasswd: Changing password for david@ENG.ACME.COM.
Old password:           <enter the current Kerberos password>
New password:           <enter the new Kerberos password>
New password (again):   <confirm the new Kerberos password>
Kerberos password changed.
 

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

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

Granting Access to Your Account

If you need to give someone access to log into 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 this:

jennifer@ENG.ACME.COM
joe@ACME.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 rlogin into david's machine (boston), as him, without having to give his password:

Figure 6-1 Using the .k5login File

(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 "How to Create a Ticket" for an example of using a forwardable ticket.)

If you will be logging into 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:

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

• Although users 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), they do not inherit your network privileges -- that is, 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, but if she uses a Kerberized programs 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 allows system administrators to become root locally, or to log in remotely as root, without having to give out the root password, and without anyone having to type the root password over the network.

Example -- Using the .k5login File

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

% rlogin boston.acme.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]%