JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Administration: Security Services     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Verifying File Integrity by Using BART (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Using Pluggable Authentication Modules

15.  Using Secure Shell

16.  Secure Shell (Reference)

17.  Using Simple Authentication and Security Layer

18.  Network Services Authentication (Tasks)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

Kerberos Ticket Management

Do You Need to Worry About Tickets?

Creating a Kerberos Ticket

Viewing Kerberos Tickets

Destroying Kerberos Tickets

Kerberos Password Management

Advice on Choosing a Password

Changing Your Password

Granting Access to Your Account

Kerberos User Commands

Overview of Kerberized Commands

Forwarding Kerberos Tickets

Using Kerberized Commands (Examples)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)

Glossary

Index

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:

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

If PAM is properly configured, 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 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 24-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 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 24-1 Using the .k5login File to Grant Access to Your Account

image:This graphic shows a session using a .k5login file to grant access to an 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:

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 24-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]%