Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

System Administration Guide: Security Services
Previous Next

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!”


Caution - 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 [email protected].
Old password:   <Jennifer types her existing password>
kpasswd: [email protected]'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 [email protected].
Old password:  <Jennifer types her existing password>
kpasswd: [email protected]'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 [email protected].
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:

[email protected]
[email protected]  

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
The preceding context describes the graphic.

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]% 
Previous Next

 
 
  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire