System Administration Guide: Security Services

Part VI Kerberos Service

This section provides information on the configuration, management and use of the Kerberos service.

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.

  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

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

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:

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:

In addition, the Solaris Kerberos service includes the following:

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:

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

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:

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:

SEAM 1.0 Components

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

Chapter 22 Planning for the Kerberos Service

This chapter should be studied by administrators who are involved in the installation and maintenance of the Kerberos service. The chapter discusses several installation and configuration options that administrators must resolve before they install or configure the service.

This is a list of the topics that a system administrator or other knowledgeable support staff should study:

Why Plan for Kerberos Deployments?

Before you install the Kerberos service, you must resolve several configuration issues. Although changing the configuration after the initial install is not impossible, some changes can be difficult to implement. In addition, some changes require that the KDC be rebuilt, so it is better to consider long-term goals when you plan your Kerberos configuration.

Deploying a Kerberos infrastructure involves such tasks as installing KDCs, creating keys for your hosts, and migrating users. Reconfiguring a Kerberos deployment can be as hard as performing an initial deployment, so plan a deployment carefully to avoid having to re-configure.

Planning Kerberos Realms

A realm is logical network, similar to a domain, that defines a group of systems that are under the same master KDC. As with establishing a DNS domain name, issues such as the realm name, the number and size of each realm, and the relationship of a realm to other realms for cross-realm authentication should be resolved before you configure the Kerberos service.

Realm Names

Realm names can consist of any ASCII string. Usually, the realm name is the same as your DNS domain name, except that the realm name is in uppercase. This convention helps differentiate problems with the Kerberos service from problems with the DNS namespace, while using a name that is familiar. If you do not use DNS or you choose to use a different string, then you can use any string. However, the configuration process requires more work. The use of realm names that follow the standard Internet naming structure is wise.

Number of Realms

The number of realms that your installation requires depends on several factors:

Alignment of Kerberos realms with administrative domains is recommended. Note that a Kerberos V realm can span multiple sub-domains of the DNS domain to which the realm corresponds.

Realm Hierarchy

When you are configuring multiple realms for cross-realm authentication, you need to decide how to tie the realms together. You can establish a hierarchical relationship among the realms, which provides automatic paths to the related domains. Of course, all realms in the hierarchical chain must be configured properly. The automatic paths can ease the administration burden. However, if there are many levels of domains, you might not want to use the default path because it requires too many transactions.

You can also choose to establish the trust relationship directly. A direct trust relationship is most useful when too many levels exist between two hierarchical realms or when no hierarchal relationship exists. The connection must be defined in the /etc/krb5/krb5.conf file on all hosts that use the connection. So, some additional work is required. The direct trust relationship is also referred to as a transitive relationship. For an introduction, see Kerberos Realms. For the configuration procedures for multiple realms, see Configuring Cross-Realm Authentication.

Mapping Host Names Onto Realms

The mapping of host names onto realm names is defined in the domain_realm section of the krb5.conf file. These mappings can be defined for a whole domain and for individual hosts, depending on the requirements.

DNS can also be used to look up information about the KDCs. Using DNS makes it easier to change the information because you will not need to edit the krb5.conf file on all of the clients each time you make a change. See the krb5.conf(4) man page for more information.

As of the Solaris Express Developer Edition 1/08 and the Solaris 10 5/08 releases, Solaris Kerberos clients can interoperate better with Active Directory servers. The Active Directory servers can be configured to provide the realm to host mapping.

Client and Service Principal Names

When you are using the Kerberos service, DNS must be enabled on all hosts. With DNS, the principal should contain the Fully Qualified Domain Name (FQDN) of each host. For example, if the host name is boston, the DNS domain name is example.com, and the realm name is EXAMPLE.COM, then the principal name for the host should be host/boston.example.com@EXAMPLE.COM. The examples in this book require that DNS is configured and use the FQDN for each host.

The Kerberos service canonicalizes host alias names through DNS, and uses the canonicalized form (cname) when constructing the service principal for the associated service. Therefore when creating a service principal, the host name component of service principal names should be the canonical form of the host name of the system hosting the service.

The following is an example of how the Kerberos service canonicalizes host name. If a user runs the command “ssh alpha.example.com” where alpha.example.com is a DNS host alias for the cname beta.example.com. When ssh calls Kerberos and requests a host service ticket for alpha.example.com, the Kerberos service canonicalizes alpha.example.com to beta.example.com and requests a ticket for the service principal “host/beta.example.com” from the KDC.

For the principal names that include the FQDN of a host, it is important to match the string that describes the DNS domain name in the /etc/resolv.conf file. The Kerberos service requires that the DNS domain name be in lowercase letters when you are specifying the FQDN for a principal. The DNS domain name can include uppercase and lowercase letters, but only use lowercase letters when you are creating a host principal. For example, it doesn't matter if the DNS domain name is example.com, Example.COM, or any other variation. The principal name for the host would still be host/boston.example.com@EXAMPLE.COM.

In addition, the Service Management Facility has been configured so that many of the daemons or commands do not start if the DNS client service is not running. The kdb5_util, kadmind, and kpropd daemons, as well as the kprop command all are configured to depend on the DNS service. To fully utilize the features available using the Kerberos service and SMF, you must enable the DNS client service on all hosts.

Ports for the KDC and Admin Services

By default, port 88 and port 750 are used for the KDC, and port 749 is used for the KDC administration daemon. Different port numbers can be used. However, if you change the port numbers, then the /etc/services and /etc/krb5/krb5.conf files must be changed on every client. In addition to these files, the /etc/krb5/kdc.conf file on each KDC must be updated.

The Number of Slave KDCs

Slave KDCs generate credentials for clients just as the master KDC does. Slave KDCs provide backup if the master becomes unavailable. Each realm should have at least one slave KDC. Additional slave KDCs might be required, depending on these factors:

It is possible to add too many slave KDCs. Remember that the KDC database must be propagated to each server, so the more KDC servers that are installed, the longer it can take to get the data updated throughout the realm. Also, because each slave retains a copy of the KDC database, more slaves increase the risk of a security breach.

In addition, one or more slave KDCs can easily be configured to be swapped with the master KDC. The advantage of configuring at least one slave KDC in this way is that if the master KDC fails for any reason, you will have a system preconfigured that will be easy to swap as the master KDC. For instructions on how to configure a swappable slave KDC, see Swapping a Master KDC and a Slave KDC.

Mapping GSS Credentials to UNIX Credentials

The Kerberos service provides a default mapping of GSS credential names to UNIX user IDs (UIDs) for GSS applications that require this mapping, such as NFS. GSS credential names are equivalent to Kerberos principal names when using the Kerberos service. The default mapping algorithm is to take a one component Kerberos principal name and use that component, which is the primary name of the principal, to look up the UID. The look up occurs in the default realm or any realm that is allowed by using the auth_to_local_realm parameter in /etc/krb5/krb5.conf. For example, the user principal name bob@EXAMPLE.COM is mapped to the UID of the UNIX user named bob using the password table. The user principal name bob/admin@EXAMPLE.COM would not be mapped, because the principal name includes an instance component of admin. If the default mappings for the user credentials are sufficient, the GSS credential table does not need to be populated. In past releases, populating the GSS credential table was required to get the NFS service to work. If the default mapping is not sufficient, for example if you want to map a principal name which contains an instance component, then other methods should be used. For more information see:

Automatic User Migration to a Kerberos Realm

UNIX users who do not have valid user accounts in the default Kerberos realm can be automatically migrated using the PAM framework. Specifically, the pam_krb5_migrate module would be used in the authentication stack of the PAM service. Services would be setup up so that whenever a user, who does not have a Kerberos principal, performs a successful log in to a system using their password, a Kerberos principal would be automatically created for that user. The new principal password would be the same as the UNIX password. See How to Configure Automatic Migration of Users in a Kerberos Realm for instructions on how to use the pam_krb5_migrate module.

Which Database Propagation System to Use

The database that is stored on the master KDC must be regularly propagated to the slave KDCs. You can configure the propagation of the database to be incremental. The incremental process propagates only updated information to the slave KDCs, rather than the entire database. For more information about database propagation, see Administering the Kerberos Database.

If you do not use incremental propagation, one of the first issues to resolve is how often to update the slave KDCs. The need to have up-to-date information that is available to all clients must be weighed against the amount of time it takes to complete the update.

In large installations with many KDCs in one realm, one or more slaves can propagate the data so that the process is done in parallel. This strategy reduces the amount of time that the update takes, but it also increases the level of complexity in administering the realm. For a complete description of this strategy, see Setting Up Parallel Propagation.

Clock Synchronization Within a Realm

All hosts that participate in the Kerberos authentication system must have their internal clocks synchronized within a specified maximum amount of time. Known as clock skew, this feature provides another Kerberos security check. If the clock skew is exceeded between any of the participating hosts, requests are rejected.

One way to synchronize all the clocks is to use the Network Time Protocol (NTP) software. See Synchronizing Clocks Between KDCs and Kerberos Clients for more information. Other ways of synchronizing the clocks are available, so the use of NTP is not required. However, some form of synchronization should be used to prevent access failures because of clock skew.

Client Configuration Options

A new feature in the Solaris 10 release is the kclient configuration utility. The utility can be run in interactive mode or noninteractive mode. In interactive mode, the user is prompted for Kerberos-specific parameter values, which allows the user to make changes to the existing installation when configuring the client. In noninteractive mode, a file with previously set parameter values is used. Also, command-line options can be used in the noninteractive mode. Both interactive and noninteractive modes require less steps than the manual process, which should make the process quicker and less prone to error.

In the Solaris Express Developer Edition 1/08 release, changes were made to allow for a zero-configuration Kerberos client. If these rules are followed in your environment then no explicit configuration procedure is necessary for a Solaris Kerberos client:

In some cases it may be better to explicitly configure the Kerberos client:

See Configuring Kerberos Clients for a description of all the client configuration processes.

Improving Client Login Security

In the Solaris 10 11/06 release, on login a client, using the pam_krb5 module, verifies that the KDC that issued the latest TGT, is the same KDC that issued the client host principal that is stored in /etc/krb5/krb5.keytab. The pam_krb5 module verifies the KDC when the module is configured in the authentication stack. For some configurations, like DHCP clients that do not store a client host principal, this check needs to be disabled. To turn off this check, you must set the verify_ap_req_nofail option in the krb5.conf file to be false. See How to Disable Verification of the Ticket Granting Ticket (TGT) for more information.

KDC Configuration Options

Starting in the the Solaris Express Developer Edition 1/08 release, there are several ways to configure a KDC. The simplest versions use the kdcmgr utility to configure the KDC automatically or interactively. The automatic version requires that you use command line options to define the configuration parameters. This method is especially useful for scripts. The interactive version prompts you for all information that is needed. See Table 23–1 for pointers to the instructions for using this command.

In addition, starting in the Solaris Express Developer Edition 1/08 release, support for using LDAP to manage the database files for Kerberos has been added. See How to Configure a KDC to Use an LDAP Data Server for instructions. Using LDAP simplifies administration for sites that require better coordination between the Solaris Kerberos databases and their existing DS setup.

Kerberos Encryption Types

An encryption type is an identifier that specifies the encryption algorithm, encryption mode, and hash algorithms used in the Kerberos service. The keys in the Kerberos service have an associated encryption type to identify the cryptographic algorithm and mode to be used when the service performs cryptographic operations with the key. Here are the supported encryption types:


Note –

In releases prior to Solaris 10 8/07 release, the aes256-cts-hmac-sha1-96 encryption type can be used with the Kerberos service if the unbundled Strong Cryptographic packages are installed.


If you want to change the encryption type, you should do so when creating a new principal database. Because of the interaction between the KDC, the server, and the client, changing the encryption type on an existing database is difficult. Leave these parameters unset unless you are re-creating the database. Refer to Using Kerberos Encryption Types for more information.


Note –

If you have a master KDC installed that is not running the Solaris 10 release, the slave KDCs must be upgraded to the Solaris 10 release before you upgrade the master KDC. A Solaris 10 master KDC will use the new encryption types, which an older slave will not be able to handle.


Online Help URL in the Graphical Kerberos Administration Tool

The online help URL is used by the Graphical Kerberos Administration Tool, gkadmin, so the URL should be defined properly to enable the “Help Contents“ menu to work. The HTML version of this manual can be installed on any appropriate server. Alternately, you can decide to use the collections at http://docs.sun.com.

The URL is specified in the krb5.conf file when configuring a host to use the Kerberos service. The URL should point to the section titled “Graphical Kerberos Administration Tool” in the “Administering Principals and Policies (Tasks)” chapter in this book. You can choose another HTML page, if another location is more appropriate.

Chapter 23 Configuring the Kerberos Service (Tasks)

This chapter provides configuration procedures for KDC servers, network application servers, NFS servers, and Kerberos clients. Many of these procedures require superuser access, so they should be used by system administrators or advanced users. Cross-realm configuration procedures and other topics related to KDC servers are also covered.

The following topics are covered.

Configuring the Kerberos Service (Task Map)

Parts of the configuration process depend on other parts and must be done in a specific order. These procedures often establish services that are required to use the Kerberos service. Other procedures are not dependent on any order, and can be done when appropriate. The following task map shows a suggested order for a Kerberos installation.

Task 

Description 

For Instructions 

1. Plan for your Kerberos installation. 

Lets you resolve configuration issues before you start the software configuration process. Planning ahead saves you time and other resources in the long run. 

Chapter 22, Planning for the Kerberos Service

2. (Optional) Install NTP. 

Configures the Network Time Protocol (NTP) software, or another clock synchronization protocol. In order for the Kerberos service to work properly, the clocks on all systems in the realm must be synchronized. 

Synchronizing Clocks Between KDCs and Kerberos Clients

3. Configure the KDC servers. 

Configures and builds the master KDC and the slave KDC servers and the KDC database for a realm. 

Configuring KDC Servers

4. (Optional) Increase security on the KDC servers. 

Prevents security breaches on the KDC servers. 

How to Restrict Access to KDC Servers

5. (Optional) Configure swappable KDC servers. 

Makes the task of swapping the master KDC and a slave KDC easier. 

How to Configure a Swappable Slave KDC

Configuring Additional Kerberos Services (Task Map)

Once the required steps have been completed, the following procedures can be used, when appropriate.

Task 

Description 

For Instructions 

Configure cross-realm authentication. 

Enables communications from one realm to another realm. 

Configuring Cross-Realm Authentication

Configure Kerberos application servers. 

Enables a server to support services such as ftp, telnet, and rsh using Kerberos authentication.

Configuring Kerberos Network Application Servers

Configure Kerberos clients. 

Enables a client to use Kerberos services. 

Configuring Kerberos Clients

Configure Kerberos NFS server. 

Enables a server to share a file system that requires Kerberos authentication. 

Configuring Kerberos NFS Servers

Increase security on an application server. 

Increases security on an application server by restricting access to authenticated transactions only. 

How to Enable Only Kerberized Applications

Configuring KDC Servers

After you install the Kerberos software, you must configure the KDC servers. Configuring a master KDC and at least one slave KDC provides the service that issues credentials. These credentials are the basis for the Kerberos service, so the KDCs must be installed before you attempt other tasks.

The most significant difference between a master KDC and a slave KDC is that only the master KDC can handle database administration requests. For instance, changing a password or adding a new principal must be done on the master KDC. These changes can then be propagated to the slave KDCs. Both the slave KDC and master KDC generate credentials. This feature provides redundancy in case the master KDC cannot respond.

Table 23–1 Configuring KDC Servers (Task Map)

Task 

Description 

For Instructions 

Configuring a Master KDC 

Configures and builds the master KDC server and database for a realm using an automatic process, which is good for scripts. 

How to Automatically Configure a Master KDC

 

Configures and builds the master KDC server and database for a realm using an interactive process, which is sufficient for most installations 

How to Interactively Configure a Master KDC

 

Configures and builds the master KDC server and database for a realm using a manual process, which is needed for more complex installations 

How to Manually Configure a Master KDC

 

Configures and builds the master KDC server and database for a realm using a manual process and using LDAP for the KDC 

How to Configure a KDC to Use an LDAP Data Server

Configuring a slave KDC server. 

Configures and builds a slave KDC server for a realm using an automatic process, which is good for scripts 

How to Automatically Configure a Slave KDC

 

Configures and builds a slave KDC server for a realm using an interactive process, which is sufficient for most installations 

How to Interactively Configure a Slave KDC

 

Configures and builds a slave KDC server for a realm using a manual process, which is needed for more complex installations 

How to Manually Configure a Slave KDC

Refreshing principal keys on a KDC server. 

Updates the session key on a KDC server to use new encryption types. 

How to Refresh the Ticket Granting Service Keys on a Master Server

ProcedureHow to Automatically Configure a Master KDC

Starting with the Solaris Express Developer Edition 1/08 release, a master KDC can be automatically configured by using the following procedure.

  1. Become superuser.

  2. Create the KDC.

    Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.


    kdc1# kdcmgr -a kws/admin -r EXAMPLE.COM create master
    
    Starting server setup
    ---------------------------------------
    
    Setting up /etc/krb5/kdc.conf
    
    Setting up /etc/krb5/krb5.conf
    
    Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM', 
    master key name 'K/M@EXAMPLE.COM' 
    You will be prompted for the database Master Password. 
    It is important that you NOT FORGET this password. 
    Enter KDC database master key: <Type the password>
    Re-enter KDC database master key to verify: <Type it again>
    
    Authenticating as principal root/admin@EXAMPLE.COM with password. 
    WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy 
    Enter password for principal "kws/admin@EXAMPLE.COM": <Type the password>
    Re-enter password for principal "kws/admin@EXAMPLE.COM": <Type it again>
    Principal "kws/admin@EXAMPLE.COM" created. 
    
    Setting up /etc/krb5/kadm5.acl. 
    
    --------------------------------------------------- 
    Setup COMPLETE. 
    
    kdc1#

ProcedureHow to Interactively Configure a Master KDC

Starting with the Solaris Express Developer Edition 1/08 release, a master KDC can be interactively configured by using the following procedure.

  1. Become superuser.

  2. Create the KDC.

    Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.


    kdc1# kdcmgr create master
    
    Starting server setup
    ---------------------------------------
    
    Enter the Kerberos realm: EXAMPLE.COM
    
    Setting up /etc/krb5/kdc.conf
    
    Setting up /etc/krb5/krb5.conf
    
    Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM', 
    master key name 'K/M@EXAMPLE.COM' 
    You will be prompted for the database Master Password. 
    It is important that you NOT FORGET this password. 
    Enter KDC database master key: <Type the password>
    Re-enter KDC database master key to verify: <Type it again>
    
    Enter the krb5 administrative principal to be created: kws/admin
    
    Authenticating as principal root/admin@EXAMPLE.COM with password. 
    WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy 
    Enter password for principal "kws/admin@EXAMPLE.COM": <Type the password>
    Re-enter password for principal "kws/admin@EXAMPLE.COM": <Type it again>
    Principal "kws/admin@EXAMPLE.COM" created. 
    
    Setting up /etc/krb5/kadm5.acl. 
    
    --------------------------------------------------- 
    Setup COMPLETE. 
    
    kdc1#

Example 23–1 Displaying the Status of a KDC Server

The kdcmgr status command can be used to display information about either a master or a slave KDC server.


ProcedureHow to Manually Configure a Master KDC

In this procedure, incremental propagation is configured. In addition, the following configuration parameters are used:

Before You Begin

This procedure requires that the host is configured to use DNS. For specific naming instructions if this master is to be swappable, see Swapping a Master KDC and a Slave KDC.

  1. Become superuser on the master KDC.

  2. Edit the Kerberos configuration file (krb5.conf).

    You need to change the realm names and the names of the servers. See the krb5.conf(4) man page for a full description of this file.


    kdc1 # cat /etc/krb5/krb5.conf
    [libdefaults]
            default_realm = EXAMPLE.COM
    
    [realms]
            EXAMPLE.COM = {
            kdc = kdc1.example.com
            admin_server = kdc1.example.com
            }
    
    [domain_realm]
            .example.com = EXAMPLE.COM
    #
    # if the domain name and realm name are equivalent, 
    # this entry is not needed
    #
    [logging]
            default = FILE:/var/krb5/kdc.log
            kdc = FILE:/var/krb5/kdc.log
    
    [appdefaults]
        gkadmin = {
            help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
            }

    In this example, the lines for default_realm, kdc, admin_server, and all domain_realm entries were changed. In addition, the line that defines the help_url was edited.


    Note –

    If you want to restrict the encryption types, you can set the default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.


  3. Edit the KDC configuration file (kdc.conf).

    You need to change the realm name. See the kdc.conf(4) man page for a full description of this file.


    kdc1 # cat /etc/krb5/kdc.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM = {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
                    sunw_dbprop_master_ulogsize = 1000
                    }

    In this example, the realm name definition in the realms section was changed. Also, in the realms section, lines to enable incremental propagation and to select the number of updates the KDC master keeps in the log were added.


    Note –

    If you want to restrict the encryption types, you can set the permitted_enctypes, supported_enctypes, or master_key_type lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.


  4. Create the KDC database by using the kdb5_util command.

    The kdb5_util command creates the KDC database. Also, when used with the -s option, this command creates a stash file that is used to authenticate the KDC to itself before the kadmind and krb5kdc daemons are started.


    kdc1 # /usr/sbin/kdb5_util create -s
    Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM'
    master key name 'K/M@EXAMPLE.COM'
    You will be prompted for the database Master Password.
    It is important that you NOT FORGET this password.
    Enter KDC database master key: <Type the key>
    Re-enter KDC database master key to verify: <Type it again>
    
  5. Edit the Kerberos access control list file (kadm5.acl).

    Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC.


    kws/admin@EXAMPLE.COM   *

    The entry gives the kws/admin principal in the EXAMPLE.COM realm the ability to modify principals or policies in the KDC. The default installation includes an asterisk (*) to match all admin principals. This default could be a security risk, so it is more secure to include a list of all of the admin principals. See the kadm5.acl(4) man page for more information.

  6. Start the kadmin.local command and add principals.

    The next substeps create principals that are used by the Kerberos service.


    kdc1 # /usr/sbin/kadmin.local
    kadmin.local: 
    1. Add administration principals to the database.

      You can add as many admin principals as you need. You must add at least one admin principal to complete the KDC configuration process. For this example, a kws/admin principal is added. You can substitute an appropriate principal name instead of “kws.”


      kadmin.local: addprinc kws/admin
      Enter password for principal kws/admin@EXAMPLE.COM:<Type the password>
      Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again>
      Principal "kws/admin@EXAMPLE.COM" created.
      kadmin.local: 
    2. Create the kiprop principals.

      The kiprop principal is used to authorize updates from the master KDC.


      kadmin.local: addprinc -randkey kiprop/kdc1.example.com
      Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
      kadmin.local:
    3. Quit kadmin.local.

      You have added all of the required principals for the next steps.


      kadmin.local: quit
      
  7. Start the Kerberos daemons.


    kdc1 # svcadm enable -r network/security/krb5kdc
    kdc1 # svcadm enable -r network/security/kadmin
    
  8. Start kadmin and add more principals.

    At this point, you can add principals by using the Graphical Kerberos Administration Tool. To do so, you must log in with one of the admin principal names that you created earlier in this procedure. However, the following command-line example is shown for simplicity.


    kdc1 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Create the master KDC host principal.

      The host principal is used by Kerberized applications, such as kprop to propagate changes to the slave KDCs. This principal is also used to provide secure remote access to the KDC server using applications, like ssh. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: addprinc -randkey host/kdc1.example.com
      Principal "host/kdc1.example.com@EXAMPLE.COM" created.
      kadmin: 
    2. (Optional) Create the kclient principal.

      This principal is used by the kclient utility during the installation of a Kerberos client. If you do not plan on using this utility, then you do not need to add the principal. The users of the kclient utility need to use this password.


      kadmin: addprinc clntconfig/admin
      Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password>
      Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again>
      Principal "clntconfig/admin@EXAMPLE.COM" created.
      kadmin: 
    3. Add the master KDC's host principal to the master KDC's keytab file.

      Adding the host principal to the keytab file allows this principal to be used by application servers, like sshd, automatically.


      kadmin: ktadd host/kdc1.example.com
      Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    4. Quit kadmin.


      kadmin: quit
      
  9. (Optional) Synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.

    Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  10. Configure Slave KDCs.

    To provide redundancy, make sure to install at least one slave KDC. See How to Manually Configure a Slave KDC for specific instructions.

ProcedureHow to Configure a KDC to Use an LDAP Data Server

Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a KDC can be configured to use an LDAP data server by using the following procedure.

In this procedure, the following configuration parameters are used:

Before You Begin

This procedure also requires that the host is configured to use DNS. For better performance, install the KDC and the LDAP Directory Service on the same server. In addition, a directory server should be running. The procedure below works with servers using the Sun JavaTM Directory Server Enterprise Edition release.

  1. Become superuser on the KDC.

  2. Configure the master KDC to use SSL to reach the directory server.

    The following steps configure a Solaris Express Developer Release KDC to use the Directory Server 6.1 self-signed certificate. If the certificate has expired, follow the instructions for renewing a certificate in To Manage Self-Signed Certificates in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

    1. On the directory server, export the self-signed directory server certificate.


      # /export/sun-ds6.1/ds6/bin/dsadm show-cert -F der /export/sun-ds6.1/directory2 \
              defaultCert > /tmp/defaultCert.cert.der
      
    2. On the master KDC, import the directory server certificate.


      # pktool setpin keystore=nss dir=/var/ldap
      # chmod a+r /var/ldap/*.db
      # pktool import keystore=nss objtype=cert trust="CT" infile=/tmp/defaultCert.certutil.der \
              label=defaultCert dir=/var/ldap
      
    3. On the master KDC, test that SSL is working.

      This example assumes that the cn=directory managerentry has administration privileges.


      /usr/bin/ldapsearch -Z -P /var/ldap -D "cn=directory manager" \
              -h dsserver.example.com -b "" -s base objectclass='*'
      Subject:
          "CN=dsserver.example.com,CN=636,CN=Directory Server,O=Example Corporation

      Note that the CN=dsserver.example.com entry should include the fully qualified host name, not a short version.

  3. Populate the LDAP directory, if necessary.

  4. Add the Solaris Kerberos schema to the existing schema.


    # ldapmodify -h dsserver.example.com -D "cn=directory manager" -f /usr/share/lib/ldif/kerberos.ldif
    
  5. Create the Kerberos container in the LDAP directory.

    Add the following entries to the krb5.conf file.

    1. Define the database type.

      Add an entry to define the database_moduleto the realms section.


      database_module = LDAP
      
    2. Define the database module.


      [dbmodules]
          LDAP = {
              ldap_kerberos_container_dn = "cn=krbcontainer,dc=example,dc=com"
              db_library = kldap
              ldap_kdc_dn = "cn=kdc service,ou=profile,dc=example,dc=com"
              ldap_kadmind_dn = "cn=kadmin service,ou=profile,dc=example,dc=com"
              ldap_cert_path = /var/ldap
              ldap_servers = ldaps://dsserver.example.com
          }
      
    3. Create the KDC in the LDAP directory.

      This command creates krbcontainer and several other objects. It also creates a /var/krb5/.k5.EXAMPLE.COM master key stash file.


      # kdb5_ldap_util -D "cn=directory manager" create -P abcd1234 -r EXAMPLE.COM -s
  6. Stash the KDC bind Distinguished Name (DN) passwords.

    These passwords are used by the KDC when it binds to the DS. The KDC uses different roles depending on the type of access the KDC is using.


    # kdb5_ldap_util stashsrvpw "cn=kdc service,ou=profile,dc=example,dc=com"
    # kdb5_ldap_util stashsrvpw "cn=kadmin service,ou=profile,dc=example,dc=com"
    
  7. Add KDC service roles.

    1. Create a kdc_roles.ldif file with contents like this:


      dn: cn=kdc service,ou=profile,dc=example,dc=com
      cn: kdc service
      sn: kdc service
      objectclass: top
      objectclass: person
      userpassword: test123
      
      dn: cn=kadmin service,ou=profile,dc=example,dc=com
      cn: kadmin service
      sn: kadmin service
      objectclass: top
      objectclass: person
      userpassword: test123
    2. Create the role entries in the LDAP directory


      # ldapmodify -a -h dsserver.example.com -D "cn=directory manager" -f kdc_roles.ldif
      
  8. Set the ACLs for the KDC-related roles.


    # cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager" 
    # Set kadmin ACL for everything under krbcontainer.
    dn: cn=krbcontainer,dc=example,dc=com
    changetype: modify
    add: aci
    aci: (target="ldap:///cn=krbcontainer,dc=example,dc=com")(targetattr="krb*")(version 3.0;\
          acl kadmin_ACL; allow (all)\
          userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";)
    
    # Set kadmin ACL for everything under the people subtree if there are
    # mix-in entries for krb princs:
    dn: ou=people,dc=example,dc=com
    changetype: modify
    add: aci
    aci: (target="ldap:///ou=people,dc=example,dc=com")(targetattr="krb*")(version 3.0;\
          acl kadmin_ACL; allow (all)\
          userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";)
    EOF
  9. Edit the Kerberos configuration file (krb5.conf).

    You need to change the realm names and the names of the servers. See the krb5.conf(4) man page for a full description of this file.


    kdc1 # cat /etc/krb5/krb5.conf
    [libdefaults]
            default_realm = EXAMPLE.COM
    
    [realms]
            EXAMPLE.COM = {
            kdc = kdc1.example.com
            admin_server = kdc1.example.com
            }
    
    [domain_realm]
            .example.com = EXAMPLE.COM
    #
    # if the domain name and realm name are equivalent, 
    # this entry is not needed
    #
    [logging]
            default = FILE:/var/krb5/kdc.log
            kdc = FILE:/var/krb5/kdc.log
    
    [appdefaults]
        gkadmin = {
            help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
            }

    In this example, the lines for default_realm, kdc, admin_server, and all domain_realm entries were changed. In addition, the line that defines the help_url was edited.


    Note –

    If you want to restrict the encryption types, you can set the default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.


  10. Edit the KDC configuration file (kdc.conf).

    You need to change the realm name. See the kdc.conf(4) man page for a full description of this file.


    kdc1 # cat /etc/krb5/kdc.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM = {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
                    sunw_dbprop_master_ulogsize = 1000
                    }

    In this example, the realm name definition in the realms section was changed. Also, in the realms section, lines to enable incremental propagation and to select the number of updates the KDC master keeps in the log were added.


    Note –

    If you want to restrict the encryption types, you can set the permitted_enctypes, supported_enctypes, or master_key_type lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.


  11. Edit the Kerberos access control list file (kadm5.acl).

    Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC.


    kws/admin@EXAMPLE.COM   *

    The entry gives the kws/admin principal in the EXAMPLE.COM realm the ability to modify principals or policies in the KDC. The default installation includes an asterisk (*) to match all admin principals. This default could be a security risk, so it is more secure to include a list of all of the admin principals. See the kadm5.acl(4) man page for more information.

  12. Start the kadmin.local command and add principals.

    The next substeps create principals that are used by the Kerberos service.


    kdc1 # /usr/sbin/kadmin.local
    kadmin.local: 
    1. Add administration principals to the database.

      You can add as many admin principals as you need. You must add at least one admin principal to complete the KDC configuration process. For this example, a kws/admin principal is added. You can substitute an appropriate principal name instead of “kws.”


      kadmin.local: addprinc kws/admin
      Enter password for principal kws/admin@EXAMPLE.COM:<Type the password>
      Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again>
      Principal "kws/admin@EXAMPLE.COM" created.
      kadmin.local: 
    2. Quit kadmin.local.

      You have added all of the required principals for the next steps.


      kadmin.local: quit
      
  13. Start the Kerberos daemons.


    kdc1 # svcadm enable -r network/security/krb5kdc
    kdc1 # svcadm enable -r network/security/kadmin
    
  14. Start kadmin and add more principals.

    At this point, you can add principals by using the Graphical Kerberos Administration Tool. To do so, you must log in with one of the admin principal names that you created earlier in this procedure. However, the following command-line example is shown for simplicity.


    kdc1 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Create the master KDC host principal.

      The host principal is used by Kerberized applications, such as klist and kprop. Solaris 10 clients use this principal when mounting an authenticated NFS file system. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: addprinc -randkey host/kdc1.example.com
      Principal "host/kdc1.example.com@EXAMPLE.COM" created.
      kadmin: 
    2. (Optional) Create the kclient principal.

      This principal is used by the kclient utility during the installation of a Kerberos client. If you do not plan on using this utility, then you do not need to add the principal. The users of the kclient utility need to use this password.


      kadmin: addprinc clntconfig/admin
      Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password>
      Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again>
      Principal "clntconfig/admin@EXAMPLE.COM" created.
      kadmin: 
    3. Add the master KDC's host principal to the master KDC's keytab file.

      Adding the host principal to the keytab file allows this principal to be used automatically.


      kadmin: ktadd host/kdc1.example.com
      Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    4. Quit kadmin.


      kadmin: quit
      
  15. (Optional) Synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.

    Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  16. Configure Slave KDCs.

    To provide redundancy, make sure to install at least one slave KDC. See How to Manually Configure a Slave KDC for specific instructions.

ProcedureHow to Automatically Configure a Slave KDC

Starting with the Solaris Express Developer Edition 1/08 release, a slave KDC can be automatically configured by using the following procedure.

  1. Become superuser.

  2. Create the KDC.

    Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.


    kdc2# kdcmgr -a kws/admin -r EXAMPLE.COM create -m kdc1 slave
    
    Starting server setup
    ---------------------------------------
    
    Setting up /etc/krb5/kdc.conf
    
    Setting up /etc/krb5/krb5.conf
    Obtaining TGT for kws/admin ... 
    Password for kws/admin@EXAMPLE.COM: <Type the password>
    
    Setting up /etc/krb5/kadm5.acl. 
    
    Setting up /etc/krb5/kpropd.acl. 
    
    Waiting for database from master... 
    Waiting for database from master... 
    Waiting for database from master... 
    kdb5_util: Cannot find/read stored master key while reading master key 
    kdb5_util: Warning: proceeding without master key 
    Enter KDC database master key: <Type the password>
    
    --------------------------------------------------- 
    Setup COMPLETE. 
    
    kdc2#

ProcedureHow to Interactively Configure a Slave KDC

Starting with the Solaris Express Developer Edition 1/08 release, a slave KDC can be interactively configured by using the following procedure.

  1. Become superuser.

  2. Create the KDC.

    Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.


    kdc1# kdcmgr create slave
    
    Starting server setup
    ---------------------------------------
    
    Enter the Kerberos realm: EXAMPLE.COM
    What is the master KDC's host name?: kdc1
    
    Setting up /etc/krb5/kdc.conf
    
    Setting up /etc/krb5/krb5.conf
    Obtaining TGT for kws/admin ... 
    Password for kws/admin@EXAMPLE.COM: <Type the password>
    
    Setting up /etc/krb5/kadm5.acl. 
    
    Setting up /etc/krb5/kpropd.acl. 
    
    Waiting for database from master... 
    Waiting for database from master... 
    Waiting for database from master... 
    kdb5_util: Cannot find/read stored master key while reading master key 
    kdb5_util: Warning: proceeding without master key 
    Enter KDC database master key: <Type the password>
    
    --------------------------------------------------- 
    Setup COMPLETE. 
    
    kdc2#

ProcedureHow to Manually Configure a Slave KDC

In this procedure, a new slave KDC named kdc2 is configured. Also, incremental propagation is configured. This procedure uses the following configuration parameters:

Before You Begin

The master KDC must be configured. For specific instructions if this slave is to be swappable, see Swapping a Master KDC and a Slave KDC.

  1. On the master KDC, become superuser.

  2. On the master KDC, start kadmin.

    You must log in with one of the admin principal names that you created when you configured the master KDC.


    kdc1 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. On the master KDC, add slave host principals to the database, if not already done.

      For the slave to function, it must have a host principal. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: addprinc -randkey host/kdc2.example.com
      Principal "host/kdc2.example.com@EXAMPLE.COM" created.
      kadmin: 
    2. On the master KDC, create the kiprop principal.

      The kiprop principal is used to authorize incremental propagation from the master KDC.


      kadmin: addprinc -randkey kiprop/kdc2.example.com
      Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.
      kadmin:
    3. Quit kadmin.


      kadmin: quit
      
  3. On the master KDC, edit the Kerberos configuration file (krb5.conf).

    You need to add an entry for each slave. See the krb5.conf(4) man page for a full description of this file.


    kdc1 # cat /etc/krb5/krb5.conf
     .
     .
    [realms]
                    EXAMPLE.COM = {
                    kdc = kdc1.example.com
                    kdc = kdc2.example.com
                    admin_server = kdc1.example.com
            }
  4. On the master KDC, add an kiprop entry to kadm5.acl.

    This entry allows the master KDC to receive requests for incremental propagation for the kdc2 server.


    kdc1 # cat /etc/krb5/kadm5.acl
    */admin@EXAMPLE.COM *
    kiprop/kdc2.example.com@EXAMPLE.COM p
    
  5. On the master KDC, restart kadmind to use the new entries in the kadm5.acl file.


    kdc1 # svcadm restart network/security/kadmin
    
  6. On all slave KDCs, copy the KDC administration files from the master KDC server.

    This step needs to be followed on all slave KDCs, because the master KDC server has updated information that each KDC server needs. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master KDC:

    • /etc/krb5/krb5.conf

    • /etc/krb5/kdc.conf

  7. On all slave KDCs, add an entry for the master KDC and each slave KDC into the database propagation configuration file, kpropd.acl.

    This information needs to be updated on all slave KDC servers.


    kdc2 # cat /etc/krb5/kpropd.acl
    host/kdc1.example.com@EXAMPLE.COM
    host/kdc2.example.com@EXAMPLE.COM
  8. On all slave KDCs, make sure that the Kerberos access control list file, kadm5.acl, is not populated.

    An unmodified kadm5.acl file would look like:


    kdc2 # cat /etc/krb5/kadm5.acl
    */admin@___default_realm___ *

    If the file has kiprop entries, remove them.

  9. On the new slave, change an entry in kdc.conf.

    Replace the sunw_dbprop_master_ulogsize entry with an entry defining sunw_dbprop_slave_poll. The entry sets the poll time to 2 minutes.


    kdc1 # cat /etc/krb5/kdc.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM= {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
                    sunw_dbprop_slave_poll = 2m
            }
  10. On the new slave, start the kadmin command.

    You must log in with one of the admin principal names that you created when you configured the master KDC.


    kdc2 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Add the slave's host principal to the slave's keytab file by using kadmin.

      This entry allows kprop and other Kerberized applications to function. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: ktadd host/kdc2.example.com
      Entry for principal host/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc2.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc2.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc2.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    2. Add the kiprop principal to the slave KDC's keytab file.

      Adding the kiprop principal to the krb5.keytab file allows the kpropd command to authenticate itself when incremental propagation is started.


      kadmin: ktadd kiprop/kdc2.example.com
      Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    3. Quit kadmin.


      kadmin: quit
      
  11. On the new slave, start the Kerberos propagation daemon.


    kdc2 # svcadm enable network/security/krb5_prop
    
  12. On the new slave, create a stash file by using kdb5_util.


    kdc2 # /usr/sbin/kdb5_util stash
    kdb5_util: Cannot find/read stored master key while reading master key
    kdb5_util: Warning: proceeding without master key
    
    Enter KDC database master key: <Type the key>
    
  13. (Optional) On the new slave KDC, synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.

    Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  14. On the new slave, start the KDC daemon (krb5kdc).


    kdc2 # svcadm enable network/security/krb5kdc
    

ProcedureHow to Refresh the Ticket Granting Service Keys on a Master Server

When the Ticket Granting Service (TGS) principal only has a DES key, which is the case for Solaris KDC servers created prior to the Solaris 10 release, the key restricts the encryption type of the Ticket Granting Ticket (TGT) session key to DES. If a Solaris KDC is updated to Solaris 10 which supports additional, stronger encryption types, the administrator may expect that stronger encryption will be used for all session keys generated by the KDC. However if the existing TGS principal does not have it's keys refreshed to include the new encryption types, then the TGT session key will be continue to be limited to DES. The following procedure refreshes the key so that additional encryption types may be used.

  1. Refresh the TGS service principal key.


    kdc1 % /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM
    

Example 23–2 Refreshing the Principal Keys from a Master Server

If you are logged on to the KDC master as root, you can refresh the TGS service principal with the following command:


kdc1 # kadmin.local -q 'cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM'

Configuring Cross-Realm Authentication

You have several ways of linking realms together so that users in one realm can be authenticated in another realm. Cross-realm authentication is accomplished by establishing a secret key that is shared between the two realms. The relationship of the realms can be either hierarchal or directional (see Realm Hierarchy).

ProcedureHow to Establish Hierarchical Cross-Realm Authentication

The example in this procedure uses two realms, ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

Before You Begin

The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.

  1. Become superuser on the first master KDC.

  2. Create ticket-granting ticket service principals for the two realms.

    You must log in with one of the admin principal names that was created when you configured the master KDC.


    # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM
    Enter password for principal krgtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM: <Type password>
    kadmin: addprinc krbtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
    Enter password for principal krgtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type password>
    kadmin: quit
    

    Note –

    The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM must be the same in both realms.


  3. Add entries to the Kerberos configuration file (krb5.conf) to define domain names for every realm.


    # cat /etc/krb5/krb5.conf
    [libdefaults]
     .
     .
    [domain_realm]
            .eng.east.example.com = ENG.EAST.EXAMPLE.COM
            .east.example.com = EAST.EXAMPLE.COM
    

    In this example, domain names for the ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM realms are defined. It is important to include the subdomain first, because the file is searched top down.

  4. Copy the Kerberos configuration file to all clients in this realm.

    For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.

  5. Repeat all of these steps in the second realm.

ProcedureHow to Establish Direct Cross-Realm Authentication

The example in this procedure uses two realms, ENG.EAST.EXAMPLE.COM and SALES.WEST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

Before You Begin

The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.

  1. Become superuser on one of the master KDC servers.

  2. Create ticket-granting ticket service principals for the two realms.

    You must log in with one of the admin principal names that was created when you configured the master KDC.


    # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM
    Enter password for principal 
      krgtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM: <Type the password>
    kadmin: addprinc krbtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
    Enter password for principal 
      krgtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type the password>
    kadmin: quit
    

    Note –

    The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM must be the same in both realms.


  3. Add entries in the Kerberos configuration file to define the direct path to the remote realm.

    This example shows the clients in the ENG.EAST.EXAMPLE.COM realm. You would need to swap the realm names to get the appropriate definitions in the SALES.WEST.EXAMPLE.COM realm.


    # cat /etc/krb5/krb5.conf
    [libdefaults]
     .
     .
    [capaths]
        ENG.EAST.EXAMPLE.COM = {
            SALES.WEST.EXAMPLE.COM = .
        }
    
        SALES.WEST.EXAMPLE.COM = {
             ENG.EAST.EXAMPLE.COM = .
        }
    
  4. Copy the Kerberos configuration file to all clients in the current realm.

    For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.

  5. Repeat all of these steps for the second realm.

Configuring Kerberos Network Application Servers

Network application servers are hosts that provide access using one or more of the following network applications: ftp, rcp, rlogin, rsh, ssh, and telnet. Only a few steps are required to enable the Kerberos version of these commands on a server.

ProcedureHow to Configure a Kerberos Network Application Server

This procedure uses the following configuration parameters:

Before You Begin

This procedure requires that the master KDC has been configured. To fully test the process, several Kerberos clients must be configured.

  1. (Optional) Install the NTP client or another clock synchronization mechanism.

    See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  2. Add principals for the new server and update the server's keytab.

    The following command reports the existence of the host principal:


    boston # klist -k |grep host
    4 host/boston.example.com@EXAMPLE.COM
    4 host/boston.example.com@EXAMPLE.COM
    4 host/boston.example.com@EXAMPLE.COM
    4 host/boston.example.com@EXAMPLE.COM

    If the command does not return a principal, then create new principals using the following steps.

    How to use the Graphical Kerberos Administration Tool to add a principal is explained in How to Create a New Kerberos Principal. The example in the following steps shows how to add the required principals using the command line. You must log in with one of the admin principal names that you created when configuring the master KDC.


    boston # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Create the server's host principal.

      The host principal is used:

      • To authenticate traffic when using the remote commands, such as rsh and ssh.

      • By pam_krb5 to prevent KDC spoofing attacks by using the host principal to verify that a user's Kerberos credential was obtained from a trusted KDC.

      • To allow the root user to automatically acquire a Kerberos credential without requiring that a root principal exist. This can be useful when doing a manual NFS mount where the share requires a Kerberos credential.

      This principal is required if traffic using the remote application is to be authenticated using the Kerberos service. If the server has multiple hostnames associated with it, then create a principal for each hostname using the FQDN form of the hostname.


      kadmin: addprinc -randkey host/boston.example.com
      Principal "host/boston.example.com" created.
      kadmin: 
    2. Add the server's host principal to the server's keytab.

      If the kadmin command is not running, restart it with a command similar to the following: /usr/sbin/kadmin -p kws/admin

      If the server has multiple hostnames associated with it, then add a principal to the keytab for each hostname.


      kadmin: ktadd host/boston.example.com
      Entry for principal host/boston.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/boston.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/boston.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/boston.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/boston.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin:
    3. Quit kadmin.


      kadmin: quit
      

Configuring Kerberos NFS Servers

NFS services use UNIX user IDs (UIDs) to identify a user and cannot directly use GSS credentials. To translate the credential to a UID, a credential table that maps user credentials to UNIX UIDs might need to be created. See Mapping GSS Credentials to UNIX Credentials for more information on the default credential mapping. The procedures in this section focus on the tasks that are necessary to configure a Kerberos NFS server, to administer the credential table, and to initiate Kerberos security modes for NFS-mounted file systems. The following task map describes the tasks that are covered in this section.

Table 23–2 Configuring Kerberos NFS Servers (Task Map)

Task 

Description 

For Instructions 

Configure a Kerberos NFS server. 

Enables a server to share a file system that requires Kerberos authentication. 

How to Configure Kerberos NFS Servers

Create a credential table. 

Generates a credential table which can be used to provide mapping from GSS credentials to UNIX user IDs, if the default mapping is not sufficient. 

How to Create a Credential Table

Change the credential table that maps user credentials to UNIX UIDs. 

Updates information in the credential table. 

How to Add a Single Entry to the Credential Table

Create credential mappings between two like realms. 

Provides instructions on how to map UIDs from one realm to another if the realms share a password file. 

How to Provide Credential Mapping Between Realms

Share a file system with Kerberos authentication. 

Shares a file system with security modes so that Kerberos authentication is required. 

How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

ProcedureHow to Configure Kerberos NFS Servers

In this procedure, the following configuration parameters are used:

  1. Complete the prerequisites for configuring a Kerberos NFS server.

    The master KDC must be configured. To fully test the process, you need several clients.

  2. (Optional) Install the NTP client or another clock synchronization mechanism.

    Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be synchronized with the time on the KDC server within a maximum difference defined by the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  3. Configure the NFS server as a Kerberos client.

    Follow the instructions in Configuring Kerberos Clients.

  4. Start kadmin.

    You can use the Graphical Kerberos Administration Tool to add a principal, as explained in How to Create a New Kerberos Principal. To do so, you must log in with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.


    denver # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Create the server's NFS service principal.

      Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.

      Repeat this step for each unique interface on the system that might be used to access NFS data. If a host has multiple interfaces with unique names, each unique name must have its own NFS service principal.


      kadmin: addprinc -randkey nfs/denver.example.com
      Principal "nfs/denver.example.com" created.
      kadmin:
    2. Add the server's NFS service principal to the server's keytab file.

      Repeat this step for each unique service principal created in Step a.


      kadmin: ktadd nfs/denver.example.com
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs denver.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin:
    3. Quit kadmin.


      kadmin: quit
      
  5. (Optional) Create special GSS credential maps, if needed.

    Normally, the Kerberos service generates appropriate maps between the GSS credentials and the UNIX UIDs. The default mapping is described in Mapping GSS Credentials to UNIX Credentials. If the default mapping is not sufficient, see How to Create a Credential Table for more information.

  6. Share the NFS file system with Kerberos security modes.

    See How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes for more information.

ProcedureHow to Create a Credential Table

The gsscred credential table is used by an NFS server to map Kerberos credentials to a UID. By default, the primary part of the principal name is matched to a UNIX login name. For NFS clients to mount file systems from an NFS server with Kerberos authentication, this table must be created if the default mapping is not sufficient.

  1. Edit /etc/gss/gsscred.conf and change the security mechanism.

    Change the mechanism to files.

  2. Create the credential table by using the gsscred command.


    # gsscred -m kerberos_v5 -a
    

    The gsscred command gathers information from all sources that are listed with the passwd entry in the /etc/nsswitch.conf file. You might need to temporarily remove the files entry, if you do not want the local password entries included in the credential table. See the gsscred(1M) man page for more information.

ProcedureHow to Add a Single Entry to the Credential Table

Before You Begin

This procedure requires that the gsscred table has already been created on the NFS server. See How to Create a Credential Table for instructions.

  1. Become superuser on the NFS server.

  2. Add an entry to the credential table by using the gsscred command.


    # gsscred -m mech [ -n name [ -u uid ]] -a
    
    mech

    Defines the security mechanism to be used.

    name

    Defines the principal name for the user, as defined in the KDC.

    uid

    Defines the UID for the user, as defined in the password database.

    -a

    Adds the UID to principal name mapping.


Example 23–3 Adding a Multiple Component Principal to the Credential Table

