JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Security Services     Oracle Solaris 10 1/13 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.  Controlling Access to Devices (Tasks)

5.  Using the Basic Audit Reporting Tool (Tasks)

6.  Controlling Access to Files (Tasks)

7.  Using the Automated Security Enhancement Tool (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Role-Based Access Control (Reference)

11.  Privileges (Tasks)

12.  Privileges (Reference)

Part IV Cryptographic Services

13.  Oracle Solaris Cryptographic Framework (Overview)

14.  Oracle Solaris Cryptographic Framework (Tasks)

15.  Oracle Solaris Key Management Framework

Part V Authentication Services and Secure Communication

16.  Using Authentication Services (Tasks)

17.  Using PAM

18.  Using SASL

19.  Using Secure Shell (Tasks)

20.  Secure Shell (Reference)

Part VI Kerberos Service

21.  Introduction to the Kerberos Service

What Is the Kerberos Service?

How the Kerberos Service Works

Initial Authentication: the Ticket-Granting Ticket

Subsequent Kerberos Authentications

The Kerberos Remote Applications

Kerberos Principals

Kerberos Realms

Kerberos Servers

Kerberos Security Services

The Components of Various Kerberos Releases

Kerberos Components

Kerberos Additions for the Solaris 10 5/08 Release

Kerberos Additions for the Solaris 10 8/07 Release

Kerberos Additions for the Solaris 10 6/06 Release

Kerberos Enhancements in the Solaris 10 3/05 Release

Kerberos Components in the Solaris 9 Release

SEAM 1.0.2 Components

Kerberos Components in the Solaris 8 Release

SEAM 1.0.1 Components

SEAM 1.0 Components

22.  Planning for the Kerberos Service

23.  Configuring the Kerberos Service (Tasks)

24.  Kerberos Error Messages and Troubleshooting

25.  Administering Kerberos Principals and Policies (Tasks)

26.  Using Kerberos Applications (Tasks)

27.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

28.  Oracle Solaris Auditing (Overview)

29.  Planning for Oracle Solaris Auditing

30.  Managing Oracle Solaris Auditing (Tasks)

31.  Oracle Solaris Auditing (Reference)

Glossary

Index

How the Kerberos Service Works

The following is an overview of the Kerberos authentication system. For a more detailed description, see How the Kerberos Authentication System Works.

From the user's standpoint, the Kerberos service is mostly invisible after the Kerberos session has been started. Commands such as rsh or ftp work about the same. Initializing a Kerberos session often involves no more than logging in and providing a Kerberos password.

The Kerberos system revolves around the concept of a ticket. A ticket is a set of electronic information that identifies a user or a service such as the NFS service. Just as your driver's license identifies you and indicates what driving privileges you have, so a ticket identifies you and your network access privileges. When you perform a Kerberos-based transaction (for example, if you remote log in to another machine), you transparently send a request for a ticket to a Key Distribution Center, or KDC. The KDC accesses a database to authenticate your identity and returns a ticket that grants you permission to access the other machine. “Transparently” means that you do not need to explicitly request a ticket. The request happens as part of the rlogin command. Because only an authenticated client can get a ticket for a specific service, another client cannot use rlogin under an assumed identity.

Tickets have certain attributes associated with them. For example, a ticket can be forwardable, which means that it can be used on another machine without a new authentication process. A ticket can also be postdated, which means that it is not valid until a specified time. How tickets can be used, for example, to specify which users are allowed to obtain which types of ticket, is set by policies. Policies are determined when the Kerberos service is installed or administered.


Note - You will frequently see the terms credential and ticket. In the greater Kerberos world, they are often used interchangeably. Technically, however, a credential is a ticket plus the session key for that session. This difference is explained in more detail in Gaining Access to a Service Using Kerberos.


The following sections further explain the Kerberos authentication process.

Initial Authentication: the Ticket-Granting Ticket

Kerberos authentication has two phases: an initial authentication that allows for all subsequent authentications, and the subsequent authentications themselves.

The following figure shows how the initial authentication takes place.

Figure 21-1 Initial Authentication for a Kerberos Session

image:Flow diagram shows a client requesting a TGT from the KDC, and then decrypting the TGT that the KDC returns to the client.
  1. A client (a user, or a service such as NFS) begins a Kerberos session by requesting a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). This request is often done automatically at login.

    A ticket-granting ticket is needed to obtain other tickets for specific services. Think of the ticket-granting ticket as similar to a passport. Like a passport, the ticket-granting ticket identifies you and allows you to obtain numerous “visas,” where the “visas” (tickets) are not for foreign countries but for remote machines or network services. Like passports and visas, the ticket-granting ticket and the other various tickets have limited lifetimes. The difference is that “Kerberized” commands notice that you have a passport and obtain the visas for you. You don't have to perform the transactions yourself.

    Another analogy for the ticket-granting ticket is that of a three-day ski pass that is good at four different ski resorts. You show the pass at whichever resort you decide to go to and you receive a lift ticket for that resort, as long as the pass has not expired. Once you have the lift ticket, you can ski all you want at that resort. If you go to another resort the next day, you once again show your pass, and you get an additional lift ticket for the new resort. The difference is that the Kerberos-based commands notice that you have the weekend ski pass, and they get the lift ticket for you. So you don't have to perform the transactions yourself.

  2. The KDC creates a ticket–granting ticket and sends it back, in encrypted form, to the client. The client decrypts the ticket-granting ticket by using the client's password.

  3. Now in possession of a valid ticket-granting ticket, the client can request tickets for all sorts of network operations, such as rlogin or telnet, for as long as the ticket-granting ticket lasts. This ticket usually lasts for a few hours. Each time the client performs a unique network operation, it requests a ticket for that operation from the KDC.

