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)

25.  The Kerberos Service (Reference)

Kerberos Files

Kerberos Commands

Kerberos Daemons

Kerberos Terminology

Kerberos-Specific Terminology

Authentication-Specific Terminology

Types of Tickets

Ticket Lifetimes

Kerberos Principal Names

How the Kerberos Authentication System Works

How the Kerberos Service Interacts With DNS and the nsswitch Service

Gaining Access to a Service Using Kerberos

Obtaining a Credential for the Ticket-Granting Service

Obtaining a Credential for a Server

Obtaining Access to a Specific Service

Using Kerberos Encryption Types

Using the gsscred Table

Notable Differences Between Oracle Solaris Kerberos and MIT Kerberos

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)

Glossary

Index

Kerberos Terminology

The following section presents Kerberos terms and their definitions. These terms are used throughout the Kerberos documentation. To grasp Kerberos concepts, an understanding of these terms is essential.

Kerberos-Specific Terminology

You need to understand the terms in this section in order to administer KDCs.

The Key Distribution Center or KDC is the component of Kerberos that is responsible for issuing credentials. These credentials are created by using information that is stored in the KDC database. Each realm needs at least two KDCs, a master and at least one slave. All KDCs generate credentials, but only the master KDC handles any changes to the KDC database.

A stash file contains the master key for the KDC. This key is used when a server is rebooted to automatically authenticate the KDC before starting the kadmind and krb5kdc commands. Because this file includes the master key, the file and any backups of the file should be kept secure. The file is created with read-only permissions for root. To keep the file secure, do not change the permissions. If the file is compromised, then the key could be used to access or modify the KDC database.

Authentication-Specific Terminology

You need to know the terms in this section to understand the authentication process. Programmers and system administrators should be familiar with these terms.

A client is the software that runs on a user's workstation. The Kerberos software that runs on the client makes many requests during this process. So, differentiating the actions of this software from the user is important.

The terms server and service are often used interchangeably. To clarify, the term server is used to define the physical system that Kerberos software is running on. The term service corresponds to a particular function that is being supported on a server (for example, ftp or nfs). Documentation often mentions servers as part of a service, but this definition clouds the meaning of the terms. Therefore, the term server refers to the physical system. The term service refers to the software.

The Kerberos product uses two types of keys. One type of key is a password derived key. The password derived key is given to each user principal and is known only to the user and to the KDC. The other type of key used by the Kerberos product is a random key that is not associated with a password and so is not suitable for use by user principals. Random keys are typically used for service principals that have entries in a keytab and session keys generated by the KDC. Service principals can use random keys since the service can access the key in the keytab which allows it to run non-interactively. Session keys are generated by the KDC (and shared between the client and service) to provide secure transactions between a client and a service.

A ticket is an information packet that is used to securely pass the identity of a user to a server or service. A ticket is valid for only a single client and a particular service on a specific server. A ticket contains:

All of this data is encrypted in the server's service key. Note, the KDC issues the ticket embedded in a credential described below. After a ticket has been issued, it can be reused until the ticket expires.

A credential is a packet of information that includes a ticket and a matching session key. The credential is encrypted with the requesting principal's key. Typically, the KDC generates a credential in response to a ticket request from a client.

An authenticator is information used by the server to authenticate the client user principal. An authenticator includes the principal name of the user, a timestamp, and other data. Unlike a ticket, an authenticator can be used once only, usually when access to a service is requested. An authenticator is encrypted by using the session key shared by the client and server. Typically, the client creates the authenticator and sends it with the server's or service's ticket in order to authenticate to the server or service.

Types of Tickets

Tickets have properties that govern how they can be used. These properties are assigned to the ticket when it is created, although you can modify a ticket's properties later. For example, a ticket can change from being forwardable to being forwarded. You can view ticket properties with the klist command. See Viewing Kerberos Tickets.

Tickets can be described by one or more of the following terms:

Forwardable/forwarded

A forwardable ticket can be sent from one host to another host, obviating the need for a client to reauthenticate itself. For example, if the user david obtains a forwardable ticket while on user jennifer's machine, he can log in to his own machine without having to get a new ticket (and thus authenticate himself again). See Example 24-1 for an example of a forwardable ticket.

Initial

An initial ticket is a ticket that is issued directly, not based on a ticket-granting ticket. Some services, such as applications that change passwords, can require tickets to be marked initial in order to assure themselves that the client can demonstrate a knowledge of its secret key. An initial ticket indicates that the client has recently authenticated itself, instead of relying on a ticket-granting ticket, which might have been around for a long time.

Invalid