In the following example, an entry is added for a principal named sandy/admin, which is mapped to UID 3736.


# gsscred -m kerberos_v5 -n sandy/admin -u 3736 -a


Example 23–4 Adding a Principal in a Different Domain to the Credential Table

In the following example, an entry is added for a principal named sandy/admin@EXAMPLE.COM, which is mapped to UID 3736.


# gsscred -m kerberos_v5 -n sandy/admin@EXAMPLE.COM -u 3736 -a

ProcedureHow to Provide Credential Mapping Between Realms

This procedure provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID.

  1. Become superuser.

  2. On the client system, add entries to the krb5.conf file.


    # cat /etc/krb5/krb5.conf
    [libdefaults]
            default_realm = CORP.EXAMPLE.COM
     .
    [realms]
        CORP.EXAMPLE.COM = {
            .
            auth_to_local_realm = SALES.EXAMPLE.COM
            .
        }

Example 23–5 Mapping Credentials Between Realms Using the Same Password File

This example provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID. On the client system, add entries to the krb5.conf file.


# cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = CORP.EXAMPLE.COM
 .
[realms]
    CORP.EXAMPLE.COM = {
        .
        auth_to_local_realm = SALES.EXAMPLE.COM
        .
    }

Troubleshooting

See Observing Mapping from GSS Credentials to UNIX Credentials to help with the process of troubleshooting credential mapping problems.

ProcedureHow to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

This procedure enables a NFS server to provide secure NFS access using different security modes or flavors. When a client negotiates a security flavor with the NFS server, the first flavor that is offered by the server that the client has access to is used. This flavor is used for all subsequent client requests of the file system shared by the NFS server.

  1. Become superuser on the NFS server.

  2. Verify that there is an NFS service principal in the keytab file.

    The klist command reports if there is a keytab file and displays the principals. If the results show that no keytab file exists or that no NFS service principal exists, you need to verify the completion of all the steps in How to Configure Kerberos NFS Servers.


    # klist -k
    Keytab name: FILE:/etc/krb5/krb5.keytab
    KVNO Principal
    ---- ---------------------------------------------------------
       3 nfs/denver.example.com@EXAMPLE.COM
       3 nfs/denver.example.com@EXAMPLE.COM
       3 nfs/denver.example.com@EXAMPLE.COM
       3 nfs/denver.example.com@EXAMPLE.COM
  3. Enable Kerberos security modes in the /etc/nfssec.conf file.

    Edit the /etc/nfssec.conf file and remove the “#” that is placed in front of the Kerberos security modes.


    # cat /etc/nfssec.conf
     .
     .
    #
    # Uncomment the following lines to use Kerberos V5 with NFS
    #
    krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
    krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
    krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS
  4. Share the file systems with the appropriate security modes.


    sharemgr share -o sec=mode file-system
    
    mode

    Specifies the security modes to be used when sharing the file system. When using multiple security modes, the first mode in the list is used as the default.

    file-system

    Defines the path to the file system to be shared.

    All clients that attempt to access files from the named file system require Kerberos authentication. To access files, the user principal on the NFS client should be authenticated.

  5. (Optional) If the automounter is being used, edit the auto_master database to select a security mode other than the default.

    You need not follow this procedure if you are not using the automounter to access the file system or if the default selection for the security mode is acceptable.


    file-system  auto_home  -nosuid,sec=mode
    
  6. (Optional) Manually issue the mount command to access the file system by using a non-default mode.

    Alternatively, you could use the mount command to specify the security mode, but this alternative does not take advantage of the automounter.


    # mount -F nfs -o sec=mode file-system
    

Example 23–6 Sharing a File System With One Kerberos Security Mode

In this example, Kerberos authentication must succeed before any files can be accessed through the NFS service.


# sharemgr share -F nfs -p -o sec=krb5 /export/home


Example 23–7 Sharing a File System With Multiple Kerberos Security Modes

In this example, all three Kerberos security modes have been selected. Which mode is used is negotiated between the client and the NFS server. If the first mode in the command fails, then the next is tried. See the nfssec(5) man page for more information.


# sharemgr share -F nfs -p -o sec=krb5:krb5i:krb5p /export/home

Configuring Kerberos Clients

Kerberos clients include any host, that is not a KDC server, on the network that needs to use Kerberos services. This section provides procedures for installing a Kerberos client, as well as specific information about using root authentication to mount NFS file systems.

Configuring Kerberos Clients (Task Map)

The following task map includes all of the procedures associated with setting up Kerberos clients. Each row includes a task identifier, a description of why you would want to do that task, followed by a link to the task.

Task 

Description 

For Instructions 

Establish a Kerberos client installation profile. 

Generates a client installation profile that can be used to automatically install a Kerberos client. 

How to Create a Kerberos Client Installation Profile

Configure a Kerberos client. 

Manually installs a Kerberos client. Use this procedure if each client installation requires unique installation parameters. 

How to Manually Configure a Kerberos Client

 

Automatically installs a Kerberos client. Use this procedure if the installation parameters for each client are the same. 

How to Automatically Configure a Kerberos Client

 

Interactively installs a Kerberos client. Use this procedure if only a few of the installation parameters need to change. 

How to Interactively Configure a Kerberos Client

 

Automatically installs a Kerberos client of an Active Directory server.  

How to Configure a Kerberos Client for an Active Directory Server

Allow a client to access a NFS file system as the root user

Creates a root principal on the client, so that the client can mount a NFS file system shared with root access. Also, allows for the client to set up non-interactive root access to the NFS file system, so that cron jobs can run.

How to Access a Kerberos Protected NFS File System as the root User

Disable verification of the KDC that issued a client Ticket Granting Ticket (TGT). 

Allows clients that do not have a host principal stored in the local keytab file to skip the security check that verifies that the KDC that issued the TGT is the same server that issued the host principal. 

How to Disable Verification of the Ticket Granting Ticket (TGT)

ProcedureHow to Create a Kerberos Client Installation Profile

This procedure creates a kclient profile that can be used when you install a Kerberos client. By using the kclient profile, you reduce the likelihood of typing errors. Also, using the profile reduces user intervention as compared to the interactive process.

  1. Become superuser.

  2. Create a kclient installation profile.

    A sample kclient profile could look similar to the following:


    client# cat /net/denver.example.com/export/install/profile
    REALM EXAMPLE.COM
    KDC kdc1.example.com
    ADMIN clntconfig
    FILEPATH /net/denver.example.com/export/install/krb5.conf
    NFS 1
    DNSLOOKUP none

ProcedureHow to Automatically Configure a Kerberos Client

Before You Begin

This procedure uses an installation profile. See How to Create a Kerberos Client Installation Profile.

  1. Become superuser.

  2. Run the kclient installation script.

    You need to provide the password for the clntconfig principal to complete the process.


    client# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile
    
    Starting client setup
    ---------------------------------------------------
    
    kdc1.example.com
    
    Setting up /etc/krb5/krb5.conf.
    
    Obtaining TGT for clntconfig/admin ...
    Password for clntconfig/admin@EXAMPLE.COM: <Type the password>
    
    nfs/client.example.com entry ADDED to KDC database.
    nfs/client.example.com entry ADDED to keytab.
    
    host/client.example.com entry ADDED to KDC database.
    host/client.example.com entry ADDED to keytab.
    
    Copied /net/denver.example.com/export/install/krb5.conf.
    
    ---------------------------------------------------
    Setup COMPLETE.
    
    client#

Example 23–8 Automatically Configuring a Kerberos Client With Command-Line Overrides

The following example overrides the DNSARG and the KDC parameters that are set in the installation profile.


# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile\
-d dns_fallback -k kdc2.example.com

Starting client setup
---------------------------------------------------

kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>

nfs/client.example.com entry ADDED to KDC database.
nfs/client.example.com entry ADDED to keytab.

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE.

client#

ProcedureHow to Interactively Configure a Kerberos Client

This procedure uses the kclient installation utility without a installation profile. In build 90 of the Solaris Express Community Edition release, the kclient utility has been expanded to improve ease of use and ability to work with Active Directory servers. See How to Configure a Kerberos Client for an Active Directory Server for more information. See Example 23–10 for an example of running kclient on a previous Solaris release.

  1. Become superuser.

  2. Run the kclient installation script.

    You need to provide the following information:

    • Kerberos realm name

    • KDC master host name

    • KDC slave host names

    • Domains to map to the local realm

    • PAM service names and options to use for Kerberos authentication

    1. Indicate if the KDC server is not running a Solaris release.

      If this system is a client of a KDC server that is not running a Solaris release, you need to define the type of server that is running the KDC. The available servers are: Microsoft Active Directory, MIT KDC server, Heimdal KDC server, and Shishi KDC server.

    2. Select if DNS should be used for Kerberos lookups.

      If you use DNS for Kerberos lookups, you need to enter the DNS lookup option that you want to use. Valid options are dns_lookup_kdc, dns_lookup_realm, and dns_fallback. See the krb5.conf(4) man page for more information about these values.

    3. Define the name of the Kerberos realm and the master KDC hostname.

      This information is added to the /etc/krb5/krb5.conf configuration file.

    4. Select if slave KDCs exist.

      If there are slave KDCs in the realm, then you need to enter the slave KDC host names. This information is used to create additional KDC entries in the client's configuration file.

    5. Indicate if service or host keys are required.

      Normally, service or host keys are not required unless the client system is hosting Kerberized services.

    6. Specify if the client is a member of a cluster.

      If the client is a member of a cluster, then you need to provide the logical name of the cluster. The logical host name is used when creating service keys, which is required when hosting Kerberos services from clusters.

    7. Identify any domains or hosts to map to the current realm.

      This mapping allows other domains to belong in the default realm of the client.

    8. Specify if the client will use Kerberized NFS.

      NFS service keys need to be created if the client will host NFS services using Kerberos.

    9. Indicate if the /etc/pam.conf file needs to be updated.

      This allows you to set which PAM services use Kerberos for authentication. You need to enter the service name and a flag indicating how Kerberos authentication is to be used. The valid flag options are:

      • first – use Kerberos authentication first, and only use UNIX if Kerberos authentication fails

      • only – use Kerberos authentication only

      • optional – use Kerberos authentication optionally

    10. Select if the master /etc/krb5/krb5.conf file should be copied.

      This option allows for specific configuration information to be used when the arguments to kclient are not sufficient.


Example 23–9 Running the kclient Installation Utility


client# /usr/sbin/kclient

Starting client setup
---------------------------------------------------

Is this a client of a non-Solaris KDC ? [y/n]: n
        No action performed.
Do you want to use DNS for kerveros lookups ? [y/n]: n
        No action performed.
Enter the Kerberos realm: EXAMPLE.COM
Specify the KDC hostname for the above realm: kdc1.example.com

Note, this system and the KDC's time must be within 5 minutes of each other for
Kerberos to function. Both systems should run some form of time synchronization
system like Network Time Protocol (NTP).
Do you have any slave KDC(s) ? [y/n]: y
Enter a comma-separated list of slave KDC host names: kdc2.example.com

Will this client need service keys ? [y/n]: n
        No action performed.
Is this client a member of a cluster that uses a logical host name ? [y/n]: n
        No action performed.
Do you have multiple domains/hosts to map to realm ? [y/n]: y
Enter a comma-separated list of domain/hosts to map to the default realm: engineering.example.com, \
        example.com

Setting up /etc/krb5/krb5.conf.

Do you plan on doing Kerberized nfs ? [y/n]: y
Do you want to update /etc/pam.conf ? [y/n]: y
Enter a comma-separated list of PAM service names in the following format:
service:{first|only|optional}: xscreensaver:first
Configuring /etc/pam.conf.

Do you want to copy over the master krb5.conf file ? [y/n]: n
        No action performed.

---------------------------------------------------
Setup COMPLETE.


Example 23–10 Running the kclient Installation Utility on the Solaris 10 Release

The following output shows the results of running the kclient command.


client# /usr/sbin/kclient

Starting client setup
---------------------------------------------------

Do you want to use DNS for kerberos lookups ? [y/n]: n
        No action performed.
Enter the Kerberos realm: EXAMPLE.COM
Specify the KDC hostname for the above realm: kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Enter the krb5 administrative principal to be used: clntconfig/admin
Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>
Do you plan on doing Kerberized nfs ? [y/n]: n

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Do you want to copy over the master krb5.conf file ? [y/n]: y
Enter the pathname of the file to be copied: \
/net/denver.example.com/export/install/krb5.conf

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE !
#

ProcedureHow to Configure a Kerberos Client for an Active Directory Server

This procedure uses the kclient installation utility without a installation profile.

  1. Become superuser.

  2. (Optional) Enable DNS resource record creation for the client.

    The first command causes DNS records to be created when the client is joined to the Active Directory domain. The second command records this change in the running configuration of this service.


    client# svccfg -s smb/server setprop smbd/ddns_enable=true
    client# svcadm refresh smb/server
    
  3. Run the kclient installation script.

    You need to provide the following information:

    • Password for the administrative principal


Example 23–11 Configuring a Kerberos Client for an Active Directory Server Using kclient.

The following output shows the results of running the kclient command using the ms_ad (Microsoft Active Directory) server type argument. The client will be joined to the Active Directory domain called EXAMPLE.COM.


client# /usr/sbin/kclient -T ms_ad

Starting client setup
---------------------------------------------------

Attempting to join 'CLIENT' to the 'EXAMPLE.COM' domain.
Password for Administrator@EXAMPLE.COM: <Type the password>
Forest name found: example.com
Looking for local KDCs, DCs and global catalog servers (SVR RRs).

Setting up /etc/krb5/krb5.conf

Creating the machine account in AD via LDAP.
---------------------------------------------------
Setup COMPLETE.
#

ProcedureHow to Manually Configure a Kerberos Client

In this procedure, the following configuration parameters are used:

  1. Become superuser.

  2. Edit the Kerberos configuration file (krb5.conf).

    To change the file from the Kerberos default version, you need to change the realm names and the server names. You also need to identify the path to the help files for gkadmin.


    kdc1 # cat /etc/krb5/krb5.conf
    [libdefaults]
            default_realm = EXAMPLE.COM
    
    [realms]
            EXAMPLE.COM = {
            kdc = kdc1.example.com
            kdc = kdc2.example.com
            admin_server = kdc1.example.com
            }
    
    [domain_realm]
            .example.com = EXAMPLE.COM
    #
    # if the domain name and realm name are equivalent, 
    # this entry is not needed
    #
    [logging]
            default = FILE:/var/krb5/kdc.log
            kdc = FILE:/var/krb5/kdc.log
    
    [appdefaults]
        gkadmin = {
            help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
    

    Note –

    If you want to restrict the encryption types, you can set the default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.


  3. (Optional) Change the process used to locate the KDCs.

    Starting with the Solaris 10 5/08 and Solaris Express Developer Edition 1/08 releases, by default the Kerberos realm to KDC mapping is determined in the following order:

    • The definition in the realms section in krb5.conf.

    • By looking up SRV records in DNS.

    You can change this behavior by adding dns_lookup_kdc or dns_fallback to the libdefaults section of the krb5.conf file. See the krb5.conf(4) man page for more information. Note that referrals are always tried first.

  4. (Optional) Change the process used to determine the realm for a host.

    Starting with the Solaris 10 5/08 and Solaris Express Developer Edition 1/08 releases, by default the host to realm mapping is determined in the following order:

    • If the KDC supports referrals, then the KDC may inform the client which realm the host belongs to.

    • By the definition of domain_realm in the krb5.conf file.

    • The DNS domainname of the host.

    • The default realm.

    You can change this behavior by adding dns_lookup_kdc or dns_fallback to the libdefaults section of the krb5.conffile. See the krb5.conf(4) man page for more information. Note that referrals will always be tried first.

  5. (Optional) Synchronize the client's clock with the master KDC's clock by using NTP or another clock synchronization mechanism.

    Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be synchronized with the time on the KDC server within a maximum difference defined in the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  6. Start kadmin.

    You can use the Graphical Kerberos Administration Tool to add a principal, as explained in How to Create a New Kerberos Principal. To do so, you must log in with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.


    denver # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. (Optional) Create a user principal if a user principal does not already exist.

      You need to create a user principal only if the user associated with this host does not already have a principal assigned to him or her.


      kadmin: addprinc mre
      Enter password for principal mre@EXAMPLE.COM: <Type the password>
      Re-enter password for principal mre@EXAMPLE.COM: <Type it again>
      kadmin: 
    2. (Optional) Create a root principal and add the principal to the server's keytab file.

      This step is required so that the client can have root access to file systems mounted using the NFS service. This step is also required if non-interactive root access is needed, such as running cron jobs as root.

      If the client does not require root access to a remote file system which is mounted using the NFS service, then you can skip this step. The root principal should be a two component principal with the second component the host name of the Kerberos client system to avoid the creation of a realm wide root principal. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: addprinc -randkey root/client.example.com
      Principal "root/client.example.com" created.
      kadmin: ktadd root/client.example.com
      Entry for principal root/client.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    3. Create a host principal and add the principal to the server's keytab file.

      The host principal is used by remote access services to provide authentication. The principal allows root to acquire a credential, if there is not one already in the keytab file.


      kadmin: addprinc -randkey host/denver.example.com
      Principal "host/denver.example.com@EXAMPLE.COM" created.
      kadmin: ktadd host/denver.example.com
      Entry for principal host/denver.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/denver.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin:
    4. (Optional) Add the server's NFS service principal to the server's keytab file.

      This step is only required if the client needs to access NFS file systems using Kerberos authentication.


      kadmin: ktadd nfs/denver.example.com
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    5. Quit kadmin.


      kadmin: quit
      
  7. (Optional) Enable Kerberos with NFS.

    1. Enable Kerberos security modes in the /etc/nfssec.conf file.

      Edit the /etc/nfssec.conf file and remove the “#” that is placed in front of the Kerberos security modes.


      # cat /etc/nfssec.conf
       .
       .
      #
      # Uncomment the following lines to use Kerberos V5 with NFS
      #
      krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
      krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
      krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS
    2. Enable DNS.

      If the /etc/resolv.conf file has not already been created, then create this file as the service principal canonicalization is dependent upon DNS to do this. See the resolv.conf(4) man page for more information.

    3. Restart the gssd service.

      After the /etc/resolv.conf file has been created or modified you must then restart the gssd daemon to reread any changes.


      # svcadm restart network/rpc/gss
      
  8. If you want the client to automatically renew the TGT or to warn users about Kerberos ticket expiration, create an entry in the /etc/krb5/warn.conf file.

    See the warn.conf(4) man page for more information.


Example 23–12 Setting Up a Kerberos Client Using a Non-Solaris KDC

A Kerberos client can be set up to work with a non-Solaris KDC. In this case, a line must be included in the /etc/krb5/krb5.conf file in the realms section. This line changes the protocol that is used when the client is communicating with the Kerberos password-changing server. The format of this line follows.


[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
                kpasswd_protocol = SET_CHANGE
        }


Example 23–13 DNS TXT Records for the Mapping of Host and Domain Name to Kerberos Realm


@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                        IN      NS      kdc1.example.com.
kdc1                    IN      A       192.146.86.20
kdc2                    IN      A       192.146.86.21

_kerberos.example.com.             IN      TXT     "EXAMPLE.COM"
_kerberos.kdc1.example.com.        IN      TXT     "EXAMPLE.COM"
_kerberos.kdc2.example.com.        IN      TXT     "EXAMPLE.COM"


Example 23–14 DNS SRV Records for Kerberos Server Locations

This example defines the records for the location of the KDCs, the admin server, and the kpasswd server, respectively.


@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                                   IN      NS      kdc1.example.com.
kdc1                               IN      A       192.146.86.20
kdc2                               IN      A       192.146.86.21

_kerberos._udp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._udp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos-adm._tcp.EXAMPLE.COM     IN      SRV 0 0 749 kdc1.example.com
_kpasswd._udp.EXAMPLE.COM          IN      SRV 0 0 749 kdc1.example.com

ProcedureHow to Disable Verification of the Ticket Granting Ticket (TGT)

This procedure disables the security check that checks that the KDC of the host principal stored in the local /etc/krb5/krb5.keytab file is the same KDC that issued the Ticket Granting Ticket. This check prevents DNS spoofing attacks. However, for some client configurations, the host principal may not be available, so this check would need to be disabled to allow the client to function. These are the configurations that require that this check is disabled:

  1. Become superuser.

  2. Change the krb5.conf file.

    If the verify_ap_req_nofail option is set to false, the TGT verification process is not enabled. See the krb5.conf(4) man page for more information about this option.


    client # cat /etc/krb5/krb5.conf
    [libdefaults]
            default_realm = EXAMPLE.COM
            verify_ap_req_nofail = false
      ...

    Note –

    The verify_ap_req_nofail option can be entered in either the [libdefaults] or the [realms] section of the krb5.conf file. If the option is in the [libdefaults]section, the setting is used for all realms. If the option is in the [realms]section, the setting only applies to the defined realm.


ProcedureHow to Access a Kerberos Protected NFS File System as the root User

This procedure allows a client to access a NFS file system that requires Kerberos authentication with the root ID privilege. In particular, when the NFS file system is shared with options like: -o sec=krb5,root=client1.sun.com.

  1. Become superuser.

  2. Start kadmin.

    You can use the Graphical Kerberos Administration Tool to add a principal, as explained in How to Create a New Kerberos Principal. To do so, you must log in with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.


    denver # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Create a root principal for the NFS client.

      This principal is used to provide root equivalent access to NFS mounted file systems that require Kerberos authentication. The root principal should be a two component principal with the second component the host name of the Kerberos client system to avoid the creation of a realm wide root principal. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: addprinc -randkey root/client.example.com
      Principal "root/client.example.com" created.
      kadmin:
    2. Add the root principal to the server's keytab file.

      This step is required if you added a root principal so that the client can have root access to file systems mounted using the NFS service. This step is also required if non-interactive root access is needed, such as running cron jobs as root.


      kadmin: ktadd root/client.example.com
      Entry for principal root/client.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal root/client.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    3. Quit kadmin.


      kadmin: quit
      

ProcedureHow to Configure Automatic Migration of Users in a Kerberos Realm

Users, who do not have a Kerberos principal, can be automatically migrated to an existing Kerberos realm. The migration is achieved by using the PAM framework for the service in use by stacking the pam_krb5_migrate module in the service's authentication stack in /etc/pam.conf.

In this example, the dtlogin and other PAM service names are configured to use the automatic migration. The following configuration parameters are used:

Before You Begin

Setup server1 as a Kerberos client of the realm EXAMPLE.COM. See Configuring Kerberos Clients for more information.

  1. Check to see if a host service principal for server1 exists.

    The host service principal in the keytab file of server1 is used to authenticate the server to the master KDC.


    server1 # klist -k
    Keytab name: FILE:/etc/krb5/krb5.keytab
    	KVNO Principal
    	---- ------------------------------------------------
    	   3 host/server1.example.com@EXAMPLE.COM
    	   3 host/server1.example.com@EXAMPLE.COM
    	   3 host/server1.example.com@EXAMPLE.COM
    	   3 host/server1.example.com@EXAMPLE.COM
  2. Make changes to the PAM configuration file.

    1. Add entries for the dtlogin service.


      # cat /etc/pam.conf
       .
       .
      #
      # dtlogin service (explicit because of pam_krb5_migrate)
      #
      dtlogin       auth requisite          pam_authtok_get.so.1
      dtlogin       auth required           pam_dhkeys.so.1
      dtlogin       auth required           pam_unix_cred.so.1
      dtlogin       auth sufficient         pam_krb5.so.1
      dtlogin       auth requisite          pam_unix_auth.so.1
      dtlogin       auth optional           pam_krb5_migrate.so.1
      
    2. (Optional) Force an immediate password change, if needed.

      The newly created Kerberos accounts can have their password expiration time set to the current time (now), in order to force an immediate Kerberos password change. To set the expiration time to now, add the expire_pw option to the lines which use the pam_krb5_migrate module. See the pam_krb5_migrate(5) man page for more information.


      # cat /etc/pam.conf
       .
       .
      dtlogin  auth optional           pam_krb5_migrate.so.1 expire_pw
      
    3. Add the pam_krb5 module to the account stack.

      This addition allows for password expiration in Kerberos to block access.


      # cat /etc/pam.conf
       .
       .
      #
      # Default definition for Account management
      # Used when service name is not explicitly mentioned for account management
      #
      other   account requisite       pam_roles.so.1
      other   account required        pam_krb5.so.1
      other   account required        pam_unix_account.so.1
    4. Add the pam_krb5 module to the password stack.

      This addition allows for passwords to be updated when the password expire.


      # cat /etc/pam.conf
       .
       .
      #
      # Default definition for Password management
      # Used when service name is not explicitly mentioned for password management
      #
      other   password required       pam_dhkeys.so.1
      other   password requisite      pam_authtok_get.so.1
      other   password requisite      pam_authtok_check.so.1
      other   password sufficient     pam_krb5.so.1
      other   password required       pam_authtok_store.so.1
  3. On the master KDC, update the access control file.

    The following entries grant migrate and inquire privileges to the host/server1.example.com service principal for all users, excepting the root user. It is important that users who should not be migrated are listed in the kadm5.acl file using the U privilege. These entries need to be before the permit all or ui entry. See the kadm5.acl(4) man page for more information.


    kdc1 # cat /etc/krb5/kadm5.acl
    host/server1.example.com@EXAMPLE.COM U root
    host/server1.example.com@EXAMPLE.COM ui *
    */admin@EXAMPLE.COM *
  4. On the master KDC, restart the Kerberos administration daemon.

    This step allows the kadmind daemon to use the new kadm5.acl entries.


    kdc1 # svcadm restart network/security/kadmin
    
  5. On the master KDC, add entries to the pam.conf file.

    The following entries enable the kadmind daemon to use the k5migrate PAM service, to validate UNIX user password for accounts that require migration.


    # grep k5migrate /etc/pam.conf
    k5migrate        auth    required        pam_unix_auth.so.1
    k5migrate        account required        pam_unix_account.so.1

Synchronizing Clocks Between KDCs and Kerberos Clients

All hosts that participate in the Kerberos authentication system must have their internal clocks synchronized within a specified maximum amount of time (known as clock skew). This requirement provides another Kerberos security check. If the clock skew is exceeded between any of the participating hosts, client requests are rejected.

The clock skew also determines how long application servers must keep track of all Kerberos protocol messages, in order to recognize and reject replayed requests. So, the longer the clock skew value, the more information that application servers have to collect.

The default value for the maximum clock skew is 300 seconds (five minutes). You can change this default in the libdefaults section of the krb5.conf file.


Note –

For security reasons, do not increase the clock skew beyond 300 seconds.


Because maintaining synchronized clocks between the KDCs and Kerberos clients is important, you should use the Network Time Protocol (NTP) software to synchronize them. NTP public domain software from the University of Delaware is included in the Solaris software, starting with the Solaris 2.6 release.


Note –

Another way to synchronize clocks is to use the rdate command and cron jobs, a process that can be less involved than using NTP. However, this section focuses on using NTP. And, if you use the network to synchronize the clocks, the clock synchronization protocol must itself be secure.


NTP enables you to manage precise time or network clock synchronization, or both, in a network environment. NTP is basically a server-client implementation. You pick one system to be the master clock (the NTP server). Then, you set up all your other systems (the NTP clients) to synchronize their clocks with the master clock.

To synchronize the clocks, NTP uses the xntpd daemon, which sets and maintains a UNIX system time-of-day in agreement with Internet standard time servers. The following shows an example of this server-client NTP implementation.

Figure 23–1 Synchronizing Clocks by Using NTP

Diagram shows a central NTP server as the master clock
for NTP clients and Kerberos clients that are running the xntpd daemon.

    Ensuring that the KDCs and Kerberos clients maintain synchronized clocks involves implementing the following steps:

  1. Setting up an NTP server on your network. This server can be any system, except the master KDC. See Managing Network Time Protocol (Tasks) in System Administration Guide: Network Services to find the NTP server task.

  2. As you configure the KDCs and Kerberos clients on the network, setting them up to be NTP clients of the NTP server. See Managing Network Time Protocol (Tasks) in System Administration Guide: Network Services to find the NTP client task.

Swapping a Master KDC and a Slave KDC

You should use the procedures in this section to make the swap of a master KDC with a slave KDC easier. You should swap the master KDC with a slave KDC only if the master KDC server fails for some reason, or if the master KDC needs to be re-installed (for example, because new hardware is installed).

ProcedureHow to Configure a Swappable Slave KDC

Perform this procedure on the slave KDC server that you want to have available to become the master KDC. This procedure assumes that you are using incremental propagation.

  1. Use alias names for the master KDC and the swappable slave KDC during the KDC installation.

    When you define the host names for the KDCs, make sure that each system has an alias included in DNS. Also, use the alias names when you define the hosts in the /etc/krb5/krb5.conf file.

  2. Follow the steps to install a slave KDC.

    Prior to any swap, this server should function as any other slave KDC in the realm. See How to Manually Configure a Slave KDC for instructions.

  3. Move the master KDC commands.

    To prevent the master KDC commands from being run from this slave KDC, move the kprop, kadmind, and kadmin.local commands to a reserved place.


    kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save
    kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save
    kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save
    

ProcedureHow to Swap a Master KDC and a Slave KDC

In this procedure, the master KDC server that is being swapped out is named kdc1. The slave KDC that will become the new master KDC is named kdc4. This procedure assumes that you are using incremental propagation.

Before You Begin

This procedure requires that the slave KDC server has been set up as a swappable slave. For more information, see How to Configure a Swappable Slave KDC).

  1. On the new master KDC, start kadmin.


    kdc4 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Create new principals for the kadmind service.

      The following example shows the first addprinc command on two lines, but it should be typed on one line.


      kadmin: addprinc -randkey -allow_tgs_req +password_changing_service -clearpolicy \
             changepw/kdc4.example.com
      Principal "changepw/kdc4.example.com@ENG.SUN.COM" created.
      kadmin: addprinc -randkey -allow_tgs_req -clearpolicy kadmin/kdc4.example.com
      Principal "kadmin/kdc4.example.com@EXAMPLE.COM" created.
      kadmin: 
    2. Quit kadmin.


      kadmin: quit
      
  2. On the new master KDC, force synchronization.

    The following steps force a full KDC update on the slave server.


    kdc4 # svcadm disable network/security/krb5kdc
    kdc4 # rm /var/krb5/principal.ulog
    
  3. On the new master KDC, verify that the update is complete.


    kdc4 # /usr/sbin/kproplog -h
    
  4. On the new master KDC, restart the KDC service.


    kdc4 # svcadm enable -r network/security/krb5kdc
    
  5. On the new master KDC, clear the update log.

    These steps reinitialize the update log for the new master KDC server.


    kdc4 # svcadm disable network/security/krb5kdc
    kdc4 # rm /var/krb5/principal.ulog
    
  6. On the old master KDC, kill the kadmind and krb5kdc processes.

    When you kill the kadmind process, you prevent any changes from being made to the KDC database.


    kdc1 # svcadm disable network/security/kadmin
    kdc1 # svcadm disable network/security/krb5kdc
    
  7. On the old master KDC, specify the poll time for requesting propagations.

    Comment out the sunw_dbprop_master_ulogsize entry in /etc/krb5/kdc.conf and add an entry defining sunw_dbprop_slave_poll. The entry sets the poll time to 2 minutes.


    kdc1 # cat /etc/krb5/kdc.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM= {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
    #               sunw_dbprop_master_ulogsize = 1000
                    sunw_dbprop_slave_poll = 2m
            }
  8. On the old master KDC, move the master KDC commands and the kadm5.acl file.

    To prevent the master KDC commands from being run, move the kprop, kadmind, and kadmin.local commands to a reserved place.


    kdc1 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save
    kdc1 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save
    kdc1 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save
    kdc1 # mv /etc/krb5/kadm5.acl /etc/krb5/kadm5.acl.save
    
  9. On the DNS server, change the alias names for the master KDC.

    To change the servers, edit the example.com zone file and change the entry for masterkdc.


    masterkdc IN CNAME kdc4
  10. On the DNS server, restart the Internet domain name server.

    Run the following command to reload the new alias information:


    # svcadm refresh network/dns/server
    
  11. On the new master KDC, move the master KDC commands and the slave kpropd.acl file.


    kdc4 # mv /usr/lib/krb5/kprop.save /usr/lib/krb5/kprop
    kdc4 # mv /usr/lib/krb5/kadmind.save /usr/lib/krb5/kadmind
    kdc4 # mv /usr/sbin/kadmin.local.save /usr/sbin/kadmin.local
    kdc4 # mv /etc/krb5/kpropd.acl /etc/krb5/kpropd.acl.save
    
  12. On the new master KDC, create the Kerberos access control list file (kadm5.acl).

    Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC. The file should also list all of the slaves that make requests for incremental propagation. See the kadm5.acl(4) man page for more information.


    kdc4 # cat /etc/krb5/kadm5.acl
    kws/admin@EXAMPLE.COM   *
    kiprop/kdc1.example.com@EXAMPLE.COM p
    
  13. On the new master KDC, specify the update log size in the kdc.conf file.

    Comment out the sunw_dbprop_slave_poll entry and add an entry defining sunw_dbprop_master_ulogsize. The entry sets the log size to 1000 entries.


    kdc1 # cat /etc/krb5/kdc.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM= {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
    #               sunw_dbprop_slave_poll = 2m
                    sunw_dbprop_master_ulogsize = 1000
            }
  14. On the new master KDC, start kadmind and krb5kdc.


    kdc4 # svcadm enable -r network/security/krb5kdc
    kdc4 # svcadm enable -r network/security/kadmin
    
  15. On the old master KDC, add the kiprop service principal.

    Adding the kiprop principal to the krb5.keytab file allows the kpropd daemon to authenticate itself for the incremental propagation service.


    kdc1 # /usr/sbin/kadmin -p kws/admin
    Authenticating as pricipal kws/admin@EXAMPLE.COM with password.
    Enter password: <Type kws/admin password>
    kadmin: ktadd kiprop/kdc1.example.com
    Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
              with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
              with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type Triple DES cbc
              mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type ArcFour
              with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type DES cbc mode
              with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    kadmin: quit
    
  16. On the old master KDC, add an entry for each KDC listed in krb5.conf to the propagation configuration file, kpropd.acl.


    kdc1 # cat /etc/krb5/kpropd.acl
    host/kdc1.example.com@EXAMPLE.COM
    host/kdc2.example.com@EXAMPLE.COM
    host/kdc3.example.com@EXAMPLE.COM
    host/kdc4.example.com@EXAMPLE.COM
  17. On the old master KDC, start kpropd and krb5kdc.


    kdc1 # svcadm enable -r network/security/krb5_prop
    kdc1 # svcadm enable -r network/security/krb5kdc
    