Subsequent Kerberos Authentications

After the client has received the initial authentication, each subsequent authentication follows the pattern that is shown in the following figure.

Figure 21-2 Obtaining Access to a Service Using Kerberos Authentication

image:Flow diagram shows the client using a TGT to request a ticket from the KDC, and then using the returned ticket for access to the server.
  1. The client requests a ticket for a particular service, for example, to remote log in to another machine, from the KDC by sending the KDC its ticket-granting ticket as proof of identity.

  2. The KDC sends the ticket for the specific service to the client.

    For example, suppose user joe wants to access an NFS file system that has been shared with krb5 authentication required. Because he is already authenticated (that is, he already has a ticket-granting ticket), as he attempts to access the files, the NFS client system automatically and transparently obtains a ticket from the KDC for the NFS service.

    For example, suppose the user joe uses rlogin on the server boston. Because he is already authenticated, that is, he already has a ticket-granting ticket, he automatically and transparently obtains a ticket as part of the rlogin command. This ticket allows him to remote log in to boston as often as he wants until the ticket expires. If joe wants to remote log in to the machine denver, he obtains another ticket, as in Step 1.

  3. The client sends the ticket to the server.

    When using the NFS service, the NFS client automatically and transparently sends the ticket for the NFS service to the NFS server.

  4. The server allows the client access.

These steps make it appear that the server doesn't ever communicate with the KDC. The server does, though; it registers itself with the KDC, just as the first client does. For simplicity's sake, that part has been left out.

The Kerberos Remote Applications

The Kerberos-based (or “Kerberized”) commands that a user such as joe can use are the following:

These applications are the same as the Solaris applications of the same name. However, they have been extended to use Kerberos principals to authenticate transactions, thereby providing Kerberos-based security. See Kerberos Principals for information on principals.

These commands are discussed further in Kerberos User Commands.

Kerberos Principals

A client in the Kerberos service is identified by its principal. A principal is a unique identity to which the KDC can assign tickets. A principal can be a user, such as joe, or a service, such as nfs or telnet.

By convention, a principal name is divided into three components: the primary, the instance, and the realm. A typical Kerberos principal would be, for example, joe/admin@ENG.EXAMPLE.COM. In this example:

The following are all valid principal names:

Kerberos Realms

A realm is a logical network, similar to a domain, that defines a group of systems under the same master KDC. Figure 21-3 shows how realms can relate to one another. Some realms are hierarchical, where one realm is a superset of the other realm. Otherwise, the realms are nonhierarchical (or “direct”) and the mapping between the two realms must be defined. A feature of the Kerberos service is that it permits authentication across realms. Each realm only needs to have a principal entry for the other realm in its KDC. This Kerberos feature is called cross-realm authentication.

Figure 21-3 Kerberos Realms

image:Diagram shows the ENG.EXAMPLE.COM realm in a non-hierarchical relationship with SEAMCO.COM, and in a hierarchical relationship with EXAMPLE.COM.

Kerberos Servers

Each realm must include a server that maintains the master copy of the principal database. This server is called the master KDC server. Additionally, each realm should contain at least one slave KDC server, which contains duplicate copies of the principal database. Both the master KDC server and the slave KDC server create tickets that are used to establish authentication.

The realm can also include a Kerberos application server. This server provides access to Kerberized services (such as ftp, telnet, rsh and NFS). If you have installed SEAM 1.0 or 1.0.1, the realm might include a Kerberos network application server, but this software was not included with these releases.

The following figure shows what a hypothetical realm might contain.

Figure 21-4 A Typical Kerberos Realm

image:Diagram shows a typical Kerberos realm, EXAMPLE.COM, which contains a master KDC, three clients, two slave KDCs, and two application servers.