System Administration Guide: Security Services

Chapter 21 Introduction to the Kerberos Service

This chapter introduces the Kerberos Service. The following is a list of the overview information in this chapter.

What Is the Kerberos Service?

The Kerberos service is a client-server architecture that provides secure transactions over networks. The service offers strong user authentication, as well as integrity and privacy. Authentication guarantees that the identities of both the sender and the recipient of a network transaction are true. The service can also verify the validity of data being passed back and forth (integrity) and encrypt the data during transmission (privacy). Using the Kerberos service, you can log in to other machines, execute commands, exchange data, and transfer files securely. Additionally, the service provides authorization services, which allows administrators to restrict access to services and machines. Moreover, as a Kerberos user, you can regulate other people's access to your account.

The Kerberos service is a single-sign-on system, which means that you only need to authenticate yourself to the service once per session, and all subsequent transactions during the session are automatically secured. After the service has authenticated you, you do not need to authenticate yourself every time you use a Kerberos-based command such as ftp or rsh, or to access data on an NFS file system. Thus, you do not have to send your password over the network, where it can be intercepted, each time you use these services.

The Solaris Kerberos service is based on the Kerberos V5 network authentication protocol that was developed at the Massachusetts Institute of Technology (MIT). People who have used Kerberos V5 product should therefore find the Solaris version very familiar. Because the Kerberos V5 protocol is a de facto industry standard for network security, the Solaris version promotes interoperability with other systems. In other words, because the Solaris Kerberos service works with systems that use the Kerberos V5 protocol, the service allows for secure transactions even over heterogeneous networks. Moreover, the service provides authentication and security both between domains and within a single domain.

The Kerberos service allows for flexibility in running Solaris applications. You can configure the service to allow both Kerberos-based and non-Kerberos-based requests for network services such as the NFS service, telnet, and ftp. As a result, current Solaris applications still work even if they are running on systems on which the Kerberos service is not enabled. Of course, you can also configure the Kerberos service to allow only Kerberos-based network requests.

The Kerberos service provides a security mechanism which allows the use of Kerberos for authentication, integrity, and privacy when using applications that use the Generic Security Service Application Programming Interface (GSS-API). However, applications do not have to remain committed to the Kerberos service if other security mechanisms are developed. Because the service is designed to integrate modularly into the GSS-API, applications that use the GSS-API can utilize whichever security mechanism best suits their needs.

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

Flow diagram shows a client requesting a TGT from the
KDC, and then decrypting the TGT that the KDC returns to the client.

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.
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.
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

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.

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.
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.
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.
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:

ftp
rcp
rdist
rlogin
rsh
ssh
telnet

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:

joe is the primary. The primary can be a user name, as shown here, or a service, such as nfs. The primary can also be the word host, which signifies that this principal is a service principal that is set up to provide various network services, ftp, rcp, rlogin, and so on.
admin is the instance. An instance is optional in the case of user principals, but it is required for service principals. For example, if the user joe sometimes acts as a system administrator, he can use joe/admin to distinguish himself from his usual user identity. Likewise, if joe has accounts on two different hosts, he can use two principal names with different instances, for example, joe/denver.example.com and joe/boston.example.com. Notice that the Kerberos service treats joe and joe/admin as two completely different principals.

In the case of a service principal, the instance is the fully qualified host name. bigmachine.eng.example.com is an example of such an instance. The primary/instance for this example might be ftp/bigmachine.eng.example.com or host/bigmachine.eng.example.com.
ENG.EXAMPLE.COM is the Kerberos realm. Realms are discussed in Kerberos Realms.

The following are all valid principal names:

joe
joe/admin
joe/admin@ENG.EXAMPLE.COM
nfs/host.eng.example.com@ENG.EXAMPLE.COM
host/eng.example.com@ENG.EXAMPLE.COM

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

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

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

Kerberos Security Services

In addition to providing secure authentication of users, the Kerberos service provides two security services:

Integrity – Just as authentication ensures that clients on a network are who they claim to be, integrity ensures that the data they send is valid and has not been tampered with during transit. Integrity is done through cryptographic checksumming of the data. Integrity also includes user authentication.
Privacy – Privacy takes security a step further. Privacy not only includes verifying the integrity of transmitted data, but it encrypts the data before transmission, protecting it from eavesdroppers. Privacy authenticates users, as well.

Developers can design their RPC-based applications to choose a security service by using the RPCSEC_GSS programming interface.

The Components of Various Kerberos Releases