Administering the Kerberos Database

The Kerberos database is the backbone of Kerberos and must be maintained properly. This section provides some procedures on how to administer the Kerberos database, such as backing up and restoring the database, setting up incremental or parallel propagation, and administering the stash file. The steps to initially set up the database are in How to Manually Configure a Master KDC.

Backing Up and Propagating the Kerberos Database

Propagating the Kerberos database from the master KDC to the slave KDCs is one of the most important configuration tasks. If propagation doesn't happen often enough, the master KDC and the slave KDCs will lose synchronization. So, if the master KDC goes down, the slave KDCs will not have the most recent database information. Also, if a slave KDC has been configured as a master KDC for purposes of load balancing, the clients that use that slave KDC as a master KDC will not have the latest information. Therefore, you must make sure that propagation occurs often enough or else configure the servers for incremental propagation, based on how often you change the Kerberos database. Incremental propagation is preferred over manual propagation because there is more administrative overhead when you manually propagate the database. Also, there are inefficiencies when you do full propagation of the database.

When you configure the master KDC, you set up the kprop_script command in a cron job to automatically back up the Kerberos database to the /var/krb5/slave_datatrans dump file and propagate it to the slave KDCs. But, as with any file, the Kerberos database can become corrupted. If data corruption occurs on a slave KDC, you might never notice, because the next automatic propagation of the database installs a fresh copy. However, if corruption occurs on the master KDC, the corrupted database is propagated to all of the slave KDCs during the next propagation. And, the corrupted backup overwrites the previous uncorrupted backup file on the master KDC.

Because there is no “safe” backup copy in this scenario, you should also set up a cron job to periodically copy the slave_datatrans dump file to another location or to create another separate backup copy by using the dump command of kdb5_util. Then, if your database becomes corrupted, you can restore the most recent backup on the master KDC by using the load command of kdb5_util.

Another important note: Because the database dump file contains principal keys, you need to protect the file from being accessed by unauthorized users. By default, the database dump file has read and write permissions only as root. To protect against unauthorized access, use only the kprop command to propagate the database dump file, which encrypts the data that is being transferred. Also, kprop propagates the data only to the slave KDCs, which minimizes the chance of accidentally sending the database dump file to unauthorized hosts.


Caution – Caution –

If the Kerberos database is updated after it has been propagated and if the database subsequently is corrupted before the next propagation, the KDC slaves will not contain the updates. The updates will be lost. For this reason, if you add significant updates to the Kerberos database before a regularly scheduled propagation, you should manually propagate the database to avoid data loss.


The kpropd.acl File

The kpropd.acl file on a slave KDC provides a list of host principal names, one name per line, that specifies the systems from which the KDC can receive an updated database through propagation. If the master KDC is used to propagate all the slave KDCs, the kpropd.acl file on each slave needs to contain only the host principal name of the master KDC.

However, the Kerberos installation and subsequent configuration steps in this book instruct you to add the same kpropd.acl file to the master KDC and the slave KDCs. This file contains all the KDC host principal names. This configuration enables you to propagate from any KDC, in case the propagating KDCs become temporarily unavailable. And, by keeping an identical copy on all KDCs, you make the configuration easy to maintain.

The kprop_script Command

The kprop_script command uses the kprop command to propagate the Kerberos database to other KDCs. If the kprop_script command is run on a slave KDC, it propagates the slave KDC's copy of the Kerberos database to other KDCs. The kprop_script accepts a list of host names for arguments, separated by spaces, which denote the KDCs to propagate.

When kprop_script is run, it creates a backup of the Kerberos database to the /var/krb5/slave_datatrans file and copies the file to the specified KDCs. The Kerberos database is locked until the propagation is finished.

ProcedureHow to Back Up the Kerberos Database

  1. Become superuser on the master KDC.

  2. Back up the Kerberos database by using the dump command of the kdb5_util command.


    # /usr/sbin/kdb5_util dump [-verbose] [-d dbname] [filename [principals...]]
    -verbose

    Prints the name of each principal and policy that is being backed up.

    dbname

    Defines the name of the database to back up. Note that you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal.

    filename

    Defines the file that is used to back up the database. You can specify an absolute path for the file. If you don't specify a file, the database is dumped to standard output.

    principals

    Defines a list of one or more principals (separated by a space) to back up. You must use fully qualified principal names. If you don't specify any principals, the entire database is backed up.


Example 23–15 Backing Up the Kerberos Database

In the following example, the Kerberos database is backed up to a file called dumpfile. Because the -verbose option is specified, each principal is printed as it is backed up.


# kdb5_util dump -verbose dumpfile 
kadmin/kdc1.eng.example.com@ENG.EXAMPLE.COM 
krbtgt/ENG.EXAMPLE.COM@ENG.EXAMPLE.COM 
kadmin/history@ENG.EXAMPLE.COM 
pak/admin@ENG.EXAMPLE.COM 
pak@ENG.EXAMPLE.COM
changepw/kdc1.eng.example.com@ENG.EXAMPLE.COM

In the following example, the pak and pak/admin principals from the Kerberos database are backed up.


# kdb5_util dump -verbose dumpfile pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM
pak/admin@ENG.EXAMPLE.COM
pak@ENG.EXAMPLE.COM

ProcedureHow to Restore the Kerberos Database

  1. Become superuser on the master KDC.

  2. On the master, stop the KDC daemons.


    kdc1 # svcadm disable network/security/krb5kdc
    kdc1 # svcadm disable network/security/kadmin
    
  3. Restore the Kerberos database by using the load command of the kdb_util command.


    # /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename] 
    -verbose

    Prints the name of each principal and policy that is being restored.

    dbname

    Defines the name of the database to restore. Note you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal.

    -update

    Updates the existing database. Otherwise, a new database is created or the existing database is overwritten.

    filename

    Defines the file from which to restore the database. You can specify an absolute path for the file.

  4. Start the KDC daemons.


    kdc1 # svcadm enable -r network/security/krb5kdc
    kdc1 # svcadm enable -r network/security/kadmin
    

Example 23–16 Restoring the Kerberos Database

In the following example, the database called database1 is restored into the current directory from the dumpfile file. Because the -update option isn't specified, a new database is created by the restore.


# kdb5_util load -d database1 dumpfile

ProcedureHow to Convert a Kerberos Database After a Server Upgrade

If your KDC database was created on a server running the Solaris 8 or Solaris 9 release, converting the database allows you to take advantage of the improved database format.

Before You Begin

Make sure that the database is using an older format.

  1. On the master, stop the KDC daemons.


    kdc1 # svcadm disable network/security/krb5kdc
    kdc1 # svcadm disable network/security/kadmin
    
  2. Create a directory to store a temporary copy of the database.


    kdc1 # mkdir /var/krb5/tmp
    kdc1 # chmod 700 /var/krb5/tmp
    
  3. Dump the KDC database.


    kdc1 # kdb5_util dump /var/krb5/tmp/prdb.txt
    
  4. Save copies of the current database files.


    kdc1 # cd /var/krb5
    kdc1 # mv princ* tmp/
    
  5. Load the database.


    kdc1 # kdb5_util load /var/krb5/tmp/prdb.txt
    
  6. Start the KDC daemons.


    kdc1 # svcadm enable -r network/security/krb5kdc
    kdc1 # svcadm enable -r network/security/kadmin
    

ProcedureHow to Reconfigure a Master KDC to Use Incremental Propagation

The steps in this procedure can be used to reconfigure an existing master KDC to use incremental propagation. In this procedure, the following configuration parameters are used:

  1. Add entries to kdc.conf.

    You need to enable incremental propagation and select the number of updates the KDC master keeps in the log. See the kdc.conf(4) man page for more information.


    kdc1 # cat /etc/krb5/kdc.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM= {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
                    sunw_dbprop_master_ulogsize = 1000
            }
  2. Create the kiprop principal.

    The kiprop principal is used to authenticate the master KDC server and to authorize updates from the master KDC.


    kdc1 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: addprinc -randkey kiprop/kdc1.example.com
    Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
    kadmin: addprinc -randkey kiprop/kdc2.example.com
    Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.
    kadmin:
  3. On the master KDC, add a kiprop entry to kadm5.acl

    This entry allows the master KDC to receive requests for incremental propagation from the kdc2 server.


    kdc1 # cat /etc/krb5/kadm5.acl
    */admin@EXAMPLE.COM *
    kiprop/kdc2.example.com@EXAMPLE.COM p
    
  4. Comment out the kprop line in the root crontab file.

    This step prevents the master KDC from propagating its copy of the KDC database.


    kdc1 # crontab -e
    #ident  "@(#)root       1.20    01/11/06 SMI"
    #
    # The root crontab should be used to perform accounting data collection.
    #
    # The rtc command is run to adjust the real time clock if and when
    # daylight savings time changes.
    #
    10 3 * * * /usr/sbin/logadm
    15 3 * * 0 /usr/lib/fs/nfs/nfsfind
    1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
    30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
    #10 3 * * * /usr/lib/krb5kprop_script kdc2.example.sun.com #SUNWkr5ma
  5. Restart kadmind.


    kdc1 # svcadm restart network/security/kadmin
    
  6. Reconfigure all slave KDC servers that use incremental propagation.

    See How to Reconfigure a Slave KDC to Use Incremental Propagation for complete instructions.

ProcedureHow to Reconfigure a Slave KDC to Use Incremental Propagation

  1. Add entries to krb5.conf.

    The new entries enable incremental propagation and set the poll time to 2 minutes.


    kdc2 # cat /etc/krb5/krb5.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM= {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
                    sunw_dbprop_slave_poll = 2m
            }
  2. Add the kiprop principal to the krb5.keytab file.


    kdc2 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: ktadd kiprop/kdc2.example.com
    Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-256 CTS mode
              with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type AES-128 CTS mode
              with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type Triple DES cbc
              mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
              with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
              with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    kadmin: quit
    
  3. Restart kpropd.


    kdc2 # svcadm restart network/security/krb5_prop
    

ProcedureHow to Configure a Slave KDC to Use Full Propagation

This procedure shows how to reconfigure a slave KDC server running the Solaris 10 release to use full propagation. Normally, the procedure would only need to be used if the master KDC server is running either the Solaris 9 release or an earlier release. In this case, the master KDC server can not support incremental propagation, so the slave needs to be configured to allow propagation to work.

In this procedure, a slave KDC named kdc3 is configured. This procedure uses the following configuration parameters:

Before You Begin

The master KDC must be configured. For specific instructions if this slave is to be swappable, see Swapping a Master KDC and a Slave KDC.

  1. On the master KDC, become superuser.

  2. On the master KDC, start kadmin.

    You must log in with one of the admin principal names that you created when you configured the master KDC.


    kdc1 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. On the master KDC, add slave host principals to the database, if not already done.

      For the slave to function, it must have a host principal. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: addprinc -randkey host/kdc3.example.com
      Principal "host/kdc3@EXAMPLE.COM" created.
      kadmin: 
    2. Quit kadmin.


      kadmin: quit
      
  3. On the master KDC, edit the Kerberos configuration file (krb5.conf).

    You need to add an entry for each slave. See the krb5.conf(4) man page for a full description of this file.


    kdc1 # cat /etc/krb5/krb5.conf
     .
     .
    [realms]
                    EXAMPLE.COM = {
                    kdc = kdc1.example.com
                    kdc = kdc2.example.com
                    kdc = kdc3.example.com
                    admin_server = kdc1.example.com
            }
  4. On the master KDC, add an entry for the master KDC and each slave KDC into the kpropd.acl file.

    See the kprop(1M) man page for a full description of this file.


    kdc1 # cat /etc/krb5/kpropd.acl
    host/kdc1.example.com@EXAMPLE.COM
    host/kdc2.example.com@EXAMPLE.COM
    host/kdc3.example.com@EXAMPLE.COM
    
  5. On all slave KDCs, copy the KDC administration files from the master KDC server.

    This step needs to be followed on all slave KDCs, because the master KDC server has updated information that each KDC server needs. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master KDC:

    • /etc/krb5/krb5.conf

    • /etc/krb5/kdc.conf

    • /etc/krb5/kpropd.acl

  6. On all slave KDCs, make sure that the Kerberos access control list file, kadm5.acl, is not populated.

    An unmodified kadm5.acl file would look like:


    kdc2 # cat /etc/krb5/kadm5.acl
    */admin@___default_realm___ *

    If the file has kiprop entries, remove them.

  7. On the new slave, start the kadmin command.

    You must log in with one of the admin principal names that you created when you configured the master KDC.


    kdc2 # /usr/sbin/kadmin -p kws/admin
    Enter password: <Type kws/admin password>
    kadmin: 
    1. Add the slave's host principal to the slave's keytab file by using kadmin.

      This entry allows kprop and other Kerberized applications to function. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.


      kadmin: ktadd host/kdc3.example.com
      Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc3.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc3.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc3.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal host/kdc3.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin: 
    2. Quit kadmin.


      kadmin: quit
      
  8. On the master KDC, add the slave KDC name to the cron job, which automatically runs the backups, by running crontab -e.

    Add the name of each slave KDC server at the end of the kprop_script line.


    10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com
    

    You might also want to change the time of the backups. This entry starts the backup process every day at 3:10 AM.

  9. On the new slave, start the Kerberos propagation daemon.


    kdc3 # svcadm enable network/security/krb5_prop
    
  10. On the master KDC, back up and propagate the database by using kprop_script.

    If a backup copy of the database is already available, it is not necessary to complete another backup. See How to Manually Propagate the Kerberos Database to the Slave KDCs for further instructions.


    kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com
    Database propagation to kdc3.example.com: SUCCEEDED
  11. On the new slave, create a stash file by using kdb5_util.


    kdc3 # /usr/sbin/kdb5_util stash
    kdb5_util: Cannot find/read stored master key while reading master key
    kdb5_util: Warning: proceeding without master key
    
    Enter KDC database master key: <Type the key>
    
  12. (Optional) On the new slave KDC, synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.

    Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

  13. On the new slave, start the KDC daemon (krb5kdc).


    kdc3 # svcadm enable network/security/krb5kdc
    

ProcedureHow to Verify That the KDC Servers Are Synchronized

If incremental propagation has been configured, this procedure ensures that the information on the slave KDC has been updated.

  1. On the KDC master server, run the kproplog command.


    kdc1 # /usr/sbin/kproplog -h
    
  2. On a KDC slave server, run the kproplog command.


    kdc2 # /usr/sbin/kproplog -h
    
  3. Check that the last serial # and the last timestamp values match.


Example 23–17 Verifying That the KDC Servers Are Synchronized

The following is a sample of results from running the kproplog command on the master KDC server.


kdc1 # /usr/sbin/kproplog -h

Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
    Log version #: 1
    Log state: Stable
    Entry block size: 2048
    Number of entries: 2500
    First serial #: 137966
    Last serial #: 140465
    First time stamp: Fri Nov 28 00:59:27 2004
    Last time stamp: Fri Nov 28 01:06:13 2004

The following is a sample of results from running the kproplog command on a slave KDC server.


