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.
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.
If PAM is properly configured, you can change your Kerberos password in two ways:
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.
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.
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.
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.
% 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.
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:
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.
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.
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.
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]%