Components of the Kerberos service have been included in many releases. Originally, the Kerberos service and changes to the base operating system to support the Kerberos service were released using the product name “Sun Enterprise Authentication Mechanism” which was shortened to SEAM. As more parts of the SEAM product were included in the Solaris software, the contents of the SEAM release decreased. For the Solaris 10 release, all parts of the SEAM product are included, so there is no longer a need for the SEAM product. The SEAM product name exists in the documentation for historical reasons.

The following table describes which components are included in each release. Each product release is listed in chronological order. All components are described in the following sections.

Table 21–1 Kerberos Release Contents


Release Name	Contents
SEAM 1.0 in Solaris Easy Access Server 3.0	Full release of the Kerberos service for the Solaris 2.6 and 7 releases
The Kerberos service in the Solaris 8 release	Kerberos client software only
SEAM 1.0.1 in the Solaris 8 Admin Pack	Kerberos KDC and remote applications for the Solaris 8 release
The Kerberos service in the Solaris 9 release	Kerberos KDC and client software only
SEAM 1.0.2	Kerberos remote applications for the Solaris 9 release
The Kerberos service in the Solaris 10 release	Full release of the Kerberos service with enhancements

Kerberos Components

Similar to the MIT distribution of the Kerberos V5 product, the Solaris Kerberos service includes the following:

Key Distribution Center (KDC):
- Kerberos database administration daemon – kadmind.
- Kerberos ticket processing daemon – krb5kdc.
- Database administration programs – kadmin (master only), kadmin.local and kdb5_util.
- Database propagation software – kprop (slave only) and kpropd.
User programs for managing credentials – kinit, klist, and kdestroy.
User program for changing your Kerberos password – kpasswd.
Remote applications – ftp, rcp, rdist, rlogin, rsh, ssh, and telnet.
Remote application daemons – ftpd, rlogind, rshd, sshd, and telnetd.
Keytab administration utility – ktutil.
The Generic Security Service Application Programming Interface (GSS-API) – Enables applications to use multiple security mechanisms without requiring you to recompile the application every time a new mechanism is added. The GSS-API uses standard interfaces that allow applications to be portable to many operating systems. GSS-API provides applications with the ability to include the integrity and privacy security services, as well as authentication. Both ftp and ssh use the GSS-API.
The RPCSEC_GSS Application Programming Interface (API) – Enables NFS services to use Kerberos authentication. RPCSEC_GSS is a security flavor that provides security services that are independent of the mechanisms being used. RPCSEC_GSS sits on top of the GSS-API layer. Any pluggable GSS_API-based security mechanism can be used by applications that use RPCSEC_GSS.

In addition, the Solaris Kerberos service includes the following:

Graphical Kerberos Administration Tool (gkadmin) – Enables you to administer the principals and principal policies. This Java^TM technology-based GUI is an alternative to the kadmin command.
A Kerberos V5 service module for PAM – Provides authentication, account management, session management and password management for the Kerberos service. The module can be used to make Kerberos authentication transparent to the user.
Kernel modules – Provides kernel-based implementations of the kerberos service for use by the NFS service, which greatly improves performance.

Kerberos Additions for the Solaris Express Community Edition Release

In build 90, the kclient script was enhanced. The script includes the feature of joining Microsoft Active Directory servers. See How to Interactively Configure a Kerberos Client and How to Configure a Kerberos Client for an Active Directory Server for instructions. In addition, the script includes a -T option that may be used to identify the KDC server type for the client. All of the options for this script are covered in the kclient(1M) man page.

In build 102, the /etc/krb5/kadm5.keytab file is no longer needed. The keys that were stored in this file are now directly read from the Kerberos database.

Kerberos Additions for the Solaris Express Developer Edition 1/08 Release

These enhancements are available starting in the Solaris Express Developer Edition 1/08 release:

The Solaris Kerberos software has been synchronized with the MIT 1.4 version. In particular, the software for the KDC, the kinit command and the Kerberos mechanism have been updated.
Support for accessing Kerberos principal and policy records using LDAP from a directory server has been added. This change simplifies administration and can provide greater availability, depending on the deployment of the KDCs and the DSs. See Managing a KDC on an LDAP Directory Server for a list of LDAP-related procedures.
The new kdcmgr command which can be used to automatically or interactively setup any KDC. This command works to create both master and slave KDC servers. Also, used with the status option, the kdcmgr command shows information about any KDC installed on the localhost. Look for the pointers to the automatic or interactive procedures in Table 23–1.
Support for Solaris clients that require no additional setup has been added to this release. Changes were made to the Kerberos service and to some default settings. Solaris Kerberos clients work with no client-side configuration in environments that are appropriately configured. See Client Configuration Options for more information.