kdc2 # /usr/sbin/kproplog -h

Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
    Log version #: 1
    Log state: Stable
    Entry block size: 2048
    Number of entries: 0
    First serial #: None
    Last serial #: 140465
    First time stamp: None
    Last time stamp: Fri Nov 28 01:06:13 2004

Notice that the values for the last serial number and the last timestamp are identical, which indicates that the slave is synchronized with the master KDC server.

In the slave KDC server output, notice that no update entries exist in the slave KDC server's update log. No entries exist because the slave KDC server does not keep a set of updates, unlike the master KDC server. Also, the KDC slave server does not include information on the first serial number or the first timestamp because this is not relevant information.


ProcedureHow to Manually Propagate the Kerberos Database to the Slave KDCs

This procedure shows you how to propagate the Kerberos database by using the kprop command. Use this procedure if you need to synchronize a slave KDC with the master KDC outside the periodic cron job. Unlike the kprop_script, you can use kprop to propagate just the current database backup without first making a new backup of the Kerberos database.


Note –

Do not use this procedure if you are using incremental propagation.


  1. Become superuser on the master KDC.

  2. (Optional) Back up the database by using the kdb5_util command.


    # /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans
    
  3. Propagate the database to a slave KDC by using the kprop command.


    # /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC
    

Example 23–18 Manually Propagating the Kerberos Database to the Slave KDCs Using kprop_script

If you want to back up the database and propagate it to a slave KDC outside the periodic cron job, you can also use the kprop_script command as follows:


# /usr/lib/krb5/kprop_script slave-KDC

Setting Up Parallel Propagation

In most cases, the master KDC is used exclusively to propagate its Kerberos database to the slave KDCs. However, if your site has many slave KDCs, you might consider load-sharing the propagation process, known as parallel propagation.


Note –

Do not use this procedure if you are using incremental propagation.


Parallel propagation allows specific slave KDCs to share the propagation duties with the master KDC. This sharing of duties enables the propagation to be done faster and to lighten the work for the master KDC.

For example, say your site has one master KDC and six slave KDCs (shown in Figure 23–2), where slave-1 through slave-3 consist of one logical grouping and slave-4 through slave-6 consist of another logical grouping. To set up parallel propagation, you could have the master KDC propagate the database to slave-1 and slave-4. In turn, those KDC slaves could propagate the database to the KDC slaves in their group.

Figure 23–2 Example of Parallel Propagation Configuration

Diagram shows a master KDC with two propagation slaves.
Each propagation slave propagates to its slaves the master KDC database.

Configuration Steps for Setting Up Parallel Propagation

The following is not a detailed step-by-step procedure, but a high-level list of configuration steps to enable parallel propagation. These steps involve the following:

  1. On the master KDC, changing the kprop_script entry in its cron job to include arguments for only the KDC slaves that will perform the succeeding propagation (the propagation slaves).

  2. On each propagation slave, adding a kprop_script entry to its cron job, which must include arguments for the slaves to propagate. To successfully propagate in parallel, the cron job should be set up to run after the propagation slave is itself propagated with the new Kerberos database.


    Note –

    How long it will take for a propagation slave to be propagated depends on factors such as network bandwidth and the size of the Kerberos database.


  3. On each slave KDC, setting up the appropriate permissions to be propagated. This step is done by adding the host principal name of its propagating KDC to its kpropd.acl file.


Example 23–19 Setting Up Parallel Propagation

Using the example in Figure 23–2, the master KDC's kprop_script entry would look similar to the following:


0 3 * * * /usr/lib/krb5/kprop_script slave-1.example.com slave-4.example.com

The slave-1's kprop_script entry would look similar to the following:


0 4 * * * /usr/lib/krb5/kprop_script slave-2.example.com slave-3.example.com

Note that the propagation on the slave starts an hour after it is propagated by the master.

The kpropd.acl file on the propagation slaves would contain the following entry:


host/master.example.com@EXAMPLE.COM

The kpropd.acl file on the KDC slaves being propagated by slave-1 would contain the following entry:


host/slave-1.example.com@EXAMPLE.COM

Administering the Stash File

The stash file contains the master key for the Kerberos database, which is automatically created when you create a Kerberos database. If the stash file gets corrupted, you can use the stash command of the kdb5_util utility to replace the corrupted file. The only time you should need to remove a stash file is after removing the Kerberos database with the destroy command of kdb5_util. Because the stash file is not automatically removed with the database, you have to remove the stash file to finish the cleanup.

ProcedureHow to Remove a Stash File

  1. Become superuser on the KDC that contains the stash file.

  2. Remove the stash file.


    # rm stash-file
    

    Where stash-file is the path to the stash file. By default, the stash file is located at /var/krb5/.k5.realm.


    Note –

    If you need to re-create the stash file, you can use the -f option of the kdb5_util command.


Managing a KDC on an LDAP Directory Server

Most of the KDC administration tasks using an LDAP Directory Server are the same as those for the DB2 server. There are some new tasks that are specific to working with LDAP.

Table 23–3 Configuring KDC Servers to Use LDAP (Task Map)

Task 

Description 

For Instructions 

Configuring a Master KDC 

Configures and builds the master KDC server and database for a realm using a manual process and using LDAP for the KDC. 

How to Configure a KDC to Use an LDAP Data Server

Mix Kerberos principal attributes with non-Kerberos object class types. 

Allows information stored with the Kerberos records to be shared with other LDAP databases. 

How to Mix Kerberos Principal Attributes in a Non-Kerberos Object Class Type

Destroy a Realm 

Removes all of the data associated with a realm 

How to Destroy a Realm on an LDAP Directory Server

ProcedureHow to Mix Kerberos Principal Attributes in a Non-Kerberos Object Class Type

This procedure allows for Kerberos principal attributes to be associated with non-Kerberos object class types. In this procedure the krbprincipalaux, and krbTicketPolicyAux and krbPrincipalName attributes are associated with the people object class.

In this procedure, the following configuration parameters are used:

  1. Become superuser.

  2. Prepare each entry in the people object class.

    Repeat this step for each entry.


    cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager"
    dn: uid=willf,ou=people,dc=example,dc=com
    changetype: modify
    objectClass: krbprincipalaux
    objectClass: krbTicketPolicyAux
    krbPrincipalName: willf@EXAMPLE.COM
    EOF
  3. Add a subtree attribute to the realm container.

    This step allows for searching of principal entries in the ou=people,dc=example,dc=com container, as well as in the default EXAMPLE.COM container.


    # kdb5_ldap_util -D "cn=directory manager" modify \
                -subtrees 'ou=people,dc=example,dc=com' -r EXAMPLE.COM
    
  4. (Optional) If the KDC records are stored in DB2, migrate DB2 entries.

    1. Dump the DB2 entries.


      # kdb5_util dump > dumpfile
      
    2. Load the database into the LDAP server.


      # kdb5_util load -update dumpfile
      
  5. (Optional) Add the principal attributes to the KDC.


    # kadmin.local -q 'addprinc willf'

ProcedureHow to Destroy a Realm on an LDAP Directory Server

This procedure can be used if a different LDAP Directory Server has been configured to handle a realm.

  1. Become superuser.

  2. Destroy the realm.


    # kdb5_ldap_util -D "cn=directory manager" destroy
    

Increasing Security on Kerberos Servers

Follow these steps to increase security on Kerberos application servers and on KDC servers.

Table 23–4 Increasing Security on Kerberos Servers (Task Map)

Task 

Description 

For Instructions 

Enabling access using Kerberos authentication 

Restrict network access to a server to allow Kerberos authentication only 

How to Enable Only Kerberized Applications

Restricting access to the KDC servers 

Increases the security of the KDC servers and their data. 

How to Restrict Access to KDC Servers

Increasing password security by using a dictionary file 

Increases the security of any new passwords by checking the new password against a dictionary. 

How to Use a Dictionary File to Increase Password Security

ProcedureHow to Enable Only Kerberized Applications

This procedure restricts network access to the server that is running telnet, ftp, rcp, rsh, and rlogin to use Kerberos authenticated transactions only.

  1. Change the exec property for the telnet service.

    Add the -a user option to the exec property for telnet to restrict access to those users who can provide valid authentication information.


    # inetadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user"
  2. (Optional) If not already configured, change the exec property for the telnet service.

    Add the -a option to the exec property for ftp to permit only Kerberos authenticated connections.


    # inetadm -m svc:/network/ftp:default exec="/usr/sbin/in.ftpd -a"
  3. Disable other services.

    The in.rshd and in.rlogind daemons should be disabled.


    # svcadm disable network/shell
    # svcadm disable network/login:rlogin
    

ProcedureHow to Restrict Access to KDC Servers

Both master KDC servers and slave KDC servers have copies of the KDC database stored locally. Restricting access to these servers so that the databases are secure is important to the overall security of the Kerberos installation.

  1. Disable remote services, as needed.

    To provide a secure KDC server, all nonessential network services should be disabled . Depending on your configuration, some of these services may already be disabled. Check the service status with the svcs command. In most circumstances, the only services that would need to run would be krb5kdc and krdb5_kprop if the KDC is a slave or only kadmin if the KDC is a master. In addition, any services that use loopback tli (ticlts, ticotsord, and ticots) can be left enabled.


    # svcadm disable network/comsat
    # svcadm disable network/dtspc/tcp
    # svcadm disable network/finger
    # svcadm disable network/login:rlogin
    # svcadm disable network/rexec
    # svcadm disable network/shell
    # svcadm disable network/talk
    # svcadm disable network/tname
    # svcadm disable network/uucp
    # svcadm disable network/rpc_100068_2-5/rpc_udp
    
  2. Restrict access to the hardware that supports the KDC.

    To restrict physical access, make sure that the KDC server and its monitor are located in a secure facility. Users should not be able to access this server in any way.

  3. Store KDC database backups on local disks or on the KDC slaves.

    Make tape backups of your KDC only if the tapes are stored securely. Follow the same practice for copies of keytab files. It would be best to store these files on a local file system that is not shared with other systems. The storage file system can be on either the master KDC server or any of the slave KDCs.

ProcedureHow to Use a Dictionary File to Increase Password Security

A dictionary file can be used by the Kerberos service to prevent words in the dictionary from being used as passwords when creating new credentials. Preventing the use of dictionary terms as passwords makes it harder for someone else to guess any password. By default the /var/krb5/kadm5.dict file is used, but it is empty.

  1. Become superuser on the master KDC.

  2. Edit the KDC configuration file (kdc.conf).

    You need add a line to instruct the service to use a dictionary file. In this example, the dictionary that is included with the spell utility is used. See the kdc.conf(4) man page for a full description of the configuration file.


    kdc1 # cat /etc/krb5/kdc.conf
    [kdcdefaults]
            kdc_ports = 88,750
    
    [realms]
            EXAMPLE.COM = {
                    profile = /etc/krb5/krb5.conf
                    database_name = /var/krb5/principal
                    acl_file = /etc/krb5/kadm5.acl
                    kadmind_port = 749
                    max_life = 8h 0m 0s
                    max_renewable_life = 7d 0h 0m 0s
                    sunw_dbprop_enable = true
                    sunw_dbprop_master_ulogsize = 1000
                    dict_file = /usr/share/lib/dict/words
                    }
  3. Restart the Kerberos daemons.


    kdc1 # svcadm restart -r network/security/krb5kdc
    kdc1 # svcadm restart -r network/security/kadmin
    

Chapter 24 Kerberos Error Messages and Troubleshooting

This chapter provides resolutions for error messages that you might receive when you use the Kerberos service. This chapter also provides some troubleshooting tips for various problems. This is a list of the error message and troubleshooting information in this chapter.

Kerberos Error Messages

This section provides information about Kerberos error messages, including why each error occurs and a way to fix it.

SEAM Administration Tool Error Messages


Unable to view the list of principals or policies; use the Name field.

Cause:

The admin principal that you logged in with does not have the list privilege (l) in the Kerberos ACL file (kadm5.acl). So, you cannot view the principal list or policy list.

Solution:

You must type the principal and policy names in the Name field to work on them, or you need to log in with a principal that has the appropriate privileges.


JNI: Java array creation failed


JNI: Java class lookup failed


JNI: Java field lookup failed


JNI: Java method lookup failed


JNI: Java object lookup failed


JNI: Java object field lookup failed


JNI: Java string access failed


JNI: Java string creation failed

Cause:

A serious problem exists with the Java Native Interface that is used by the SEAM Administration Tool (gkadmin).

Solution:

Exit gkadmin and restart it. If the problem persists, please report a bug.

Common Kerberos Error Messages (A-M)

This section provides an alphabetical list (A-M) of common error messages for the Kerberos commands, Kerberos daemons, PAM framework, GSS interface, the NFS service, and the Kerberos library.


All authentication systems disabled; connection refused

Cause:

This version of rlogind does not support any authentication mechanism.

Solution:

Make sure that rlogind is invoked with the -k option.


Another authentication mechanism must be used to access this host

Cause:

Authentication could not be done.

Solution:

Make sure that the client is using Kerberos V5 mechanism for authentication.


Authentication negotiation has failed, which is required for encryption. Good bye.

Cause:

Authentication could not be negotiated with the server.

Solution:

Start authentication debugging by invoking the telnet command with the toggle authdebug command and look at the debug messages for further clues. Also, make sure that you have valid credentials.


Bad krb5 admin server hostname while initializing kadmin interface

Cause:

An invalid host name is configured for admin_server in the krb5.conf file.

Solution:

Make sure that the correct host name for the master KDC is specified on the admin_server line in the krb5.conf file.


Bad lifetime value

Cause:

The lifetime value provided is not valid or incorrectly formatted.

Solution:

Make sure that the value provided is consistent with the Time Formats section in the kinit(1) man page.


Bad start time value

Cause:

The start time value provided is not valid or incorrectly formatted.

Solution:

Make sure that the value provided is consistent with the Time Formats section in the kinit(1) man page.


Cannot contact any KDC for requested realm

Cause:

No KDC responded in the requested realm.

Solution:

Make sure that at least one KDC (either the master or a slave) is reachable or that the krb5kdc daemon is running on the KDCs. Check the /etc/krb5/krb5.conf file for the list of configured KDCs (kdc = kdc-name).


Cannot determine realm for host

Cause:

Kerberos cannot determine the realm name for the host.

Solution:

Make sure that there is a default realm name, or that the domain name mappings are set up in the Kerberos configuration file (krb5.conf).


Cannot find KDC for requested realm

Cause:

No KDC was found in the requested realm.

Solution:

Make sure that the Kerberos configuration file (krb5.conf) specifies a KDC in the realm section.


cannot initialize realm realm-name

Cause:

The KDC might not have a stash file.

Solution:

Make sure that the KDC has a stash file. If not, create a stash file by using the kdb5_util command, and try restarting the krb5kdc command.


Cannot resolve KDC for requested realm

Cause:

Kerberos cannot determine any KDC for the realm.

Solution:

Make sure that the Kerberos configuration file (krb5.conf) specifies a KDC in the realm section.


Cannot reuse password

Cause:

The password that you specified has been used before by this principal.

Solution:

Choose a password that has not been chosen before, at least not within the number of passwords that are kept in the KDC database for each principal. This policy is enforced by the principal's policy.


Can't get forwarded credentials

Cause:

Credential forwarding could not be established.

Solution:

Make sure that the principal has forwardable credentials.


Can't open/find Kerberos configuration file

Cause:

The Kerberos configuration file (krb5.conf) was unavailable.

Solution:

Make sure that the krb5.conf file is available in the correct location and has the correct permissions. This file should be writable by root and readable by everyone else.


Client did not supply required checksum--connection rejected

Cause:

Authentication with checksum was not negotiated with the client. The client might be using an old Kerberos V5 protocol that does not support initial connection support.

Solution:

Make sure that the client is using a Kerberos V5 protocol that supports initial connection support.


Client/server realm mismatch in initial ticket request

Cause:

A realm mismatch between the client and server occurred in the initial ticket request.

Solution:

Make sure that the server you are communicating with is in the same realm as the client, or that the realm configurations are correct.


Client or server has a null key

Cause:

The principal has a null key.

Solution:

Modify the principal to have a non-null key by using the cpw command of kadmin.


Communication failure with server while initializing kadmin interface

Cause:

The host that was specified for the admin server, also called the master KDC, did not have the kadmind daemon running.

Solution:

Make sure that you specified the correct host name for the master KDC. If you specified the correct host name, make sure that kadmind is running on the master KDC that you specified.


Credentials cache file permissions incorrect

Cause:

You do not have the appropriate read or write permissions on the credentials cache (/tmp/krb5cc_uid).

Solution:

Make sure that you have read and write permissions on the credentials cache.


Credentials cache I/O operation failed XXX

Cause:

Kerberos had a problem writing to the system's credentials cache (/tmp/krb5cc_uid).

Solution:

Make sure that the credentials cache has not been removed, and that there is space left on the device by using the df command.


Decrypt integrity check failed

Cause:

You might have an invalid ticket.

Solution:

Verify both of these conditions:

  • Make sure that your credentials are valid. Destroy your tickets with kdestroy, and create new tickets with kinit.

  • Make sure that the target host has a keytab file with the correct version of the service key. Use kadmin to view the key version number of the service principal (for example, host/FQDN-hostname) in the Kerberos database. Also, use klist -k on the target host to make sure that it has the same key version number.


Encryption could not be enabled. Goodbye.

Cause:

Encryption could not be negotiated with the server.

Solution:

Start authentication debugging by invoking the telnet command with the toggle encdebug command and look at the debug messages for further clues.


failed to obtain credentials cache

Cause:

During kadmin initialization, a failure occurred when kadmin tried to obtain credentials for the admin principal.

Solution:

Make sure that you used the correct principal and password when you executed kadmin.


Field is too long for this implementation

Cause:

The message size that was being sent by a Kerberized application was too long. This error could be generated if the transport protocol is UDP. which has a default maximum message size 65535 bytes. In addition, there are limits on individual fields within a protocol message that is sent by the Kerberos service.

Solution:

Verify that you have not restricted the transport to UDP in the KDC server's /etc/krb5/kdc.conf file.


GSS-API (or Kerberos) error

Cause:

This message is a generic GSS-API or Kerberos error message and can be caused by several different problems.

Solution:

Check the /var/krb5/kdc.log file to find the more specific error message that was logged when this error occurred.


Hostname cannot be canonicalized

Cause:

Kerberos cannot make the host name fully qualified.

Solution:

Make sure that the host name is defined in DNS and that the host-name-to-address and address-to-host-name mappings are consistent.


Illegal cross-realm ticket

Cause:

The ticket sent did not have the correct cross-realms. The realms might not have the correct trust relationships set up.

Solution:

Make sure that the realms you are using have the correct trust relationships.


Improper format of Kerberos configuration file

Cause:

The Kerberos configuration file has invalid entries.

Solution:

Make sure that all the relations in the krb5.conf file are followed by the “=” sign and a value. Also, verify that the brackets are present in pairs for each subsection.


Inappropriate type of checksum in message

Cause:

The message contained an invalid checksum type.

Solution:

Check which valid checksum types are specified in the krb5.conf and kdc.conf files.


Incorrect net address

Cause:

There was a mismatch in the network address. The network address in the ticket that was being forwarded was different from the network address where the ticket was processed. This message might occur when tickets are being forwarded.

Solution:

Make sure that the network addresses are correct. Destroy your tickets with kdestroy, and create new tickets with kinit.


Invalid credential was supplied


Service key not available

Cause:

The service ticket in the credentials cache may be incorrect.

Solution:

Destroy current credential cache and rerun kinit before trying to use this service.


Invalid flag for file lock mode

Cause:

An internal Kerberos error occurred.

Solution:

Please report a bug.


Invalid message type specified for encoding

Cause:

Kerberos could not recognize the message type that was sent by the Kerberized application.

Solution:

If you are using a Kerberized application that was developed by your site or a vendor, make sure that it is using Kerberos correctly.


Invalid number of character classes

Cause:

The password that you specified for the principal does not contain enough password classes, as enforced by the principal's policy.

Solution:

Make sure that you specify a password with the minimum number of password classes that the policy requires.


KADM err: Memory allocation failure

Cause:

There is insufficient memory to run kadmin.

Solution:

Free up memory and try running kadmin again.


kadmin: Bad encryption type while changing host/<FQDN>'s key

Cause:

More default encryption types are included in the base release in the Solaris 10 8/07 release. Clients can request encryption types that may not be supported by a KDC running an older version of the Solaris software.

Solution:

Several solutions exist to fix this problem. The easiest one to implement is listed first:

  1. Add the SUNWcry and SUNWcryr packages to the KDC server. This increases the number of encryption types supported by the KDC.

  2. Set permitted_enctypes in krb5.conf on the client to not include the aes256 encryption type. This step will need to be done on each new client.


KDC can't fulfill requested option

Cause:

The KDC did not allow the requested option. A possible problem might be that postdating or forwardable options were being requested, and the KDC did not allow them. Another problem might be that you requested the renewal of a TGT, but you didn't have a renewable TGT.

Solution:

Determine if you are either requesting an option that the KDC does not allow or a type of ticket that is not available.


KDC policy rejects request

Cause:

The KDC policy did not allow the request. For example, the request to the KDC did not have an IP address in its request. Or forwarding was requested, but the KDC did not allow it.

Solution:

Make sure that you are using kinit with the correct options. If necessary, modify the policy that is associated with the principal or change the principal's attributes to allow the request. You can modify the policy or principal by using kadmin.


KDC reply did not match expectations

Cause:

The KDC reply did not contain the expected principal name, or other values in the response were incorrect.

Solution:

Make sure that the KDC you are communicating with complies with RFC1510, that the request you are sending is a Kerberos V5 request, or that the KDC is available.


kdestroy: Could not obtain principal name from cache

Cause:

The credentials cache is missing or corrupted.

Solution:

Check that the cache location provided is correct. Remove and obtain a new TGT using kinit, if necessary.


kdestroy: No credentials cache file found while destroying cache

Cause:

The credentials cache (/tmp/krb5c_uid) is missing or corrupted.

Solution:

Check that the cache location provided is correct. Remove and obtain a new TGT using kinit, if necessary.


kdestroy: TGT expire warning NOT deleted

Cause:

The credentials cache is missing or corrupted.

Solution:

Check that the cache location provided is correct. Remove and obtain a new TGT using kinit, if necessary.


Kerberos authentication failed

Cause:

The Kerberos password is either incorrect or the password might not be synchronized with the UNIX password.

Solution:

If the password are not synchronized, then you must specify a different password to complete Kerberos authentication. It is possible that the user has forgotten their original password.


Kerberos V5 refuses authentication

Cause:

Authentication could not be negotiated with the server.

Solution:

Start authentication debugging by invoking the telnet command with the toggle authdebug command and look at the debug messages for further clues. Also, make sure that you have valid credentials.


Key table entry not found

Cause:

No entry exists for the service principal in the network application server's keytab file.

Solution:

Add the appropriate service principal to the server's keytab file so that it can provide the Kerberized service.


Key version number for principal in key table is incorrect

Cause:

A principal's key version in the keytab file is different from the version in the Kerberos database. Either a service's key has been changed, or you might be using an old service ticket.

Solution:

If a service's key has been changed (for example, by using kadmin), you need to extract the new key and store it in the host's keytab file where the service is running.

Alternately, you might be using an old service ticket that has an older key. You might want to run the kdestroy command and then the kinit command again.


kinit: gethostname failed

Cause:

An error in the local network configuration is causing kinit to fail.

Solution:

Make sure that the host is configured correctly.


login: load_modules: can not open module /usr/lib/security/pam_krb5.so.1

Cause:

Either the Kerberos PAM module is missing or it is not a valid executable binary.

Solution:

Make sure that the Kerberos PAM module is in the /usr/lib/security directory and that it is a valid executable binary. Also, make sure that the /etc/pam.conf file contains the correct path to pam_krb5.so.1.


Looping detected inside krb5_get_in_tkt

Cause:

Kerberos made several attempts to get the initial tickets but failed.

Solution:

Make sure that at least one KDC is responding to authentication requests.


Master key does not match database

Cause:

The loaded database dump was not created from a database that contains the master key. The master key is located in /var/krb5/.k5.REALM.

Solution:

Make sure that the master key in the loaded database dump matches the master key that is located in /var/krb5/.k5.REALM.


Matching credential not found

Cause:

The matching credential for your request was not found. Your request requires credentials that are unavailable in the credentials cache.

Solution:

Destroy your tickets with kdestroy, and create new tickets with kinit.


Message out of order

Cause:

Messages that were sent using sequential-order privacy arrived out of order. Some messages might have been lost in transit.

Solution:

You should reinitialize the Kerberos session.


Message stream modified

Cause:

There was a mismatch between the computed checksum and the message checksum. The message might have been modified while in transit, which can indicate a security leak.

Solution:

Make sure that the messages are being sent across the network correctly. Because this message can also indicate the possible tampering of messages while they are being sent, destroy your tickets using kdestroy and reinitialize the Kerberos services that you are using.