An invalid ticket is a postdated ticket that has not yet become usable. An invalid ticket will be rejected by an application server until it becomes validated. To be validated, a ticket must be presented to the KDC by the client in a ticket-granting service request, with the VALIDATE flag set, after its start time has passed.

Postdatable/postdated

A postdated ticket is a ticket that does not become valid until some specified time after its creation. Such a ticket is useful, for example, for batch jobs that are intended to be run late at night, because the ticket, if stolen, cannot be used until the batch job is to be run. When a postdated ticket is issued, it is issued as invalid and remains that way until its start time has passed, and the client requests validation by the KDC. A postdated ticket is normally valid until the expiration time of the ticket-granting ticket. However, if the ticket is marked renewable, its lifetime is normally set to be equal to the duration of the full life of the ticket-granting ticket.

Proxiable/proxy

At times, it is necessary for a principal to allow a service to perform an operation on its behalf. The principal name of the proxy must be specified when the ticket is created. The Oracle Solaris release does not support proxiable or proxy tickets.

A proxiable ticket is similar to a forwardable ticket, except that it is valid only for a single service, whereas a forwardable ticket grants the service the complete use of the client's identity. A forwardable ticket can therefore be thought of as a sort of super-proxy.

Renewable

Because it is a security risk to have tickets with very long lives, tickets can be designated as renewable. A renewable ticket has two expiration times: the time at which the current instance of the ticket expires, and the maximum lifetime for any ticket, which is one week. If a client wants to continue to use a ticket, the client renews it before the first expiration occurs. For example, a ticket can be valid for one hour, with all tickets having a maximum lifetime of 10 hours. If the client that is holding the ticket wants to keep it for more than an hour, the client must renew it within that hour. When a ticket reaches the maximum ticket lifetime (10 hours), it automatically expires and cannot be renewed.

For information on how to view the attributes of tickets, see Viewing Kerberos Tickets.

Ticket Lifetimes

Any time a principal obtains a ticket, including a ticket-granting ticket (TGT), the ticket's lifetime is set as the smallest of the following lifetime values:

Figure 25-1 shows how a TGT's lifetime is determined and where the four lifetime values come from. Even though this figure shows how a TGT's lifetime is determined, basically the same thing happens when any principal obtains a ticket. The only differences are that kinit doesn't provide a lifetime value, and the service principal that provides the ticket provides a maximum lifetime value (instead of the krbtgt/realm principal).

Figure 25-1 How a TGT's Lifetime is Determined

image:Diagram shows that a ticket lifetime is the smallest value allowed by the kinit command, the user principal, the site default, and the ticket granter.

The renewable ticket lifetime is also determined from the minimum of four values, but renewable lifetime values are used instead, as follows:

Kerberos Principal Names

Each ticket is identified by a principal name. The principal name can identify a user or a service. Here are examples of several principal names.

Table 25-4 Examples of Kerberos Principal Names

Principal Name
Description
changepw/kdc1.example.com@EXAMPLE.COM
A principal for the master KDC server that allows access to the KDC when you are changing passwords.
clntconfig/admin@EXAMPLE.COM
A principal that is used by the kclient installation utility.
ftp/boston.example.com@EXAMPLE.COM
A principal used by the ftp service. This principal can be used instead of a host principal.
host/boston.example.com@EXAMPLE.COM
A principal that is used by the Kerberized applications (klist and kprop, for example) and services (such as ftp and telnet). This principal is called a host or service principal. The principal is used to authenticate NFS mounts. This principal is also used by a client to verify that the TGT that is issued to the client is from the correct KDC.
K/M@EXAMPLE.COM
The master key name principal. One master key name principal is associated with each master KDC.
kadmin/history@EXAMPLE.COM
A principal that includes a key used to keep password histories for other principals. Each master KDC has one of these principals.
kadmin/kdc1.example.com@EXAMPLE.COM
A principal for the master KDC server that allows access to the KDC by using kadmind.
kadmin/changepw.example.com@EXAMPLE.COM
A principal that is used to accept password change requests from clients that are not running an Oracle Solaris release.
krbtgt/EXAMPLE.COM@EXAMPLE.COM
This principal is used when you generate a ticket-granting ticket.
krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM
This principal is an example of a cross-realm ticket-granting ticket.
nfs/boston.example.com@EXAMPLE.COM
A principal that is used by the NFS service. This principal can be used instead of a host principal.
root/boston.example.com@EXAMPLE.COM
A principal that is associated with the root account on a client. This principal is called a root principal and provides root access to NFS mounted file systems..
username@EXAMPLE.COM
A principal for a user.
username/admin@EXAMPLE.COM
An admin principal that can be used to administer the KDC database.