Kerberos Additions for the Solaris 10 8/07 Release

The MIT Kerberos V5 application programming interface (krb5-api) is supported in the Solaris 10 8/07 release. See the libkrb5(3LIB) and krb5-config(1) man pages for more information. Also, see the MIT Kerberos V5 project web pages at mit.edu for more detailed documentation as it becomes available.

Although the krb5-api is now available, Sun strongly encourages the use of the GSS-API for network authentication and integrity and privacy as the GSS-API is security-mechanism independent and an IETF standard. See the libgss(3LIB) man page for more information.

Kerberos Additions for the Solaris 10 6/06 Release

In the Solaris 10 6/06 release, the ktkt_warnd daemon can automatically renew credentials, rather than just warn the user when the credential is about to expire. The user must be logged in for the credential to be renewed automatically.

Kerberos Enhancements in the Solaris 10 3/05 Release

These Kerberos enhancements are included in the Solaris 10 Release. Several of the enhancements were introduced in prior Software Express releases and updated in the Solaris 10 Beta releases.

Kerberos protocol support is provided in remote applications, such as ftp, rcp, rdist, rlogin, rsh, ssh, and telnet. See the man pages for each command or daemon and the krb5_auth_rules(5) man page for more information.
The Kerberos principal database can now be transferred by incremental update instead of by transferring the entire database each time. Incremental propagation provides these advantages:
- Increased database consistencies across servers
- The need for fewer resources (network, CPU, and so forth)
- Much more timely propagation of updates
- An automated method of propagation
A new script to help automatically configure a Kerberos client is now available. The script helps an administrator quickly and easily set up a Kerberos client. For procedures using the new script, see Configuring Kerberos Clients. Also, see the kclient(1M) man page for more information.
Several new encryption types have been added to the Kerberos service. These new encryption types increase security and enhance compatibility with other Kerberos implementations that support these encryption types. See Using Kerberos Encryption Types for more information. The encryption types include:
- The AES encryption type can be used for high speed, high security encryption of Kerberos sessions.
- ARCFOUR-HMAC provides better compatibility with other Kerberos implementations.
- Triple DES (3DES) with SHA1 increases security. This encryption type also enhances interoperability with other Kerberos implementations that support this encryption type.
The encryption types are enabled through the Cryptographic Framework. The framework can provide for hardware accelerated cryptography for the Kerberos service.
The KDC software, the user commands, and user applications now support the use of the TCP network protocol. This enhancement provides more robust operation and better interoperability with other Kerberos implementations, including Microsoft's Active Directory. The KDC now listens on both the traditional UDP ports as well as TCP ports so it can respond to requests using either protocol. The user commands and applications first try UDP when sending a request to the KDC, and if that fails, then try TCP.
Support for IPv6 was added to the KDC software, which includes the kinit, klist and kprop commands. Support for IPv6 addresses is provided by default. There are no configuration parameters to change to enable IPv6 support. No IPv6 support is available for the kadmin and kadmind commands.
A new -e option has been included to several subcommands of the kadmin command. This new option allows for the selection of the encryption type during the creation of principals. See the kadmin(1M) man page for more information.
Additions to the pam_krb5 module to manage the Kerberos credentials cache by using the PAM framework. See the pam_krb5(5) man page for more information.
Support is provided for auto-discovery of the Kerberos KDC, admin server, kpasswd server, and host or domain name-to-realm mappings by using DNS lookups. This enhancement reduces some of the steps needed to install a Kerberos client. The client is able to locate a KDC server by using DNS instead of by reading a configuration file. See the krb5.conf(4) man page for more information.
A new PAM module called pam_krb5_migrate has been introduced. The new module helps in the automatic migration of users to the local Kerberos realm, if they do not already have Kerberos accounts. See the pam_krb5_migrate(5) man page for more information.
The ~/.k5login file can now be used with the GSS applications ftp and ssh. For more information, see the gss_auth_rules(5) man page.
The kproplog utility has been updated to output all attribute names per log entry. For more information, see the kproplog(1M) man page.
Strict TGT verification can now be disabled using a configuration option in the krb5.conf file. See the krb5.conf(4) man page for more information.
Extensions to the password-changing utilities enable the Solaris Kerberos V5 administration server to accept password change requests from clients that do not run Solaris software. See the kadmind(1M) man page for more information.
The default location of the replay cache has been moved from RAM-based file systems to persistent storage in /var/krb5/rcache/. The new location protects against replays if a system is rebooted. Performance enhancements were made to the rcache code. However, overall replay cache performance might be slower due to the use of persistent storage.
The replay cache can now be configured to use file or memory only storage. Refer to the krb5envvar(5) man page for more information about environment variables that can be configured for key table and credential cache types or locations.
The GSS credential table is no longer necessary for the Kerberos GSS mechanism. For more information, see Mapping GSS Credentials to UNIX Credentials or the gsscred(1M), gssd(1M), and gsscred.conf(4) man pages.
The Kerberos utilities, kinit and ktutil, are now based on MIT Kerberos version 1.2.1. This change added new options to the kinit command and new subcommands to the ktutil command. For more information, see the kinit(1) and ktutil(1) man pages.
The Solaris Kerberos Key Distribution Center (KDC) and kadmind is now based on MIT Kerberos version 1.2.1. The KDC now defaults to a btree-based database, which is more reliable than the current hash-based database. See the kdb5_util(1M) man page for more information.
The kpropd, kadmind, krb5kdc and ktkt_warnd daemons are managed by the Service Management Facility. Administrative actions on this service, such as enabling, disabling, or restarting, can be performed using the svcadm command. The service's status for all daemons can be queried using the svcs command. For an overview of the Service Management Facility refer to Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration.