Common Kerberos Error Messages (N-Z)

This section provides an alphabetical list (N-Z) of common error messages for the Kerberos commands, Kerberos daemons, PAM framework, GSS interface, the NFS service, and the Kerberos library.


No credentials cache file found

Cause:

Kerberos could not find the credentials cache (/tmp/krb5cc_uid).

Solution:

Make sure that the credential file exists and is readable. If it isn't, try performing kinit again.


No credentials were supplied, or the credentials were unavailable or inaccessible


No credential cache found

Cause:

The user's credential cache is incorrect or does not exist.

Solution:

The user should run kinit before trying to start the service.


No credentials were supplied, or the credentials were unavailable or inaccessible


No principal in keytab matches desired name

Cause:

An error occurred while trying to authenticate the server.

Solution:

Make sure that the host or service principal is in the server's keytab file.


Operation requires “privilege” privilege

Cause:

The admin principal that was being used does not have the appropriate privilege configured in the kadm5.acl file.

Solution:

Use a principal that has the appropriate privileges. Or, configure the principal that was being used to have the appropriate privileges by modifying the kadm5.acl file. Usually, a principal with /admin as part of its name has the appropriate privileges.


PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found

Cause:

The remote application tried to read the host's service principal in the local /etc/krb5/krb5.keytab file, but one does not exist.

Solution:

Add the host's service principal to the host's keytab file.


Password is in the password dictionary

Cause:

The password that you specified is in a password dictionary that is being used. Your password is not a good choice for a password.

Solution:

Choose a password that has a mix of password classes.


Permission denied in replay cache code

Cause:

The system's replay cache could not be opened. Your server might have been first run under a user ID different than your current user ID.

Solution:

Make sure that the replay cache has the appropriate permissions. The replay cache is stored on the host where the Kerberized server application is running. The replay cache file is called /var/krb5/rcache/rc_service_name_uid for non-root users. For root users the replay cache file is called /var/krb5/rcache/root/rc_service_name.


Protocol version mismatch

Cause:

Most likely, a Kerberos V4 request was sent to the KDC. The Kerberos service supports only the Kerberos V5 protocol.

Solution:

Make sure that your applications are using the Kerberos V5 protocol.


Request is a replay

Cause:

The request has already been sent to this server and processed. The tickets might have been stolen, and someone else is trying to reuse the tickets.

Solution:

Wait for a few minutes, and reissue the request.


Requested principal and ticket don't match

Cause:

The service principal that you are connecting to and the service ticket that you have do not match.

Solution:

Make sure that DNS is functioning properly. If you are using another vendor's software, make sure that the software is using principal names correctly.


Requested protocol version not supported

Cause:

Most likely, a Kerberos V4 request was sent to the KDC. The Kerberos service supports only the Kerberos V5 protocol.

Solution:

Make sure that your applications are using the Kerberos V5 protocol.


Server refused to negotiate authentication, which is required for encryption. Good bye.

Cause:

The remote application is not capable or has been configured not to accept Kerberos authentication from the client.

Solution:

Provide a remote application that can negotiate authentication or configure the application to use the appropriate flags to turn on authentication.


Server refused to negotiate encryption. Good bye.

Cause:

Encryption could not be negotiated with the server.

Solution:

Start authentication debugging by invoking the telnet command with the toggle encdebugcommand and look at the debug messages for further clues.


Server rejected authentication (during sendauth exchange)

Cause:

The server that you are trying to communicate with rejected the authentication. Most often, this error occurs during Kerberos database propagation. Some common causes might be problems with the kpropd.acl file, DNS, or the keytab file.

Solution:

If you get this error when you are running applications other than kprop, investigate whether the server's keytab file is correct.


The ticket isn't for us


Ticket/authenticator don't match

Cause:

There was a mismatch between the ticket and the authenticator. The principal name in the request might not have matched the service principal's name. Either because the ticket was being sent with an FQDN name of the principal while the service expected a non-FQDN name, or a non-FDQN name was sent when the service expected an FQDN name.

Solution:

If you get this error when you are running applications other than kprop, investigate whether the server's keytab file is correct.


Ticket expired

Cause:

Your ticket times have expired.

Solution:

Destroy your tickets with kdestroy, and create new tickets with kinit.


Ticket is ineligible for postdating

Cause:

The principal does not allow its tickets to be postdated.

Solution:

Modify the principal with kadmin to allow postdating.


Ticket not yet valid

Cause:

The postdated ticket is not valid yet.

Solution:

Create a new ticket with the correct date, or wait until the current ticket is valid.


Truncated input file detected

Cause:

The database dump file that was being used in the operation is not a complete dump file.

Solution:

Create the dump file again, or use a different database dump file.


Unable to securely authenticate user ... exit

Cause:

Authentication could not be negotiated with the server.

Solution:

Start authentication debugging by invoking the telnet command with the toggle authdebug command and look at the debug messages for further clues. Also, make sure that you have valid credentials.


Wrong principal in request

Cause:

There was an invalid principal name in the ticket. This error might indicate a DNS or FQDN problem.

Solution:

Make sure that the principal of the service matches the principal in the ticket.

Kerberos Troubleshooting

This section provides troubleshooting information for the Kerberos software.

Problems With the Format of the krb5.conf File

If the krb5.conf file is not formatted properly, the telnet command will fail. However, the dtlogin and login commands will still succeed, even if the krb5.conf file is specified as required for the commands. If this problem occurs, the following error message is displayed:


Error initializing krb5: Improper format of Kerberos configuration

In addition, an incorrectly formatted krb5.conf file, prevents the applications that use the GSSAPI from using the krb5 mechanisms.

If there is a problem with the format of the krb5.conf file, you are vulnerable to security breaches. You should fix the problem before you allow Kerberos features to be used.

Problems Propagating the Kerberos Database

If propagating the Kerberos database fails, try /usr/bin/rlogin -x between the slave KDC and master KDC, and from the master KDC to the slave KDC server.

If the KDCs have been set up to restrict access, rlogin is disabled and cannot be used to troubleshoot this problem. To enable rlogin on a KDC, you must enable the eklogin service.


# svcadm enable svc:/network/login:eklogin

After you finish troubleshooting the problem, you need to disable the eklogin service..

If rlogin does not work, problems are likely because of the keytab files on the KDCs. If rlogin does work, the problem is not in the keytab file or the name service, because rlogin and the propagation software use the same host/host-name principal. In this case, make sure that the kpropd.acl file is correct.

Problems Mounting a Kerberized NFS File System

In this example, the setup allows one reference to the different interfaces and a single service principal instead of three service principals in the server's keytab file.

Problems Authenticating as root

If authentication fails when you try to become superuser on your system and you have already added the root principal to your host's keytab file, there are two potential problems to check. First, make sure that the root principal in the keytab file has a fully qualified host name as its instance. If it does, check the /etc/resolv.conf file to make sure that the system is correctly set up as a DNS client.

Observing Mapping from GSS Credentials to UNIX Credentials

To be able to monitor the credential mappings, first uncomment this line from the /etc/gss/gsscred.conf file.


SYSLOG_UID_MAPPING=yes

Next instruct the gssd service to get information from the /etc/gss/gsscred.conf file.


# pkill -HUP gssd

Now you should be able to monitor the credential mappings as gssd requests them. The mappings are recorded by syslogd, if the syslog.conf file is configured for the auth system facility with the debug severity level.

Chapter 25 Administering Kerberos Principals and Policies (Tasks)

This chapter provides procedures for administering principals and the policies that are associated with them. This chapter also shows how to administer a host's keytab file.

This chapter should be used by anyone who needs to administer principals and policies. Before you use this chapter, you should be familiar with principals and policies, including any planning considerations. Refer to Chapter 21, Introduction to the Kerberos Service and Chapter 22, Planning for the Kerberos Service, respectively.

This is a list of the information in this chapter.

Ways to Administer Kerberos Principals and Policies

The Kerberos database on the master KDC contains all of your realm's Kerberos principals, their passwords, policies, and other administrative information. To create and delete principals, and to modify their attributes, you can use either the kadmin or gkadmin command.

The kadmin command provides an interactive command-line interface that enables you to maintain Kerberos principals, policies, and keytab files. There are two versions of the kadmin command:

Other than kadmin using Kerberos to authenticate the user, the capabilities of the two versions are identical. The local version is necessary to enable you to set up enough of the database so that you can use the remote version.

Also, the Solaris release provides the SEAM Administration Tool, gkadmin, which is an interactive graphical user interface (GUI) that provides essentially the same capabilities as the kadmin command. See SEAM Administration Tool for more information.

SEAM Administration Tool

The SEAM Administration Tool (SEAM Tool) is an interactive graphical user interface (GUI) that enables you to maintain Kerberos principals and policies. This tool provides much the same capabilities as the kadmin command. However, this tool does not support the management of keytab files. You must use the kadmin command to administer keytab files, which is described in Administering Keytab Files.

Similar to the kadmin command, the SEAM Tool uses Kerberos authentication and encrypted RPC to operate securely from anywhere on the network. The SEAM Tool enables you to do the following:

The SEAM Tool also provides context-sensitive help and general online help.

The following task maps provide pointers to the various tasks that you can do with the SEAM Tool:

Also, go to SEAM Tool Panel Descriptions for descriptions of all the principal attributes and policy attributes that you can either specify or view in the SEAM Tool.

Command-Line Equivalents of the SEAM Tool

This section lists the kadmin commands that provide the same capabilities as the SEAM Tool. These commands can be used without running an X Window system. Even though most procedures in this chapter use the SEAM Tool, many procedures also provide corresponding examples that use the command-line equivalents.

Table 25–1 Command-Line Equivalents of the SEAM Tool

SEAM Tool Procedure 

Equivalent kadmin Command

View the list of principals. 

list_principals or get_principals

View a principal's attributes. 

get_principal

Create a new principal. 

add_principal

Duplicate a principal. 

No command-line equivalent 

Modify a principal. 

modify_principal or change_password

Delete a principal. 

delete_principal

Set up defaults for creating new principals. 

No command-line equivalent 

View the list of policies. 

list_policies or get_policies

View a policy's attributes. 

get_policy

Create a new policy. 

add_policy

Duplicate a policy. 

No command-line equivalent 

Modify a policy. 

modify_policy

Delete a policy. 

delete_policy

The Only File Modified by the SEAM Tool

The only file that the SEAM Tool modifies is the $HOME/.gkadmin file. This file contains the default values for creating new principals. You can update this file by choosing Properties from the Edit menu.

Print and Online Help Features of the SEAM Tool

The SEAM Tool provides both print features and online help features. From the Print menu, you can send the following to a printer or a file:

From the Help menu, you can access context-sensitive help and general help. When you choose Context-Sensitive Help from the Help menu, the Context-Sensitive Help window is displayed and the tool is switched to help mode. In help mode, when you click on any fields, labels, or buttons on the window, help on that item is displayed in the Help window. To switch back to the tool's normal mode, click Dismiss in the Help window.

You can also choose Help Contents, which opens an HTML browser that provides pointers to the general overview and task information that is provided in this chapter.

Working With Large Lists in the SEAM Tool

As your site starts to accumulate a large number of principals and policies, the time it takes the SEAM Tool to load and display the principal and policy lists will become increasingly longer. Thus, your productivity with the tool will decrease. There are several ways to work around this problem.

First, you can completely eliminate the time to load the lists by not having the SEAM Tool load the lists. You can set this option by choosing Properties from the Edit menu, and unchecking the Show Lists field. Of course, when the tool doesn't load the lists, it can't display the lists, and you can no longer use the list panels to select principals or policies. Instead, you must type a principal or policy name in the new Name field that is provided, then select the operation that you want to perform on it. In effect, typing a name is equivalent to selecting an item from the list.

Another way to work with large lists is to cache them. In fact, caching the lists for a limited time is set as the default behavior for the SEAM Tool. The SEAM Tool must still initially load the lists into the cache. But after that, the tool can use the cache rather than retrieve the lists again. This option eliminates the need to keep loading the lists from the server, which is what takes so long.

You can set list caching by choosing Properties from the Edit menu. There are two cache settings. You can choose to cache the list forever, or you can specify a time limit when the tool must reload the lists from the server into the cache.

Caching the lists still enables you to use the list panels to select principals and policies, so it doesn't affect how you use the SEAM Tool as the first option does. Also, even though caching doesn't enable you to see the changes of other users, you can still see the latest list information based on your changes, because your changes update the lists both on the server and in the cache. And, if you want to update the cache to see other changes and get the lastest copy of the lists, you can use the Refresh menu whenever you want to refresh the cache from the server.

ProcedureHow to Start the SEAM Tool

  1. Start the SEAM Tool by using the gkadmin command.


    $ /usr/sbin/gkadmin
    

    The SEAM Administration Login window is displayed.

    Dialog box titled SEAM Administration Login shows four
fields for Principal Name, Password, Realm, and Master KDC. Shows OK and Start
Over buttons.
  2. If you don't want to use the default values, specify new default values.

    The window automatically fills in with default values. The default principal name is determined by taking your current identity from the USER environment variable and appending /admin to it (username/admin). The default Realm and Master KDC fields are selected from the /etc/krb5/krb5.conf file. If you ever want to retrieve the default values, click Start Over.


    Note –

    The administration operations that each Principal Name can perform are dictated by the Kerberos ACL file, /etc/krb5/kadm5.acl. For information about limited privileges, see Using the SEAM Tool With Limited Kerberos Administration Privileges.


  3. Type a password for the specified principal name.

  4. Click OK.

    A window showing all of the principals is displayed.

Administering Kerberos Principals

This section provides the step-by-step instructions used to administer principals with the SEAM Tool. This section also provides examples of command-line equivalents, when available.

Administering Kerberos Principals (Task Map)

Task 

Description 

For Instructions 

View the list of principals. 

View the list of principals by clicking the Principals tab. 

How to View the List of Kerberos Principals

View a principal's attributes. 

View a principal's attributes by selecting the Principal in the Principal List, then clicking the Modify button. 

How to View a Kerberos Principal's Attributes

Create a new principal. 

Create a new principal by clicking the Create New button in the Principal List panel. 

How to Create a New Kerberos Principal

Duplicate a principal. 

Duplicate a principal by selecting the principal to duplicate in the Principal List, then clicking the Duplicate button. 

How to Duplicate a Kerberos Principal

Modify a principal. 

Modify a principal by selecting the principal to modify in the Principal List, then clicking the Modify button. 

Note that you cannot modify a principal's name. To rename a principal, you must duplicate the principal, specify a new name for it, save it, and then delete the old principal. 

How to Modify a Kerberos Principal

Delete a principal. 

Delete a principal by selecting the principal to delete in the Principal List, then clicking the Delete button. 

How to Delete a Kerberos Principal

Set up defaults for creating new principals. 

Set up defaults for creating new principals by choosing Properties from the Edit menu. 

How to Set Up Defaults for Creating New Kerberos Principals

Modify the Kerberos administration privileges (kadm5.acl file).

Command-line only. The Kerberos administration privileges determine what operations a principal can perform on the Kerberos database, such as add and modify.

You need to edit the /etc/krb5/kadm5.acl file to modify the Kerberos administration privileges for each principal.

How to Modify the Kerberos Administration Privileges

Automating the Creation of New Kerberos Principals

Even though the SEAM Tool provides ease-of-use, it doesn't provide a way to automate the creation of new principals. Automation is especially useful if you need to add 10 or even 100 new principals in a short time. However, by using the kadmin.local command in a Bourne shell script, you can do just that.

The following shell script line is an example of how to automate the creation of new principals:


awk '{ print "ank +needchange -pw", $2, $1 }' < /tmp/princnames | 
        time /usr/sbin/kadmin.local> /dev/null

This example is split over two lines for readability. The script reads in a file called princnames that contains principal names and their passwords, and adds them to the Kerberos database. You would have to create the princnames file, which contains a principal name and its password on each line, separated by one or more spaces. The +needchange option configures the principal so that the user is prompted for a new password during login with the principal for the first time. This practice helps to ensure that the passwords in the princnames file are not a security risk.

You can build more elaborate scripts. For example, your script could use the information in the name service to obtain the list of user names for the principal names. What you do and how you do it is determined by your site's needs and your scripting expertise.

ProcedureHow to View the List of Kerberos Principals

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Principals tab.

    The list of principals is displayed.

    Dialog box titled Seam Administration Tool shows a list
of principals and a list filter. Shows Modify, Create New, Delete, and Duplicate
buttons.
  3. Display a specific principal or a sublist of principals.

    Type a filter string in the Filter field, and press Return. If the filter succeeds, the list of principals that match the filter is displayed.

    The filter string must consist of one or more characters. Because the filter mechanism is case sensitive, you need to use the appropriate uppercase and lowercase letters for the filter. For example, if you type the filter string ge, the filter mechanism displays only the principals with the ge string in them (for example, george or edge).

    If you want to display the entire list of principals, click Clear Filter.


Example 25–1 Viewing the List of Kerberos Principals (Command Line)

In the following example, the list_principals command of kadmin is used to list all the principals that match kadmin*. Wildcards can be used with the list_principals command.


kadmin: list_principals kadmin*
kadmin/changepw@EXAMPLE.COM
kadmin/kdc1.example.con@EXAMPLE.COM
kadmin/history@EXAMPLE.COM
kadmin: quit

ProcedureHow to View a Kerberos Principal's Attributes

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Principals tab.

  3. Select the principal in the list that you want to view, then click Modify.

    The Principal Basics panel that contains some of the principal's attributes is displayed.

  4. Continue to click Next to view all the principal's attributes.

    Three windows contain attribute information. Choose Context-Sensitive Help from the Help menu to get information about the various attributes in each window. Or, for all the principal attribute descriptions, go to SEAM Tool Panel Descriptions.

  5. When you are finished viewing, click Cancel.


Example 25–2 Viewing a Kerberos Principal's Attributes

The following example shows the first window when you are viewing the jdb/admin principal.

Dialog box titled SEAM Administration Tool shows account
data for the jdb/admin principal.  Shows account expiration date and comments.

Example 25–3 Viewing a Kerberos Principal's Attributes (Command Line)

In the following example, the get_principal command of kadmin is used to view the attributes of the jdb/admin principal.


kadmin: getprinc jdb/admin
Principal: jdb/admin@EXAMPLE.COM
Expiration date: Fri Aug 25 17:19:05 PDT 2004
Last password change: [never]
Password expiration date: Wed Apr 14 11:53:10 PDT 2003
Maximum ticket life: 1 day 16:00:00
Maximum renewable life: 1 day 16:00:00
Last modified: Thu Jan 14 11:54:09 PST 2003 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 1, Triple DES with HMAC/sha1, no salt
Key: vno 1, ArcFour with HMAC/md5, no salt
Key: vno 1, DES cbc mode with RSA-MD5, no salt
Attributes: REQUIRES_HW_AUTH
Policy: [none]
kadmin: quit

ProcedureHow to Create a New Kerberos Principal

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    Note –

    If you are creating a new principal that might need a new policy, you should create the new policy before you create the new principal. Go to How to Create a New Kerberos Policy.



    $ /usr/sbin/gkadmin
    
  2. Click the Principals tab.

  3. Click New.

    The Principal Basics panel that contains some attributes for a principal is displayed.

  4. Specify a principal name and a password.

    Both the principal name and the password are mandatory.

  5. Specify the encryption types for the principal.

    Click on the box to the right of the encryption key types field to open a new window that displays all of the encryption key types available. Click OK after selecting the required encryption types.

    Dialog box titled SEAM Encryption Type List Helper lists
all of the encryption types installed.
  6. Specify the policy for the principal.

  7. Specify values for the principal's attributes, and continue to click Next to specify more attributes.

    Three windows contain attribute information. Choose Context-Sensitive Help from the Help menu to get information about the various attributes in each window. Or, for all the principal attribute descriptions, go to SEAM Tool Panel Descriptions.

  8. Click Save to save the principal, or click Done on the last panel.

  9. If needed, set up Kerberos administration privileges for the new principal in the /etc/krb5/kadm5.acl file.

    See How to Modify the Kerberos Administration Privileges for more details.


Example 25–4 Creating a New Kerberos Principal

The following example shows the Principal Basics panel when a new principal called pak is created. The policy is set to testuser.

Dialog box titled SEAM Administration Tool shows account
data for the pak principal.  Shows password, account expiration date, and
testuser policy.

Example 25–5 Creating a New Kerberos Principal (Command Line)

In the following example, the add_principal command of kadmin is used to create a new principal called pak. The principal's policy is set to testuser.


kadmin: add_principal -policy testuser pak
Enter password for principal "pak@EXAMPLE.COM": <Type the password>
Re-enter password for principal "pak@EXAMPLE.COM": <Type the password again>
Principal "pak@EXAMPLE.COM" created.
kadmin: quit

ProcedureHow to Duplicate a Kerberos Principal

This procedure explains how to use all or some of the attributes of an existing principal to create a new principal. No command-line equivalent exists for this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Principals tab.

  3. Select the principal in the list that you want to duplicate, then click Duplicate.

    The Principal Basics panel is displayed. All the attributes of the selected principal are duplicated, except for the Principal Name and Password fields, which are empty.

  4. Specify a principal name and a password.

    Both the principal name and the password are mandatory. To make an exact duplicate of the principal you selected, click Save and skip to Step 7.

  5. Specify different values for the principal's attributes, and continue to click Next to specify more attributes.

    Three windows contain attribute information. Choose Context-Sensitive Help from the Help menu to get information about the various attributes in each window. Or, for all the principal attribute descriptions, go to SEAM Tool Panel Descriptions.

  6. Click Save to save the principal, or click Done on the last panel.

  7. If needed, set up Kerberos administration privileges for the principal in /etc/krb5/kadm5.acl file.

    See How to Modify the Kerberos Administration Privileges for more details.

ProcedureHow to Modify a Kerberos Principal

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Principals tab.

  3. Select the principal in the list that you want to modify, then click Modify.

    The Principal Basics panel that contains some of the attributes for the principal is displayed.

  4. Modify the principal's attributes, and continue to click Next to modify more attributes.

    Three windows contain attribute information. Choose Context-Sensitive Help from the Help menu to get information about the various attributes in each window. Or, for all the principal attribute descriptions, go to SEAM Tool Panel Descriptions.


    Note –

    You cannot modify a principal's name. To rename a principal, you must duplicate the principal, specify a new name for it, save it, and then delete the old principal.


  5. Click Save to save the principal, or click Done on the last panel.

  6. Modify the Kerberos administration privileges for the principal in the /etc/krb5/kadm5.acl file.

    See How to Modify the Kerberos Administration Privileges for more details.


Example 25–6 Modifying a Kerberos Principal's Password (Command Line)

In the following example, the change_password command of kadmin is used to modify the password for the jdb principal. The change_password command does not let you change the password to a password that is in the principal's password history.


kadmin: change_password jdb
Enter password for principal "jdb": <Type the new password>
Re-enter password for principal "jdb": <Type the password again>
Password for "jdb@EXAMPLE.COM" changed.
kadmin: quit

To modify other attributes for a principal, you must use the modify_principal command of kadmin.


ProcedureHow to Delete a Kerberos Principal

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Principals tab.

  3. Select the principal in the list that you want to delete, then click Delete.

    After you confirm the deletion, the principal is deleted.

  4. Remove the principal from the Kerberos access control list (ACL) file, /etc/krb5/kadm5.acl.

    See How to Modify the Kerberos Administration Privileges for more details.


Example 25–7 Deleting a Kerberos Principal (Command Line)

In the following example, the delete_principal command of kadmin is used to delete the jdb principal.


kadmin: delete_principal pak
Are you sure you want to delete the principal "pak@EXAMPLE.COM"? (yes/no): yes
Principal "pak@EXAMPLE.COM" deleted.
Make sure that you have removed this principal from all ACLs before reusing.
kadmin: quit

ProcedureHow to Set Up Defaults for Creating New Kerberos Principals

No command-line equivalent exists for this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Choose Properties from the Edit Menu.

    The Properties window is displayed.

    Dialog box titled Properties shows defaults for new principals
and list controls. Defaults for principals cover security and other options.
  3. Select the defaults that you want to use when you create new principals.

    Choose Context-Sensitive Help from the Help menu for information about the various attributes in each window.

  4. Click Save.

ProcedureHow to Modify the Kerberos Administration Privileges

Even though your site probably has many user principals, you usually want only a few users to be able to administer the Kerberos database. Privileges to administer the Kerberos database are determined by the Kerberos access control list (ACL) file, kadm5.acl. The kadm5.acl file enables you to allow or disallow privileges for individual principals. Or, you can use the '*' wildcard in the principal name to specify privileges for groups of principals.

  1. Become superuser on the master KDC.

  2. Edit the /etc/krb5/kadm5.acl file.

    An entry in the kadm5.acl file must have the following format:


    principal privileges [principal-target]

    principal

    Specifies the principal to which the privileges are granted. Any part of the principal name can include the '*' wildcard, which is useful for providing the same privileges for a group of principals. For example, if you want to specify all principals with the admin instance, you would use */admin@realm.

    Note that a common use of an admin instance is to grant separate privileges (such as administration access to the Kerberos database) to a separate Kerberos principal. For example, the user jdb might have a principal for his administrative use, called jdb/admin. This way, the user jdb obtains jdb/admin tickets only when he or she actually needs to use those privileges.

    privileges

    Specifies which operations can or cannot be performed by the principal. This field consists of a string of one or more of the following list of characters or their uppercase counterparts. If the character is uppercase (or not specified), then the operation is disallowed. If the character is lowercase, then the operation is permitted. 

     

    a

    [Dis]allows the addition of principals or policies. 

     

    d

    [Dis]allows the deletion of principals or policies. 

     

    m

    [Dis]allows the modification of principals or polices. 

     

    c

    [Dis]allows the changing of passwords for principals. 

     

    i

    [Dis]allows inquiries to the Kerberos database. 

     

    l

    [Dis]allows the listing of principals or policies in the Kerberos database. 

     

    x or *

    Allows all privileges (admcil).

    principal-target

    When a principal is specified in this field, the privileges apply to the principal only when the principal operates on the principal-target. Any part of the principal name can include the '*' wildcard, which is useful to group principals.


Example 25–8 Modifying the Kerberos Administration Privileges

The following entry in the kadm5.acl file gives any principal in the EXAMPLE.COM realm with the admin instance all the privileges on the Kerberos database:


*/admin@EXAMPLE.COM *

The following entry in the kadm5.acl file gives the jdb@EXAMPLE.COM principal the privileges to add, list, and inquire about any principal that has the root instance.


jdb@EXAMPLE.COM ali */root@EXAMPLE.COM

Administering Kerberos Policies

This section provides step-by-step instructions used to administer policies with the SEAM Tool. This section also provides examples of command-line equivalents, when available.

Administering Kerberos Policies (Task Map)

Task 

Description 

For Instructions 

View the list of policies. 

View the list of policies by clicking the Policies tab. 

How to View the List of Kerberos Policies

View a policy's attributes. 

View a policy's attributes by selecting the policy in the Policy List, then clicking the Modify button. 

How to View a Kerberos Policy's Attributes

Create a new policy. 

Create a new policy by clicking the Create New button in the Policy List panel. 

How to Create a New Kerberos Policy

Duplicate a policy. 

Duplicate a policy by selecting the policy to duplicate in the Policy List, then clicking the Duplicate button. 

How to Duplicate a Kerberos Policy

Modify a policy. 

Modify a policy by selecting the policy to modify in the Policy List, then clicking the Modify button. 

Note that you cannot modify a policy's name. To rename a policy, you must duplicate the policy, specify a new name for it, save it, and then delete the old policy. 

How to Modify a Kerberos Policy

Delete a policy. 

Delete a policy by selecting the policy to delete in the Policy List, then clicking the Delete button. 

How to Delete a Kerberos Policy

ProcedureHow to View the List of Kerberos Policies

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Policies tab.

    The list of policies is displayed.

    Dialog box titled SEAM Administration Tool shows a list
of policies and a policy filter. Shows Modify, Create New, Delete, and Duplicate
buttons.
  3. Display a specific policy or a sublist of policies.

    Type a filter string in the Filter field, and press Return. If the filter succeeds, the list of policies that match the filter is displayed.

    The filter string must consist of one or more characters. Because the filter mechanism is case sensitive, you need to use the appropriate uppercase and lowercase letters for the filter. For example, if you type the filter string ge, the filter mechanism displays only the policies with the ge string in them (for example, george or edge).

    If you want to display the entire list of policies, click Clear Filter.


Example 25–9 Viewing the List of Kerberos Policies (Command Line)

In the following example, the list_policies command of kadmin is used to list all the policies that match *user*. Wildcards can be used with the list_policies command.


kadmin: list_policies *user*
testuser
enguser
kadmin: quit

ProcedureHow to View a Kerberos Policy's Attributes

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Policies tab.

  3. Select the policy in the list that you want to view, then click Modify.

    The Policy Details panel is displayed.

  4. When you are finished viewing, click Cancel.


Example 25–10 Viewing a Kerberos Policy's Attributes

The following example shows the Policy Details panel when you are viewing the test policy.

Dialog box titled SEAM Administration Tool shows policy
details of the enguser policy. Shows Save, Previous, Done, and Cancel buttons

Example 25–11 Viewing a Kerberos Policy's Attributes (Command Line)

In the following example, the get_policy command of kadmin is used to view the attributes of the enguser policy.


kadmin: get_policy enguser
Policy: enguser
Maximum password life: 2592000
Minimum password life: 0
Minimum password length: 8
Minimum number of password character classes: 2
Number of old keys kept: 3
Reference count: 0
kadmin: quit

The Reference count is the number of principals that use this policy.


ProcedureHow to Create a New Kerberos Policy

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Policies tab.

  3. Click New.

    The Policy Details panel is displayed.

  4. Specify a name for the policy in the Policy Name field.

    The policy name is mandatory.

  5. Specify values for the policy's attributes.

    Choose Context-Sensitive Help from the Help menu for information about the various attributes in this window. Or, go to Table 25–5 for all the policy attribute descriptions.

  6. Click Save to save the policy, or click Done.


Example 25–12 Creating a New Kerberos Policy

In the following example, a new policy called build11 is created. The Minimum Password Classes is set to 3.

Dialog box titled SEAM Administration Tool shows policy
details of the build11 policy.  Shows Save, Previous, Done, and Cancel buttons.

Example 25–13 Creating a New Kerberos Policy (Command Line)

In the following example, the add_policy command of kadmin is used to create the build11 policy. This policy requires at least 3 character classes in a password.


$ kadmin
kadmin: add_policy -minclasses 3 build11
kadmin: quit

ProcedureHow to Duplicate a Kerberos Policy

This procedure explains how to use all or some of the attributes of an existing policy to create a new policy. No command-line equivalent exists for this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Policies tab.

  3. Select the policy in the list that you want to duplicate, then click Duplicate.

    The Policy Details panel is displayed. All the attributes of the selected policy are duplicated, except for the Policy Name field, which is empty.

  4. Specify a name for the duplicated policy in the Policy Name field.

    The policy name is mandatory. To make an exact duplicate of the policy you selected, skip to Step 6.

  5. Specify different values for the policy's attributes.

    Choose Context-Sensitive Help from the Help menu for information about the various attributes in this window. Or, go to Table 25–5 for all the policy attribute descriptions.

  6. Click Save to save the policy, or click Done.

ProcedureHow to Modify a Kerberos Policy

An example of the command-line equivalent follows this procedure.

  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for details.


    $ /usr/sbin/gkadmin
    
  2. Click the Policies tab.

  3. Select the policy in the list that you want to modify, then click Modify.

    The Policy Details panel is displayed.

  4. Modify the policy's attributes.

    Choose Context-Sensitive Help from the Help menu for information about the various attributes in this window. Or, go to Table 25–5 for all the policy attribute descriptions.


    Note –

    You cannot modify a policy's name. To rename a policy, you must duplicate the policy, specify a new name for it, save it, and then delete the old policy.


  5. Click Save to save the policy, or click Done.


Example 25–14 Modifying a Kerberos Policy (Command Line)

In the following example, the modify_policy command of kadmin is used to modify the minimum length of a password to five characters for the build11 policy.


$ kadmin
kadmin: modify_policy -minlength 5 build11
kadmin: quit

ProcedureHow to Delete a Kerberos Policy

An example of the command-line equivalent follows this procedure.


Note –

Before you delete a policy, you must cancel the policy from all principals that are currently using it. To do so, you need to modify the principals' Policy attribute. The policy cannot be deleted if any principal is using it.


  1. If necessary, start the SEAM Tool.

    See How to Start the SEAM Tool for more information.


    $ /usr/sbin/gkadmin
    
  2. Click the Policies tab.

  3. Select the policy in the list that you want to delete, then click Delete.

    After you confirm the deletion, the policy is deleted.


Example 25–15 Deleting a Kerberos Policy (Command Line)

In the following example, the delete_policy command of the kadmin command is used to delete the build11 policy.


kadmin: delete_policy build11 
Are you sure you want to delete the policy "build11"? (yes/no): yes
kadmin: quit

Before you delete a policy, you must cancel the policy from all principals that are currently using it. To do so, you need to use the modify_principal -policy command of kadmin on the affected principals. The delete_policy command fails if the policy is in use by a principal.


SEAM Tool Reference

This section provides descriptions of each panel in the SEAM Tool. Also, information about using limited privileges with SEAM Tool are provided.

SEAM Tool Panel Descriptions

This section provides descriptions for each principal and policy attribute that you can either specify or view in the SEAM Tool. The attributes are organized by the panel in which they are displayed.

Table 25–2 Attributes for the Principal Basics Panel of the SEAM Tool

Attribute 

Description 

Principal Name 

The name of the principal (which is the primary/instance part of a fully qualified principal name). A principal is a unique identity to which the KDC can assign tickets.

If you are modifying a principal, you cannot edit its name. 

Password 

The password for the principal. You can use the Generate Random Password button to create a random password for the principal. 

Policy 

A menu of available policies for the principal. 

Account Expires 

The date and time on which the principal's account expires. When the account expires, the principal can no longer get a ticket-granting ticket (TGT) and might be unable to log in. 

Last Principal Change  

The date on which information for the principal was last modified. (Read only) 

Last Changed By 

The name of the principal that last modified the account for this principal. (Read only) 

Comments 

Comments that are related to the principal (for example, “Temporary Account”). 

Table 25–3 Attributes for the Principal Details Panel of the SEAM Tool

Attribute 

Description 

Last Success 

The date and time when the principal last logged in successfully. (Read only) 

Last Failure 

The date and time when the last login failure for the principal occurred. (Read only) 

Failure Count 

The number of times a login failure has occurred for the principal. (Read only) 

Last Password Change 

The date and time when the principal's password was last changed. (Read only) 

Password Expires 

The date and time when the principal's current password expires. 

Key Version 

The key version number for the principal. This attribute is normally changed only when a password has been compromised. 

Maximum Lifetime (seconds) 

The maximum length of time for which a ticket can be granted for the principal (without renewal). 

Maximum Renewal (seconds) 

The maximum length of time for which an existing ticket can be renewed for the principal. 

Table 25–4 Attributes of the Principal Flags Panel of the SEAM Tool

Attribute (Radio Buttons) 

Description 

Disable Account 

When checked, prevents the principal from logging in. This attribute provides an easy way to temporarily freeze a principal account. 

Require Password Change 

When checked, expires the principal's current password, which forces the user to use the kpasswd command to create a new password. This attribute is useful if a security breach occurs, and you need to make sure that old passwords are replaced.

Allow Postdated Tickets 

When checked, allows the principal to obtain postdated tickets.  

For example, you might need to use postdated tickets for cron jobs that must run after hours, but you cannot obtain tickets in advance because of short ticket lifetimes.

Allow Forwardable Tickets 

When checked, allows the principal to obtain forwardable tickets. 

Forwardable tickets are tickets that are forwarded to the remote host to provide a single-sign-on session. For example, if you are using forwardable tickets and you authenticate yourself through ftp or rsh, then other services, such as NFS services, are available without your being prompted for another password.

Allow Renewable Tickets 

When checked, allows the principal to obtain renewable tickets. 

A principal can automatically extend the expiration date or time of a ticket that is renewable (rather than having to get a new ticket after the first ticket expires). Currently, the NFS service is the ticket service that can renew tickets. 

Allow Proxiable Tickets 

When checked, allows the principal to obtain proxiable tickets. 

A proxiable ticket is a ticket that can be used by a service on behalf of a client to perform an operation for the client. With a proxiable ticket, a service can take on the identity of a client and obtain a ticket for another service. However, the service cannot obtain a ticket-granting ticket (TGT). 

Allow Service Tickets 

When checked, allows service tickets to be issued for the principal. 

You should not allow service tickets to be issued for the kadmin/hostname and changepw/hostname principals. This practice ensures that only these principals can update the KDC database.

Allow TGT-Based Authentication 

When checked, allows the service principal to provide services to another principal. More specifically, this attribute allows the KDC to issue a service ticket for the service principal. 

This attribute is valid only for service principals. When unchecked, service tickets cannot be issued for the service principal. 

Allow Duplicate Authentication 

When checked, allows the user principal to obtain service tickets for other user principals. 

This attribute is valid only for user principals. When unchecked, the user principal can still obtain service tickets for service principals, but not for other user principals. 

Required Preauthentication 

When checked, the KDC will not send a requested ticket-granting ticket (TGT) to the principal until the KDC can authenticate (through software) that the principal is really the principal that is requesting the TGT. This preauthentication is usually done through an extra password, for example, from a DES card. 

When unchecked, the KDC does not need to preauthenticate the principal before the KDC sends a requested TGT to the principal. 

Required Hardware Authentication 

When checked, the KDC will not send a requested ticket-granting ticket (TGT) to the principal until the KDC can authenticate (through hardware) that the principal is really the principal that is requesting the TGT. Hardware preauthentication can occur, for example, on a Java ring reader. 

When unchecked, the KDC does not need to preauthenticate the principal before the KDC sends a requested TGT to the principal. 

Table 25–5 Attributes for the Policy Basics Pane of the SEAM Tool

Attribute 

Description 

Policy Name 

The name of the policy. A policy is a set of rules that govern a principal's password and tickets. 

If you are modifying a policy, you cannot edit its name. 

Minimum Password Length 

The minimum length for the principal's password. 

Minimum Password Classes 

The minimum number of different character types that are required in the principal's password. 

For example, a minimum classes value of 2 means that the password must have at least two different character types, such as letters and numbers (hi2mom). A value of 3 means that the password must have at least three different character types, such as letters, numbers, and punctuation (hi2mom!). And so on.  

A value of 1 sets no restriction on the number of password character types. 

Saved Password History 

The number of previous passwords that have been used by the principal, and a list of the previous passwords that cannot be reused. 

Minimum Password Lifetime (seconds) 

The minimum length of time that the password must be used before it can be changed. 

Maximum Password Lifetime (seconds) 

The maximum length of time that the password can be used before it must be changed. 

Principals Using This Policy 

The number of principals to which this policy currently applies. (Read only) 

Using the SEAM Tool With Limited Kerberos Administration Privileges

All features of the SEAM Administration Tool are available if your admin principal has all the privileges to administer the Kerberos database. However, you might have limited privileges, such as only being allowed to view the list of principals or to change a principal's password. With limited Kerberos administration privileges, you can still use the SEAM Tool. However, various parts of the SEAM Tool change based on the Kerberos administration privileges that you do not have. Table 25–6 shows how the SEAM Tool changes based on your Kerberos administration privileges.

The most visual change to the SEAM Tool occurs when you don't have the list privilege. Without the list privilege, the List panels do not display the list of principals and polices for you to manipulate. Instead, you must use the Name field in the List panels to specify a principal or a policy that you want to manipulate.

If you log in to the SEAM Tool, and you do not have sufficient privileges to perform tasks with it, the following message displays and you are sent back to the SEAM Administration Login window:


Insufficient privileges to use gkadmin: ADMCIL. Please try using another principal.

To change the privileges for a principal so that it can administer the Kerberos database, go to How to Modify the Kerberos Administration Privileges.

Table 25–6 Using the SEAM Tool With Limited Kerberos Administration Privileges

Disallowed Privilege 

How the SEAM Tool Changes 

a (add)

The Create New and Duplicate buttons are unavailable in the Principal List and Policy List panels. Without the add privilege, you cannot create new principals or policies, or duplicate them. 

d (delete)

The Delete button is unavailable in the Principal List and Policy List panels. Without the delete privilege, you cannot delete principals or policies. 

m (modify)

The Modify button is unavailable in the Principal List and Policy List panels. Without the modify privilege, you cannot modify principals or policies.  

Also, with the Modify button unavailable, you cannot modify a principal's password, even if you have the change password privilege. 

c (change password)

The Password field in the Principal Basics panel is read only and cannot be changed. Without the change password privilege, you cannot modify a principal's password.  

Note that even if you have the change password privilege, you must also have the modify privilege to change a principal's password. 

i (inquiry to database)

The Modify and Duplicate buttons are unavailable in the Principal List and Policy List panels. Without the inquiry privilege, you cannot modify or duplicate a principal or a policy.  

Also, with the Modify button unavailable, you cannot modify a principal's password, even if you have the change password privilege. 

l (list)

The list of principals and policies in the List panels are unavailable. Without the list privilege, you must use the Name field in the List panels to specify the principal or the policy that you want to manipulate. 

Administering Keytab Files

Every host that provides a service must have a local file, called a keytab (short for “key table”). The keytab contains the principal for the appropriate service, called a service key. A service key is used by a service to authenticate itself to the KDC and is known only by Kerberos and the service itself. For example, if you have a Kerberized NFS server, that server must have a keytab file that contains its nfs service principal.

To add a service key to a keytab file, you add the appropriate service principal to a host's keytab file by using the ktadd command of kadmin. Because you are adding a service principal to a keytab file, the principal must already exist in the Kerberos database so that kadmin can verify its existence. On application servers that provide Kerberized services, the keytab file is located at /etc/krb5/krb5.keytab, by default.

A keytab is analogous to a user's password. Just as it is important for users to protect their passwords, it is equally important for application servers to protect their keytab files. You should always store keytab files on a local disk, and make them readable only by the root user. Also, you should never send a keytab file over an unsecured network.

There is also a special instance in which to add a root principal to a host's keytab file. If you want a user on the Kerberos client to mount Kerberized NFS file systems that require root-equivalent access, you must add the client's root principal to the client's keytab file. Otherwise, users must use the kinit command as root to obtain credentials for the client's root principal whenever they want to mount a Kerberized NFS file system with root access, even when they are using the automounter.

Another command that you can use to administer keytab files is the ktutil command. This interactive command enables you to manage a local host's keytab file without having Kerberos administration privileges, because ktutil doesn't interact with the Kerberos database as kadmin does. So, after a principal is added to a keytab file, you can use ktutil to view the keylist in a keytab file or to temporarily disable authentication for a service.


Note –

When you change a principal in a keytab file using the ktadd command in kadmin, a new key is generated and added to the keytab file.


Administering Keytab Files (Task Map)

Task 

Description 

For Instructions 

Add a service principal to a keytab file. 

Use the ktadd command of kadmin to add a service principal to a keytab file.

How to Add a Kerberos Service Principal to a Keytab File

Remove a service principal from a keytab file. 

Use the ktremove command of kadmin to remove a service from a keytab file.

How to Remove a Service Principal From a Keytab File

Display the keylist (list of principals) in a keytab file. 

Use the ktutil command to display the keylist in a keytab file.

How to Display the Keylist (Principals) in a Keytab File

Temporarily disable authentication for a service on a host. 

This procedure is a quick way to temporarily disable authentication for a service on a host without requiring kadmin privileges.

Before you use ktutil to delete the service principal from the server's keytab file, copy the original keytab file to a temporary location. When you want to enable the service again, copy the original keytab file back to its proper location.

How to Temporarily Disable Authentication for a Service on a Host

ProcedureHow to Add a Kerberos Service Principal to a Keytab File

  1. Make sure that the principal already exists in the Kerberos database.

    See How to View the List of Kerberos Principals for more information.

  2. Become superuser on the host that needs a principal added to its keytab file.

  3. Start the kadmin command.


    # /usr/sbin/kadmin
    
  4. Add a principal to a keytab file by using the ktadd command.


    kadmin: ktadd [-e enctype] [-k keytab] [-q] [principal | -glob principal-exp]
    -e enctype

    Overrides the list of encryption types defined in the krb5.conf file.

    -k keytab

    Specifies the keytab file. By default, /etc/krb5/krb5.keytab is used.

    -q

    Displays less verbose information.

    principal

    Specifies the principal to be added to the keytab file. You can add the following service principals: host, root, nfs, and ftp.

    -glob principal-exp

    Specifies the principal expressions. All principals that match the principal-exp are added to the keytab file. The rules for principal expression are the same as for the list_principals command of kadmin.

  5. Quit the kadmin command.


    kadmin: quit
    

Example 25–16 Adding a Service Principal to a Keytab File

In the following example, denver's host principal is added to denver's keytab file, so that the KDC can authenticate denver's network services.


denver # /usr/sbin/kadmin
kadmin: ktadd host/denver.example.com
Entry for principal host/denver.example.com with kvno 3, encryption type AES-256 CTS
          mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type Triple DES cbc mode
          with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

ProcedureHow to Remove a Service Principal From a Keytab File

  1. Become superuser on the host with a service principal that must be removed from its keytab file.

  2. Start the kadmin command.


    # /usr/sbin/kadmin
    
  3. (Optional) To display the current list of principals (keys) in the keytab file, use the ktutil command.

    See How to Display the Keylist (Principals) in a Keytab File for detailed instructions.

  4. Remove a principal from the keytab file by using the ktremove command.


    kadmin: ktremove [-k keytab] [-q] principal [kvno | all | old ]
    -k keytab

    Specifies the keytab file. By default, /etc/krb5/krb5.keytab is used.

    -q

    Displays less verbose information.

    principal

    Specifies the principal to be removed from the keytab file.

    kvno

    Removes all entries for the specified principal whose key version number matches kvno.

    all

    Removes all entries for the specified principal.

    old

    Removes all entries for the specified principal, except those principals with the highest key version number.

  5. Quit the kadmin command.


    kadmin: quit
    

Example 25–17 Removing a Service Principal From a Keytab File

In the following example, denver's host principal is removed from denver's keytab file.


denver # /usr/sbin/kadmin
kadmin: ktremove host/denver.example.com@EXAMPLE.COM
kadmin: Entry for principal host/denver.example.com@EXAMPLE.COM with kvno 3
  removed from keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

ProcedureHow to Display the Keylist (Principals) in a Keytab File

  1. Become superuser on the host with the keytab file.


    Note –

    Although you can create keytab files that are owned by other users, using the default location for the keytab file requires root ownership.


  2. Start the ktutil command.


    # /usr/bin/ktutil
    
  3. Read the keytab file into the keylist buffer by using the read_kt command.


    ktutil: read_kt keytab
    
  4. Display the keylist buffer by using the list command.


    ktutil: list
    

    The current keylist buffer is displayed.

  5. Quit the ktutil command.


    ktutil: quit
    

Example 25–18 Displaying the Keylist (Principals) in a Keytab File

The following example displays the keylist in the /etc/krb5/krb5.keytab file on the denver host.


denver # /usr/bin/ktutil
    ktutil: read_kt /etc/krb5/krb5.keytab
    ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------
   1    5 host/denver@EXAMPLE.COM
    ktutil: quit

ProcedureHow to Temporarily Disable Authentication for a Service on a Host

At times, you might need to temporarily disable the authentication mechanism for a service, such as rlogin or ftp, on a network application server. For example, you might want to stop users from logging in to a system while you are performing maintenance procedures. The ktutil command enables you to accomplish this task by removing the service principal from the server's keytab file, without requiring kadmin privileges. To enable authentication again, you just need to copy the original keytab file that you saved back to its original location.


Note –

By default, most services are set up to require authentication. If a service is not set up to require authentication, then the service still works, even if you disable authentication for the service.


  1. Become superuser on the host with the keytab file.


    Note –

    Although you can create keytab files that are owned by other users, using the default location for the keytab file requires root ownership.


  2. Save the current keytab file to a temporary file.

  3. Start the ktutil command.


    # /usr/bin/ktutil
    
  4. Read the keytab file into the keylist buffer by using the read_kt command.


    ktutil: read_kt keytab
    
  5. Display the keylist buffer by using the list command.


    ktutil: list
    

    The current keylist buffer is displayed. Note the slot number for the service that you want to disable.

  6. To temporarily disable a host's service, remove the specific service principal from the keylist buffer by using the delete_entry command.


    ktutil: delete_entry slot-number
    

    Where slot-number specifies the slot number of the service principal to be deleted, which is displayed by the list command.

  7. Write the keylist buffer to a new keytab file by using the write_kt command.


    ktutil: write_kt new-keytab
    
  8. Quit the ktutil command.


    ktutil: quit
    
  9. Move the new keytab file.


    # mv new-keytab keytab
    
  10. When you want to re-enable the service, copy the temporary (original) keytab file back to its original location.


Example 25–19 Temporarily Disabling a Service on a Host

In the following example, the host service on the denver host is temporarily disabled. To re-enable the host service on denver, you would copy the krb5.keytab.temp file to the /etc/krb5/krb5.keytab file.


denver # cp /etc/krb5/krb5.keytab /etc/krb5/krb5.keytab.temp
denver # /usr/bin/ktutil
    ktutil:read_kt /etc/krb5/krb5.keytab
    ktutil:list