Kerberos Components in the Solaris 9 Release

The Solaris 9 release includes all components included in Kerberos Components, except for the remote applications.

SEAM 1.0.2 Components

The SEAM 1.0.2 release includes the remote applications. These applications are the only part of SEAM 1.0 that have not been incorporated into the Solaris 9 release. The components for the remote applications are as follows:

Client applications – ftp, rcp, rlogin, rsh, and telnet
Server daemons – ftpd, rlogind, rshd, and telnetd

Kerberos Components in the Solaris 8 Release

The Solaris 8 release includes only the client-side portions of the Kerberos service, so many components are not included. This product enables systems that run the Solaris 8 release to become Kerberos clients without requiring you to install SEAM 1.0.1 separately. To use these capabilities, you must install a KDC that uses either Solaris Easy Access Server 3.0 or the Solaris 8 Admin Pack, the MIT distribution, or Windows 2000. The client-side components are not useful without a configured KDC to distribute tickets. The following components are included in this release:

User programs for obtaining, viewing, and destroying tickets – kinit, klist, and kdestroy.
User program for changing your Kerberos password – kpasswd.
Key table administration utility – ktutil.
Additions to the Pluggable Authentication Module (PAM) – Enables applications to use various authentication mechanisms. PAM can be used to make logins and logouts transparent to the user.
GSS_API plug–ins – Provides Kerberos protocol and cryptographic support.
NFS client and server support.

SEAM 1.0.1 Components

The SEAM 1.0.1 release includes all components of the SEAM 1.0 release that are not already included in the Solaris 8 release. The components are as follows:

Key Distribution Center (KDC) (master):
- Kerberos database administration daemon – kadmind
- Kerberos ticket processing daemon – krb5kdc
Slave KDCs.
Database administration programs – kadmin and kadmin.local.
Database propagation software – kprop.
Remote applications – ftp, rcp, rlogin, rsh, and telnet.
Remote application daemons – ftpd, rlogind, rshd, and telnetd.
Administration utility – kdb5_util.
Graphical Kerberos Administration Tool (gkadmin) – Enables you to administer principals and principal policies. This Java technology-based GUI is an alternative to the kadmin command.
A preconfiguration procedure – Enables you to set the parameters for installing and configuring SEAM 1.0.1, which makes SEAM installation automatic. This procedure is especially useful for multiple installations.
Several libraries.

SEAM 1.0 Components

The SEAM 1.0 release includes all of the items included in Kerberos Components as well as the following:

A utility (gsscred) and a daemon (gssd) – These programs help map UNIX user IDs (UIDs) to principal names. These programs are needed because NFS servers use UNIX UIDs to identify users and not principal names, which are stored in a different format.
The Generic Security Service Application Programming Interface (GSS-API) – Enables applications to use multiple security mechanisms without requiring you to recompile the application every time a new mechanism is added. Because GSS-API is machine-independent, it is appropriate for applications on the Internet. GSS-API provides applications with the ability to include the integrity and privacy security services, as well as authentication.
The RPCSEC_GSS Application Programming Interface (API) – Enables NFS services to use Kerberos authentication. RPCSEC_GSS is a security flavor that provides security services that are independent of the mechanisms being used. RPCSEC_GSS sits on top of the GSS-API layer. Any pluggable GSS_API-based security mechanism can be used by applications that use RPCSEC_GSS.
A preconfiguration procedure – Enables you to set the parameters for installing and configuring SEAM 1.0, which makes installation automatic. This procedure is especially useful for multiple installations.