slot KVNO Principal
---- ---- ---------------------------------------
   1    8 root/denver@EXAMPLE.COM
   2    5 host/denver@EXAMPLE.COM
    ktutil:delete_entry 2
    ktutil:list
slot KVNO Principal
---- ---- --------------------------------------
   1    8 root/denver@EXAMPLE.COM
    ktutil:write_kt /etc/krb5/new.krb5.keytab
    ktutil: quit
denver # cp /etc/krb5/new.krb5.keytab /etc/krb5/krb5.keytab

Chapter 26 Using Kerberos Applications (Tasks)

This chapter is intended for anyone on a system with the Kerberos service configured on it. This chapter explains how to use the “Kerberized” commands and services that are provided. You should already be familiar with these commands (in their non-Kerberized versions) before you read about them here.

Because this chapter is intended for the general reader, it includes information on tickets: obtaining, viewing, and destroying them. This chapter also includes information on choosing or changing a Kerberos password.

This is a list of the information in this chapter:

For an overview of the Solaris Kerberos product, see Chapter 21, Introduction to the Kerberos Service.

Kerberos Ticket Management

This section explains how to obtain, view, and destroy tickets. For an introduction to tickets, see How the Kerberos Service Works.

Do You Need to Worry About Tickets?

With any of the SEAM releases or the Solaris 10 release installed, Kerberos is built into the login command, and you will obtain tickets automatically when you log in. The Kerberized commands rsh, rcp, rdist, telnet, and rlogin are usually set up to forward copies of your tickets to the other machines, so you don't have to explicitly ask for tickets to get access to those machines. Your configuration might not include this automatic forwarding, but it is the default behavior. See Overview of Kerberized Commands and Forwarding Kerberos Tickets for more information on forwarding tickets.

For information on ticket lifetimes, see Ticket Lifetimes.

Creating a Kerberos Ticket

Normally, if PAM is configured properly, a ticket is created automatically when you log in, and you need not do anything special to obtain a ticket. However, you might need to create a ticket if your ticket expires. Also, you might need to use a different principal besides your default principal, for example, if you use rlogin -l to log in to a machine as someone else.

To create a ticket, use the kinit command.


% /usr/bin/kinit
 

The kinit command prompts you for your password. For the full syntax of the kinit command, see the kinit(1) man page.


Example 26–1 Creating a Kerberos Ticket

This example shows a user, jennifer, creating a ticket on her own system.


% kinit
Password for jennifer@ENG.EXAMPLE.COM:  <Type password>
 

Here, the user david creates a ticket that is valid for three hours with the -l option.


% kinit -l 3h david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:  <Type password>
 

This example shows the user david creating a forwardable ticket (with the -f option) for himself. With this forwardable ticket, he can, for example, log in to a second system, and then telnet to a third system.


% kinit -f david@EXAMPLE.ORG
Password for david@EXAMPLE.ORG:     <Type password>
 

For more information on how forwarding tickets works, see Forwarding Kerberos Tickets and Types of Tickets.


Viewing Kerberos Tickets

Not all tickets are alike. One ticket might, for example, be forwardable. Another ticket might be postdated. While a third ticket might be both forwardable and postdated. You can see which tickets you have, and what their attributes are, by using the klist command with the -f option:


% /usr/bin/klist -f

The following symbols indicate the attributes that are associated with each ticket, as displayed by klist:

A

Preauthenticated

D

Postdatable

d

Postdated

F

Forwardable

f

Forwarded

I

Initial

i

Invalid

P

Proxiable

p

Proxy

R

Renewable

Types of Tickets describes the various attributes that a ticket can have.


Example 26–2 Viewing Kerberos Tickets

This example shows that the user jennifer has an initial ticket, which is forwardable (F) and postdated (d), but not yet validated (i).


% /usr/bin/klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: jennifer@ENG.EXAMPLE.COM
 
Valid starting                 Expires                 Service principal
09 Mar 04 15:09:51  09 Mar 04 21:09:51  nfs/EXAMPLE.SUN.COM@EXAMPLE.SUN.COM
        renew until 10 Mar 04 15:12:51, Flags: Fdi
 

The following example shows that the user david has two tickets that were forwarded (f) to his host from another host. The tickets are also forwardable (F).


% klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: david@EXAMPLE.SUN.COM
 
Valid starting                 Expires                 Service principal
07 Mar 04 06:09:51  09 Mar 04 23:33:51  host/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 17:09:51, Flags: fF
 
Valid starting                 Expires                 Service principal
08 Mar 04 08:09:51  09 Mar 04 12:54:51  nfs/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 15:22:51, Flags: fF

The following example shows how to display the encryption types of the session key and the ticket by using the -e option. The -a option is used to map the host address to a host name if the name service can do the conversion.


% klist -fea
Ticket cache: /tmp/krb5cc_74287
Default principal: david@EXAMPLE.SUN.COM
 
Valid starting                 Expires                 Service principal
07 Mar 04 06:09:51  09 Mar 04 23:33:51  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 10 Mar 04 17:09:51, Flags: FRIA
        Etype(skey, tkt): DES cbc mode with RSA-MD5, DES cbc mode with CRC-32
        Addresses: client.example.com

Destroying Kerberos Tickets

If you want to destroy all Kerberos tickets acquired during your current session, use the kdestroy command. The command destroys you credential cache, which destroys all your credentials and tickets. While this is not usually necessary, running kdestroy reduces the chance of the credential cache being compromised during times that you are not logged in.

To destroy your tickets, use the kdestroy command.


% /usr/bin/kdestroy

The kdestroy command destroys all your tickets. You cannot use this command to selectively destroy a particular ticket.

If you are going to be away from your system and are concerned about an intruder using your permissions, you should use either kdestroy or a screen saver that locks the screen.

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

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

Kerberos User Commands

Kerberos V5 product is a single-sign-on system, which means that you only have to type your password once. The Kerberos V5 programs do the authenticating (and optional encrypting) for you, because Kerberos has been built into each of a suite of existing, familiar network programs. The Kerberos V5 applications are versions of existing UNIX network programs with Kerberos features added.

For example, when you use a Kerberized program to connect to a remote host, the program, the KDC, and the remote host perform a set of rapid negotiations. When these negotiations are completed, your program has proven your identity on your behalf to the remote host, and the remote host has granted you access.

Note that Kerberized commands try to authenticate with Kerberos first. If Kerberos authentication fails, an error occurs or UNIX authentication is attempted, depending on what options were used with the command. Refer to the Kerberos Security section in each Kerberos command man page for more detailed information.

Overview of Kerberized Commands

The Kerberized network services are programs that connect to another machine somewhere on the Internet. These programs are the following:

These programs have features that transparently use your Kerberos tickets for negotiating authentication and optional encryption with the remote host. In most cases, you'll notice only that you no longer have to type your password to use them, because Kerberos will provide proof of your identity for you.

The Kerberos V5 network programs include options that enable you to do the following:


Note –

This section assumes you are already familiar with the non-Kerberos versions of these programs, and highlights the Kerberos functionality added by the Kerberos V5 package. For detailed descriptions of the commands described here, see their respective man pages.


The following Kerberos options have been added to ftp, rcp, rlogin, rsh, and telnet:

-a

Attempts automatic login using your existing tickets. Uses the username as returned by getlogin(), unless the name is different from the current user ID. See the telnet(1) man page for details.

-f

Forwards a non-reforwardable ticket to a remote host. This option is mutually exclusive with the -F option. They cannot be used together in the same command.

You'll want to forward a ticket if you have reason to believe you'll need to authenticate yourself to other Kerberos-based services on a third host. For example, you might want to remotely log in to another machine and then remotely log in from it to a third machine.

You should definitely use a forwardable ticket if your home directory on the remote host is NFS-mounted using the Kerberos V5 mechanism. Otherwise, you won't be able to access your home directory. That is, suppose you initially log in to System 1. From System 1, you remotely log in to your home machine, System 2, which mounts your home directory from System 3. Unless you've used the -f or -F option with rlogin, you won't be able to get to your home directory because your ticket can't be forwarded to System 3.

By default, kinit obtains forwardable ticket-granting tickets (TGTs). However, your configuration might differ in this respect.

For more information on forwarding tickets, see Forwarding Kerberos Tickets.

-F

Forwards a reforwardable copy of your TGT to a remote system. It is similar to -f, but it allows for access to a further (say, fourth or fifth) machine. The -F option can therefore be regarded as being a superset of the -f option. The -F option is mutually exclusive with the -f option. They cannot be used together in the same command.

For more information on forwarding tickets, see Forwarding Kerberos Tickets.

-k realm

Requests tickets for the remote host in the specified realm, instead of determining the realm itself using the krb5.conf file.

-K

Uses your tickets to authenticate to the remote host, but does not automatically log in.

-m mechanism

Specifies the GSS-API security mechanism to use, as listed in the /etc/gss/mech file. Defaults to kerberos_v5.

-x

Encrypts this session.

-X auth-type

Disables the auth-type type of authentication.

The following table shows which commands have specific options. An “X” indicates that the command has that option.

Table 26–1 Kerberos Options for Network Commands

 

ftp

rcp

rlogin

rsh

telnet

-a

 

 

 

 

-f

 

-F

 

 

-k

 

-K

 

 

 

 

-m

 

 

 

 

-x

-X

 

 

 

 

Additionally, ftp allows the protection level for a session to be set at its prompt:

clear

Sets the protection level to “clear” (no protection). This protection level is the default.

private

Sets the protection level to “private.” Data transmissions are confidentiality-protected and integrity-protected by encryption. The privacy service might not be available to all Kerberos users, however.

safe

Sets the protection level to “safe.” Data transmissions are integrity-protected by cryptographic checksum.

You can also set the protection level at the ftp prompt by typing protect followed by any of the protection levels shown above (clear, private, or safe).

Forwarding Kerberos Tickets

As described in Overview of Kerberized Commands, some commands allow you to forward tickets with either the -f or -F option. Forwarding tickets allows you to “chain” your network transactions. You can, for example, remotely log in to one machine and then remotely log in from it to another machine. The -f option allows you to forward a ticket, while the -F option allows you to reforward a forwarded ticket.

In Figure 26–2, the user david obtains a non-forwardable ticket-granting ticket (TGT) with kinit. The ticket is non-forwardable because he did not specify the -f option. In scenario 1, he is able to remotely log in to machine B, but he can go no further. In scenario 2, the rlogin -f command fails because he is attempting to forward a ticket that is non-forwardable.

Figure 26–2 Using Non-Forwardable Tickets

The preceding context describes the graphic.

In actuality, Kerberos configuration files are set up so that kinit obtains forwardable tickets by default. However, your configuration might differ. For the sake of explanation, assume that kinit does not obtain forwardable TGTs unless it is invoked with kinit -f. Notice, by the way, that kinit does not have a -F option. TGTs are either forwardable or not.

In Figure 26–3, the user david obtains forwardable TGTs with kinit -f. In scenario 3, he is able to reach machine C because he uses a forwardable ticket with rlogin. In scenario 4, the second rlogin fails because the ticket is not reforwardable. By using the -F option instead, as in scenario 5, the second rlogin succeeds and the ticket can be reforwarded on to machine D.

Figure 26–3 Using Forwardable Tickets

The preceding context describes the graphic.

Using Kerberized Commands (Examples)

The following examples show how the options to the Kerberized commands work.


Example 26–5 Using the -a, -f, and -x Options With telnet

In this example, the user david has already logged in, and wants to telnet to the machine denver.example.com. He uses the -f option to forward his existing tickets, the -x option to encrypt the session, and the -a option to perform the login automatically. Because he does not plan to use the services of a third host, he can use -f instead of -F.


% telnet -a -f -x denver.example.com 
Trying 128.0.0.5... 
Connected to denver.example.com. Escape character is '^]'. 
[ Kerberos V5 accepts you as "david@eng.example.com" ] 
[ Kerberos V5 accepted forwarded credentials ] 
SunOS 5.9: Tue May 21 00:31:42 EDT 2004  Welcome to SunOS 
%

Notice that david's machine used Kerberos to authenticate him to denver.example.com, and logged him in automatically as himself. He had an encrypted session, a copy of his tickets already waiting for him, and he never had to type his password. If he had used a non-Kerberos version of telnet, he would have been prompted for his password, and it would have been sent over the network unencrypted. If an intruder had been watching network traffic at the time, the intruder would have known david's password.

If you forward your Kerberos tickets, telnet (as well as the other commands discussed here) destroys them when it exits.



Example 26–6 Using rlogin With the -F Option

Here, the user jennifer wants to log in to her own machine, boston.example.com. She forwards her existing tickets with the -F option, and encrypts the session with the -x option. She chooses -F rather than -f because after she is logged in to boston, she might want to perform other network transactions requiring tickets to be reforwarded. Also, because she is forwarding her existing tickets, she does not have to type her password.


% rlogin boston.example.com -F -x
This rlogin session is using encryption for all transmissions.
Last login Mon May 19 15:19:49 from daffodil 
SunOS Release 5.9 (GENERIC) #2 Tue Nov 14 18:09:3 EST 2003 
%


Example 26–7 Setting the Protection Level in ftp

Suppose that joe wants to use ftp to get his mail from the directory ~joe/MAIL from the machine denver.example.com, encrypting the session. The exchange would look like the following:


% ftp -f denver.example.com
Connected to denver.example.com
220 denver.example.org FTP server (Version 6.0) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type 
GSSAPI authentication succeeded Name (daffodil.example.org:joe) 
232 GSSAPI user joe@MELPOMENE.EXAMPLE.COM is authorized as joe
230 User joe logged in.
Remote system type is UNIX.
Using BINARY mode to transfer files.
ftp> protect private
200 Protection level set to Private
ftp> cd ~joe/MAIL
250 CWD command successful.
ftp> get RMAIL
227 Entering Passive Mode (128,0,0,5,16,49)
150 Opening BINARY mode data connection for RMAIL (158336 bytes).
226 Transfer complete. 158336 bytes received in 1.9 seconds (1.4e+02 Kbytes/s)
ftp> quit
% 

To encrypt the session, joe sets the protection level to private.


Chapter 27 The Kerberos Service (Reference)

This chapter lists many of the files, commands, and daemons that are part of the Kerberos product. In addition, this chapter provides detailed information about how Kerberos authentication works.

This is a list of the reference information in this chapter.

Kerberos Files

Table 27–1 Kerberos Files

File Name 

Description 

~/.gkadmin

Default values for creating new principals in the SEAM Administration Tool

~/.k5login

List of principals that grant access to a Kerberos account

/etc/krb5/kadm5.acl

Kerberos access control list file, which includes principal names of KDC administrators and their Kerberos administration privileges

/etc/krb5/kadm5.keytab

Obsolete: This file was removed in the Solaris Express Community Edition, build 102 release.

/etc/krb5/kdc.conf

KDC configuration file

/etc/krb5/kpropd.acl

Kerberos database propagation configuration file

/etc/krb5/krb5.conf

Kerberos realm configuration file

/etc/krb5/krb5.keytab

Keytab file for network application servers

/etc/krb5/warn.conf

Kerberos ticket expiration warning and automatic renewal configuration file

/etc/pam.conf

PAM configuration file

/tmp/krb5cc_uid

Default credentials cache, where uid is the decimal UID of the user

/tmp/ovsec_adm.xxxxxx

Temporary credentials cache for the lifetime of the password changing operation, where xxxxxx is a random string

/var/krb5/.k5.REALM

KDC stash file, which contains a copy of the KDC master key

/var/krb5/kadmin.log

Log file for kadmind

/var/krb5/kdc.log

Log file for the KDC

/var/krb5/principal

Kerberos principal database

/var/krb5/principal.kadm5

Kerberos administrative database, which contains policy information

/var/krb5/principal.kadm5.lock

Kerberos administrative database lock file

/var/krb5/principal.ok

Kerberos principal database initialization file that is created when the Kerberos database is initialized successfully

/var/krb5/principal.ulog

Kerberos update log, which contains updates for incremental propagation

/var/krb5/slave_datatrans

Backup file of the KDC that the kprop_script script uses for propagation

/var/krb5/slave_datatrans_slave

Temporary dump file that is created when full updates are made to the specified slave

Kerberos Commands

This section lists some commands that are included in the Kerberos product.

Table 27–2 Kerberos Commands

Command 

Description 

/usr/bin/ftp

File Transfer Protocol program

/usr/bin/kdestroy

Destroys Kerberos tickets

/usr/bin/kinit

Obtains and caches Kerberos ticket-granting tickets

/usr/bin/klist

Displays current Kerberos tickets

/usr/bin/kpasswd

Changes a Kerberos password

/usr/bin/ktutil

Manages Kerberos keytab files

/usr/bin/rcp

Remote file copy program

/usr/bin/rdist

Remote file distribution program

/usr/bin/rlogin

Remote login program

/usr/bin/rsh

Remote shell program

/usr/bin/telnet

Kerberized telnet program

/usr/lib/krb5/kprop

Kerberos database propagation program

/usr/sbin/gkadmin

Kerberos database administration GUI program, which is used to manage principals and policies

/usr/sbin/gsscred

Manage gsscred table entries

/usr/sbin/kadmin

Remote Kerberos database administration program (run with Kerberos authentication), which is used to manage principals, policies, and keytab files

/usr/sbin/kadmin.local

Local Kerberos database administration program (run without Kerberos authentication and must be run on master KDC), which is used to manage principals, policies, and keytab files

/usr/sbin/kclient

Kerberos client installation script which is used with or without a installation profile

/usr/sbin/kdb5_ldap_util

Creates LDAP containers for Kerberos databases

/usr/sbin/kdb5_util

Creates Kerberos databases and stash files

/usr/sbin/kgcmgr

Configures Kerberos master and slave KDCs

/usr/sbin/kproplog

Lists a summary of update entries in the update log

Kerberos Daemons

The following table lists the daemons that the Kerberos product uses.

Table 27–3 Kerberos Daemons

Daemon 

Description 

/usr/sbin/in.ftpd

File Transfer Protocol daemon

/usr/lib/krb5/kadmind

Kerberos database administration daemon

/usr/lib/krb5/kpropd

Kerberos database propagation daemon

/usr/lib/krb5/krb5kdc

Kerberos ticket processing daemon

/usr/lib/krb5/ktkt_warnd

Kerberos ticket expiration warning and automatic renewal daemon

/usr/sbin/in.rlogind

Remote login daemon

/usr/sbin/in.rshd

Remote shell daemon

/usr/sbin/in.telnetd

telnet daemon

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 26–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 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 27–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 27–1 How a TGT's Lifetime is Determined

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 27–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 a 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.

How the Kerberos Authentication System Works

Applications allow you to log in to a remote system if you can provide a ticket that proves your identity, and a matching session key. The session key contains information that is specific to the user and the service that is being accessed. A ticket and session key are created by the KDC for all users when they first log in. The ticket and the matching session key form a credential. While using multiple networking services, a user can gather many credentials. The user needs to have a credential for each service that runs on a particular server. For example, access to the ftp service on a server named boston requires one credential. Access to the ftp service on another server requires its own credential.

The process of creating and storing the credentials is transparent. Credentials are created by the KDC that sends the credential to the requester. When received, the credential is stored in a credential cache.

Gaining Access to a Service Using Kerberos

To access a specific service on a specific server, the user must obtain two credentials. The first credential is for the ticket-granting ticket (known as the TGT). Once the ticket-granting service has decrypted this credential, the service creates a second credential for the server that the user is requesting access to. This second credential can then be used to request access to the service on the server. After the server has successfully decrypted the second credential, then the user is given access. The following sections describe this process in more detail.

Obtaining a Credential for the Ticket-Granting Service

  1. To start the authentication process, the client sends a request to the authentication server for a specific user principal. This request is sent without encryption. No secure information is included in the request, so it is not necessary to use encryption.

  2. When the request is received by the authentication service, the principal name of the user is looked up in the KDC database. If a principal matches the entry in the database, the authentication service obtains the private key for that principal. The authentication service then generates a session key to be used by the client and the ticket-granting service (call it Session key 1) and a ticket for the ticket-granting service (Ticket 1). This ticket is also known as the ticket-granting ticket (TGT). Both the session key and the ticket are encrypted by using the user's private key, and the information is sent back to the client.

  3. The client uses this information to decrypt Session Key 1 and Ticket 1, by using the private key for the user principal. Because the private key should only be known by the user and the KDC database, the information in the packet should be safe. The client stores the information in the credentials cache.

During this process, a user is normally prompted for a password. If the password the user specifies is the same as the password that was used to build the private key stored in the KDC database, then the client can successfully decrypt the information that is sent by the authentication service. Now the client has a credential to be used with the ticket-granting service. The client is ready to request a credential for a server.

Figure 27–2 Obtaining a Credential for the Ticket-Granting Service

Flow diagram shows a client requesting a credential for
server access from the KDC, and using a password to decrypt the returned credential.

Obtaining a Credential for a Server

  1. To request access to a specific server, a client must first have obtained a credential for that server from the authentication service. See Obtaining a Credential for the Ticket-Granting Service. The client then sends a request to the ticket-granting service, which includes the service principal name, Ticket 1, and an authenticator that was encrypted with Session Key 1. Ticket 1 was originally encrypted by the authentication service by using the service key of the ticket-granting service.

  2. Because the service key of the ticket-granting service is known to the ticket-granting service, Ticket 1 can be decrypted. The information in Ticket 1 includes Session Key 1, so the ticket-granting service can decrypt the authenticator. At this point, the user principal is authenticated with the ticket-granting service.

  3. Once the authentication is successful, the ticket-granting service generates a session key for the user principal and the server (Session Key 2), and a ticket for the server (Ticket 2). Session Key 2 and Ticket 2 are then encrypted by using Session Key 1. Because Session Key 1 is known only to the client and the ticket-granting service, this information is secure and can be safely sent over the network.

  4. When the client receives this information packet, the client decrypts the information by using Session Key 1, which it had stored in the credential cache. The client has obtained a credential to be used with the server. Now the client is ready to request access to a particular service on that server.

Figure 27–3 Obtaining a Credential for a Server

Flow diagram shows a client sending a request encrypted
with Session Key 1 to the KDC, and then decrypting the returned credential
with the same key.

Obtaining Access to a Specific Service

  1. To request access to a specific service, the client must first have obtained a credential for the ticket-granting service from the authentication server, and a server credential from the ticket-granting service. See Obtaining a Credential for the Ticket-Granting Service and Obtaining a Credential for a Server. The client can then send a request to the server including Ticket 2 and another authenticator. The authenticator is encrypted by using Session Key 2.

  2. Ticket 2 was encrypted by the ticket-granting service with the service key for the service. Because the service key is known by the service principal, the service can decrypt Ticket 2 and get Session Key 2. Session Key 2 can then be used to decrypt the authenticator. If the authenticator is successfully decrypted, the client is given access to the service.

Figure 27–4 Obtaining Access to a Specific Service

Flow diagram shows a client using Ticket 2 and an authenticator
encrypted with Session Key 2 to obtain access permission to the server.

Using Kerberos Encryption Types

Encryption types identify which cryptographic algorithms and mode to use when cryptographic operations are performed. The aes, des3-cbc-sha1 and rc4–hmac encryption types enable the creation of keys that can be used for higher strength cryptographic operations. These higher strength operations enhance the overall security of the Kerberos service.


Note –

In releases prior to Solaris 10 8/07 release, the aes256-cts-hmac-sha1-96 encryption type can be used with the Kerberos service if the unbundled Strong Cryptographic packages are installed.


When a client requests a ticket from the KDC, the KDC must use keys whose encryption type is compatible with both the client and the server. While the Kerberos protocol allows the client to request that the KDC use particular encryption types for the client's part of the ticket reply, the protocol does not allow the server to specify encryption types to the KDC.


Note –

If you have a master KDC installed that is not running the Solaris 10 release, the slave KDCs must be upgraded to the Solaris 10 release before you upgrade the master KDC. A Solaris 10 master KDC will use the new encryption types, which an older slave will not be able to handle.


The following lists some of the issues that must be considered before you change the encryption types.

Using the gsscred Table

The gsscred table is used by an NFS server when the server is trying to identify a Kerberos user, if the default mappings are not sufficient. The NFS service uses UNIX IDs to identify users. These IDs are not part of a user principal or a credential. The gsscred table provides additional mapping from GSS credentials to UNIX UIDs (from the password file). The table must be created and administered after the KDC database is populated. See Mapping GSS Credentials to UNIX Credentials for more information.

When a client request comes in, the NFS service tries to map the credential name to a UNIX ID. If the mapping fails, the gsscred table is checked.

Notable Differences Between Solaris Kerberos and MIT Kerberos

The Solaris 10 version of the Kerberos service is based on MIT Kerberos version 1.2.1. The following lists the enhancements included in the Solaris 10 release that are not included in the MIT 1.2.1 version:

This version also includes some post MIT 1.2.1 bug fixes. In particular, 1.2.5 btree bug fixes and 1.3 TCP support have been added.