This section provides information on the configuration, management and use of the Kerberos service.
This chapter introduces the Kerberos Service. The following is a list of the overview information in this chapter.
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.
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.
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.
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.
A client (a user, or a service such as NFS) begins a Kerberos session by requesting a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). This request is often done automatically at login.
A ticket-granting ticket is needed to obtain other tickets for specific services. Think of the ticket-granting ticket as similar to a passport. Like a passport, the ticket-granting ticket identifies you and allows you to obtain numerous “visas,” where the “visas” (tickets) are not for foreign countries but for remote machines or network services. Like passports and visas, the ticket-granting ticket and the other various tickets have limited lifetimes. The difference is that “Kerberized” commands notice that you have a passport and obtain the visas for you. You don't have to perform the transactions yourself.
Another analogy for the ticket-granting ticket is that of a three-day ski pass that is good at four different ski resorts. You show the pass at whichever resort you decide to go to and you receive a lift ticket for that resort, as long as the pass has not expired. Once you have the lift ticket, you can ski all you want at that resort. If you go to another resort the next day, you once again show your pass, and you get an additional lift ticket for the new resort. The difference is that the Kerberos-based commands notice that you have the weekend ski pass, and they get the lift ticket for you. So you don't have to perform the transactions yourself.
The KDC creates a ticket–granting ticket and sends it back, in encrypted form, to the client. The client decrypts the ticket-granting ticket by using the client's password.
Now in possession of a valid ticket-granting ticket, the client can request tickets for all sorts of network operations, such as rlogin or telnet, for as long as the ticket-granting ticket lasts. This ticket usually lasts for a few hours. Each time the client performs a unique network operation, it requests a ticket for that operation from the KDC.
After the client has received the initial authentication, each subsequent authentication follows the pattern that is shown in the following figure.
The client requests a ticket for a particular service, for example, to remote log in to another machine, from the KDC by sending the KDC its ticket-granting ticket as proof of identity.
The KDC sends the ticket for the specific service to the client.
For example, suppose user joe wants to access an NFS file system that has been shared with krb5 authentication required. Because he is already authenticated (that is, he already has a ticket-granting ticket), as he attempts to access the files, the NFS client system automatically and transparently obtains a ticket from the KDC for the NFS service.
For example, suppose the user joe uses rlogin on the server boston. Because he is already authenticated, that is, he already has a ticket-granting ticket, he automatically and transparently obtains a ticket as part of the rlogin command. This ticket allows him to remote log in to boston as often as he wants until the ticket expires. If joe wants to remote log in to the machine denver, he obtains another ticket, as in Step 1.
The client sends the ticket to the server.
When using the NFS service, the NFS client automatically and transparently sends the ticket for the NFS service to the NFS server.
The server allows the client access.
These steps make it appear that the server doesn't ever communicate with the KDC. The server does, though; it registers itself with the KDC, just as the first client does. For simplicity's sake, that part has been left out.
The Kerberos-based (or “Kerberized”) commands that a user such as joe can use are the following:
ftp
rcp
rdist
rlogin
rsh
ssh
telnet
These applications are the same as the Solaris applications of the same name. However, they have been extended to use Kerberos principals to authenticate transactions, thereby providing Kerberos-based security. See Kerberos Principals for information on principals.
These commands are discussed further in Kerberos User Commands.
A client in the Kerberos service is identified by its principal. A principal is a unique identity to which the KDC can assign tickets. A principal can be a user, such as joe, or a service, such as nfs or telnet.
By convention, a principal name is divided into three components: the primary, the instance, and the realm. A typical Kerberos principal would be, for example, joe/admin@ENG.EXAMPLE.COM. In this example:
joe is the primary. The primary can be a user name, as shown here, or a service, such as nfs. The primary can also be the word host, which signifies that this principal is a service principal that is set up to provide various network services, ftp, rcp, rlogin, and so on.
admin is the instance. An instance is optional in the case of user principals, but it is required for service principals. For example, if the user joe sometimes acts as a system administrator, he can use joe/admin to distinguish himself from his usual user identity. Likewise, if joe has accounts on two different hosts, he can use two principal names with different instances, for example, joe/denver.example.com and joe/boston.example.com. Notice that the Kerberos service treats joe and joe/admin as two completely different principals.
In the case of a service principal, the instance is the fully qualified host name. bigmachine.eng.example.com is an example of such an instance. The primary/instance for this example might be ftp/bigmachine.eng.example.com or host/bigmachine.eng.example.com.
ENG.EXAMPLE.COM is the Kerberos realm. Realms are discussed in Kerberos Realms.
The following are all valid principal names:
joe
joe/admin
joe/admin@ENG.EXAMPLE.COM
nfs/host.eng.example.com@ENG.EXAMPLE.COM
host/eng.example.com@ENG.EXAMPLE.COM
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.
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.
In addition to providing secure authentication of users, the Kerberos service provides two security services:
Integrity – Just as authentication ensures that clients on a network are who they claim to be, integrity ensures that the data they send is valid and has not been tampered with during transit. Integrity is done through cryptographic checksumming of the data. Integrity also includes user authentication.
Privacy – Privacy takes security a step further. Privacy not only includes verifying the integrity of transmitted data, but it encrypts the data before transmission, protecting it from eavesdroppers. Privacy authenticates users, as well.
Developers can design their RPC-based applications to choose a security service by using the RPCSEC_GSS programming interface.
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 |
Similar to the MIT distribution of the Kerberos V5 product, the Solaris Kerberos service includes the following:
Key Distribution Center (KDC):
Kerberos database administration daemon – kadmind.
Kerberos ticket processing daemon – krb5kdc.
Database administration programs – kadmin (master only), kadmin.local and kdb5_util.
Database propagation software – kprop (slave only) and kpropd.
User programs for managing credentials – kinit, klist, and kdestroy.
User program for changing your Kerberos password – kpasswd.
Remote applications – ftp, rcp, rdist, rlogin, rsh, ssh, and telnet.
Remote application daemons – ftpd, rlogind, rshd, sshd, and telnetd.
Keytab administration utility – ktutil.
The Generic Security Service Application Programming Interface (GSS-API) – Enables applications to use multiple security mechanisms without requiring you to recompile the application every time a new mechanism is added. The GSS-API uses standard interfaces that allow applications to be portable to many operating systems. GSS-API provides applications with the ability to include the integrity and privacy security services, as well as authentication. Both ftp and ssh use the GSS-API.
The RPCSEC_GSS Application Programming Interface (API) – Enables NFS services to use Kerberos authentication. RPCSEC_GSS is a security flavor that provides security services that are independent of the mechanisms being used. RPCSEC_GSS sits on top of the GSS-API layer. Any pluggable GSS_API-based security mechanism can be used by applications that use RPCSEC_GSS.
In addition, the Solaris Kerberos service includes the following:
Graphical Kerberos Administration Tool (gkadmin) – Enables you to administer the principals and principal policies. This JavaTM technology-based GUI is an alternative to the kadmin command.
A Kerberos V5 service module for PAM – Provides authentication, account management, session management and password management for the Kerberos service. The module can be used to make Kerberos authentication transparent to the user.
Kernel modules – Provides kernel-based implementations of the kerberos service for use by the NFS service, which greatly improves performance.
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.
These enhancements are available starting in the Solaris Express Developer Edition 1/08 release:
The Solaris Kerberos software has been synchronized with the MIT 1.4 version. In particular, the software for the KDC, the kinit command and the Kerberos mechanism have been updated.
Support for accessing Kerberos principal and policy records using LDAP from a directory server has been added. This change simplifies administration and can provide greater availability, depending on the deployment of the KDCs and the DSs. See Managing a KDC on an LDAP Directory Server for a list of LDAP-related procedures.
The new kdcmgr command which can be used to automatically or interactively setup any KDC. This command works to create both master and slave KDC servers. Also, used with the status option, the kdcmgr command shows information about any KDC installed on the localhost. Look for the pointers to the automatic or interactive procedures in Table 23–1.
Support for Solaris clients that require no additional setup has been added to this release. Changes were made to the Kerberos service and to some default settings. Solaris Kerberos clients work with no client-side configuration in environments that are appropriately configured. See Client Configuration Options for more information.
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.
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.
These Kerberos enhancements are included in the Solaris 10 Release. Several of the enhancements were introduced in prior Software Express releases and updated in the Solaris 10 Beta releases.
Kerberos protocol support is provided in remote applications, such as ftp, rcp, rdist, rlogin, rsh, ssh, and telnet. See the man pages for each command or daemon and the krb5_auth_rules(5) man page for more information.
The Kerberos principal database can now be transferred by incremental update instead of by transferring the entire database each time. Incremental propagation provides these advantages:
Increased database consistencies across servers
The need for fewer resources (network, CPU, and so forth)
Much more timely propagation of updates
An automated method of propagation
A new script to help automatically configure a Kerberos client is now available. The script helps an administrator quickly and easily set up a Kerberos client. For procedures using the new script, see Configuring Kerberos Clients. Also, see the kclient(1M) man page for more information.
Several new encryption types have been added to the Kerberos service. These new encryption types increase security and enhance compatibility with other Kerberos implementations that support these encryption types. See Using Kerberos Encryption Types for more information. The encryption types include:
The AES encryption type can be used for high speed, high security encryption of Kerberos sessions.
ARCFOUR-HMAC provides better compatibility with other Kerberos implementations.
Triple DES (3DES) with SHA1 increases security. This encryption type also enhances interoperability with other Kerberos implementations that support this encryption type.
The encryption types are enabled through the Cryptographic Framework. The framework can provide for hardware accelerated cryptography for the Kerberos service.
The KDC software, the user commands, and user applications now support the use of the TCP network protocol. This enhancement provides more robust operation and better interoperability with other Kerberos implementations, including Microsoft's Active Directory. The KDC now listens on both the traditional UDP ports as well as TCP ports so it can respond to requests using either protocol. The user commands and applications first try UDP when sending a request to the KDC, and if that fails, then try TCP.
Support for IPv6 was added to the KDC software, which includes the kinit, klist and kprop commands. Support for IPv6 addresses is provided by default. There are no configuration parameters to change to enable IPv6 support. No IPv6 support is available for the kadmin and kadmind commands.
A new -e option has been included to several subcommands of the kadmin command. This new option allows for the selection of the encryption type during the creation of principals. See the kadmin(1M) man page for more information.
Additions to the pam_krb5 module to manage the Kerberos credentials cache by using the PAM framework. See the pam_krb5(5) man page for more information.
Support is provided for auto-discovery of the Kerberos KDC, admin server, kpasswd server, and host or domain name-to-realm mappings by using DNS lookups. This enhancement reduces some of the steps needed to install a Kerberos client. The client is able to locate a KDC server by using DNS instead of by reading a configuration file. See the krb5.conf(4) man page for more information.
A new PAM module called pam_krb5_migrate has been introduced. The new module helps in the automatic migration of users to the local Kerberos realm, if they do not already have Kerberos accounts. See the pam_krb5_migrate(5) man page for more information.
The ~/.k5login file can now be used with the GSS applications ftp and ssh. For more information, see the gss_auth_rules(5) man page.
The kproplog utility has been updated to output all attribute names per log entry. For more information, see the kproplog(1M) man page.
Strict TGT verification can now be disabled using a configuration option in the krb5.conf file. See the krb5.conf(4) man page for more information.
Extensions to the password-changing utilities enable the Solaris Kerberos V5 administration server to accept password change requests from clients that do not run Solaris software. See the kadmind(1M) man page for more information.
The default location of the replay cache has been moved from RAM-based file systems to persistent storage in /var/krb5/rcache/. The new location protects against replays if a system is rebooted. Performance enhancements were made to the rcache code. However, overall replay cache performance might be slower due to the use of persistent storage.
The replay cache can now be configured to use file or memory only storage. Refer to the krb5envvar(5) man page for more information about environment variables that can be configured for key table and credential cache types or locations.
The GSS credential table is no longer necessary for the Kerberos GSS mechanism. For more information, see Mapping GSS Credentials to UNIX Credentials or the gsscred(1M), gssd(1M), and gsscred.conf(4) man pages.
The Kerberos utilities, kinit and ktutil, are now based on MIT Kerberos version 1.2.1. This change added new options to the kinit command and new subcommands to the ktutil command. For more information, see the kinit(1) and ktutil(1) man pages.
The Solaris Kerberos Key Distribution Center (KDC) and kadmind is now based on MIT Kerberos version 1.2.1. The KDC now defaults to a btree-based database, which is more reliable than the current hash-based database. See the kdb5_util(1M) man page for more information.
The kpropd, kadmind, krb5kdc and ktkt_warnd daemons are managed by the Service Management Facility. Administrative actions on this service, such as enabling, disabling, or restarting, can be performed using the svcadm command. The service's status for all daemons can be queried using the svcs command. For an overview of the Service Management Facility refer to Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration.
The Solaris 9 release includes all components included in Kerberos Components, except for the remote applications.
The SEAM 1.0.2 release includes the remote applications. These applications are the only part of SEAM 1.0 that have not been incorporated into the Solaris 9 release. The components for the remote applications are as follows:
Client applications – ftp, rcp, rlogin, rsh, and telnet
Server daemons – ftpd, rlogind, rshd, and telnetd
The Solaris 8 release includes only the client-side portions of the Kerberos service, so many components are not included. This product enables systems that run the Solaris 8 release to become Kerberos clients without requiring you to install SEAM 1.0.1 separately. To use these capabilities, you must install a KDC that uses either Solaris Easy Access Server 3.0 or the Solaris 8 Admin Pack, the MIT distribution, or Windows 2000. The client-side components are not useful without a configured KDC to distribute tickets. The following components are included in this release:
User programs for obtaining, viewing, and destroying tickets – kinit, klist, and kdestroy.
User program for changing your Kerberos password – kpasswd.
Key table administration utility – ktutil.
Additions to the Pluggable Authentication Module (PAM) – Enables applications to use various authentication mechanisms. PAM can be used to make logins and logouts transparent to the user.
GSS_API plug–ins – Provides Kerberos protocol and cryptographic support.
NFS client and server support.
The SEAM 1.0.1 release includes all components of the SEAM 1.0 release that are not already included in the Solaris 8 release. The components are as follows:
Key Distribution Center (KDC) (master):
Kerberos database administration daemon – kadmind
Kerberos ticket processing daemon – krb5kdc
Slave KDCs.
Database administration programs – kadmin and kadmin.local.
Database propagation software – kprop.
Remote applications – ftp, rcp, rlogin, rsh, and telnet.
Remote application daemons – ftpd, rlogind, rshd, and telnetd.
Administration utility – kdb5_util.
Graphical Kerberos Administration Tool (gkadmin) – Enables you to administer principals and principal policies. This Java technology-based GUI is an alternative to the kadmin command.
A preconfiguration procedure – Enables you to set the parameters for installing and configuring SEAM 1.0.1, which makes SEAM installation automatic. This procedure is especially useful for multiple installations.
Several libraries.
The SEAM 1.0 release includes all of the items included in Kerberos Components as well as the following:
A utility (gsscred) and a daemon (gssd) – These programs help map UNIX user IDs (UIDs) to principal names. These programs are needed because NFS servers use UNIX UIDs to identify users and not principal names, which are stored in a different format.
The Generic Security Service Application Programming Interface (GSS-API) – Enables applications to use multiple security mechanisms without requiring you to recompile the application every time a new mechanism is added. Because GSS-API is machine-independent, it is appropriate for applications on the Internet. GSS-API provides applications with the ability to include the integrity and privacy security services, as well as authentication.
The RPCSEC_GSS Application Programming Interface (API) – Enables NFS services to use Kerberos authentication. RPCSEC_GSS is a security flavor that provides security services that are independent of the mechanisms being used. RPCSEC_GSS sits on top of the GSS-API layer. Any pluggable GSS_API-based security mechanism can be used by applications that use RPCSEC_GSS.
A preconfiguration procedure – Enables you to set the parameters for installing and configuring SEAM 1.0, which makes installation automatic. This procedure is especially useful for multiple installations.
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:
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.
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 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.
The number of realms that your installation requires depends on several factors:
The number of clients to be supported. Too many clients in one realm makes administration more difficult and eventually requires that you split the realm. The primary factors that determine the number of clients that can be supported are as follows:
The amount of Kerberos traffic that each client generates
The bandwidth of the physical network
The speed of the hosts
Because each installation will have different limitations, no rule exists for determining the maximum number of clients.
How far apart the clients are. Setting up several small realms might make sense if the clients are in different geographic regions.
The number of hosts that are available to be installed as KDCs. Each realm should have at least two KDC servers, one master server and one slave server.
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.
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.
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.
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.
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.
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:
The number of physical segments in the realm. Normally, the network should be set up so that each segment can function, at least minimally, without the rest of the realm. To do so, a KDC must be accessible from each segment. The KDC in this instance could be either a master or a slave.
The number of clients in the realm. By adding more slave KDC servers, you can reduce the load on the current servers.
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.
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:
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.
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.
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.
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:
DNS is configured to return SRV records for KDCs.
The realm name matches the DNS domain name or the KDC supports referrals.
The Kerberos client does not require a keytab.
In some cases it may be better to explicitly configure the Kerberos client:
If referrals are not used, the zero-configuration logic depends on the DNS domain name of the host to determine the realm. This introduces a small security risk, but the risk is much smaller than enabling dns_lookup_realm.
The pam_krb5 module relies on a host key entry in the keytab. This requirement may be disabled in the krb5.conf file however it is not recommend for security reasons. See the krb5.conf(4)man page.
The zero-configuration process is less efficient than direct configuration, and has a greater reliance on DNS. The process performs more DNS lookups than a directly configured client.
See Configuring Kerberos Clients for a description of all the client configuration processes.
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.
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.
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:
des-cbc-md5
des-cbc-crc
des3-cbc-sha1-kd
arcfour-hmac-md5
arcfour-hmac-md5-exp
aes128-cts-hmac-sha1-96
aes256-cts-hmac-sha1-96
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.
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 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.
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.
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. | |
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. | |
3. Configure the KDC servers. |
Configures and builds the master KDC and the slave KDC servers and the KDC database for a realm. | |
4. (Optional) Increase security on the KDC servers. |
Prevents security breaches on the KDC servers. | |
5. (Optional) Configure swappable KDC servers. |
Makes the task of swapping the master KDC and a slave KDC easier. |
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. | |
Configure Kerberos application servers. |
Enables a server to support services such as ftp, telnet, and rsh using Kerberos authentication. | |
Configure Kerberos clients. |
Enables a client to use Kerberos services. | |
Configure Kerberos NFS server. |
Enables a server to share a file system that requires Kerberos authentication. | |
Increase security on an application server. |
Increases security on an application server by restricting access to authenticated transactions only. |
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. | |
Configures and builds the master KDC server and database for a realm using an interactive process, which is sufficient for most installations | ||
Configures and builds the master KDC server and database for a realm using a manual process, which is needed for more complex installations | ||
Configures and builds the master KDC server and database for a realm using a manual process and using LDAP for the KDC | ||
Configuring a slave KDC server. |
Configures and builds a slave KDC server for a realm using an automatic process, which is good for scripts | |
Configures and builds a slave KDC server for a realm using an interactive process, which is sufficient for most installations | ||
Configures and builds a slave KDC server for a realm using a manual process, which is needed for more complex installations | ||
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 |
Starting with the Solaris Express Developer Edition 1/08 release, a master KDC can be automatically configured by using the following procedure.
Become superuser.
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# |
Starting with the Solaris Express Developer Edition 1/08 release, a master KDC can be interactively configured by using the following procedure.
Become superuser.
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# |
The kdcmgr status command can be used to display information about either a master or a slave KDC server.
In this procedure, incremental propagation is configured. In addition, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
admin principal = kws/admin
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in Online Help URL in the Graphical Kerberos Administration Tool.
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.
Become superuser on the master KDC.
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.
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.
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.
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.
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> |
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.
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: |
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: |
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: |
Quit kadmin.local.
You have added all of the required principals for the next steps.
kadmin.local: quit |
Start the Kerberos daemons.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
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: |
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: |
(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: |
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: |
Quit kadmin.
kadmin: quit |
(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.
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.
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:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Directory Server = dsserver.example.com
admin principal = kws/admin
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in Online Help URL in the Graphical Kerberos Administration Tool.
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.
Become superuser on the KDC.
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.
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 |
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 |
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.
Populate the LDAP directory, if necessary.
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 |
Create the Kerberos container in the LDAP directory.
Add the following entries to the krb5.conf file.
Define the database type.
Add an entry to define the database_moduleto the realms section.
database_module = LDAP |
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 } |
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 |
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" |
Add KDC service roles.
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 |
Create the role entries in the LDAP directory
# ldapmodify -a -h dsserver.example.com -D "cn=directory manager" -f kdc_roles.ldif |
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 |
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.
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.
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.
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.
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.
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: |
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: |
Quit kadmin.local.
You have added all of the required principals for the next steps.
kadmin.local: quit |
Start the Kerberos daemons.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
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: |
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: |
(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: |
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: |
Quit kadmin.
kadmin: quit |
(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.
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.
Starting with the Solaris Express Developer Edition 1/08 release, a slave KDC can be automatically configured by using the following procedure.
Become superuser.
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# |
Starting with the Solaris Express Developer Edition 1/08 release, a slave KDC can be interactively configured by using the following procedure.
Become superuser.
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# |
In this procedure, a new slave KDC named kdc2 is configured. Also, incremental propagation is configured. This procedure uses the following configuration parameters:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com
admin principal = kws/admin
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.
On the master KDC, become superuser.
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: |
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: |
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: |
Quit kadmin.
kadmin: quit |
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 } |
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 |
On the master KDC, restart kadmind to use the new entries in the kadm5.acl file.
kdc1 # svcadm restart network/security/kadmin |
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
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 |
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.
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 } |
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: |
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: |
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: |
Quit kadmin.
kadmin: quit |
On the new slave, start the Kerberos propagation daemon.
kdc2 # svcadm enable network/security/krb5_prop |
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> |
(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.
On the new slave, start the KDC daemon (krb5kdc).
kdc2 # svcadm enable network/security/krb5kdc |
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.
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 |
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' |
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).
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.
The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.
Become superuser on the first master KDC.
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 |
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.
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.
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.
Repeat all of these steps in the second realm.
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.
The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.
Become superuser on one of the master KDC servers.
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 |
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.
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 = . } |
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.
Repeat all of these steps for the second realm.
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.
This procedure uses the following configuration parameters:
Application server = boston
admin principal = kws/admin
DNS domain name = example.com
Realm name = EXAMPLE.COM
This procedure requires that the master KDC has been configured. To fully test the process, several Kerberos clients must be configured.
(Optional) Install the NTP client or another clock synchronization mechanism.
See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
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: |
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: |
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: |
Quit kadmin.
kadmin: quit |
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. | |
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. | |
Change the credential table that maps user credentials to UNIX UIDs. |
Updates information in 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. | |
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 |
In this procedure, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
NFS server = denver.example.com
admin principal = kws/admin
Complete the prerequisites for configuring a Kerberos NFS server.
The master KDC must be configured. To fully test the process, you need several clients.
(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.
Configure the NFS server as a Kerberos client.
Follow the instructions in Configuring Kerberos Clients.
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: |
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: |
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: |
Quit kadmin.
kadmin: quit |
(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.
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.
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.
Edit /etc/gss/gsscred.conf and change the security mechanism.
Change the mechanism to files.
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.
This procedure requires that the gsscred table has already been created on the NFS server. See How to Create a Credential Table for instructions.
Become superuser on the NFS server.
Add an entry to the credential table by using the gsscred command.
# gsscred -m mech [ -n name [ -u uid ]] -a |
Defines the security mechanism to be used.
Defines the principal name for the user, as defined in the KDC.
Defines the UID for the user, as defined in the password database.
Adds the UID to principal name mapping.
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 |
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 |
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.
Become superuser.
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 . } |
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 . } |
See Observing Mapping from GSS Credentials to UNIX Credentials to help with the process of troubleshooting credential mapping problems.
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.
Become superuser on the NFS server.
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 |
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 |
Share the file systems with the appropriate security modes.
sharemgr share -o sec=mode file-system |
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.
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.
(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 |
(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 |
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 |
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 |
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.
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. | |
Configure a Kerberos client. |
Manually installs a Kerberos client. Use this procedure if each client installation requires unique installation parameters. | |
Automatically installs a Kerberos client. Use this procedure if the installation parameters for each client are the same. | ||
Interactively installs a Kerberos client. Use this procedure if only a few of the installation parameters need to change. | ||
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) |
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.
Become superuser.
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 |
This procedure uses an installation profile. See How to Create a Kerberos Client Installation Profile.
Become superuser.
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# |
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# |
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.
Become superuser.
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
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.
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.
Define the name of the Kerberos realm and the master KDC hostname.
This information is added to the /etc/krb5/krb5.conf configuration file.
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.
Indicate if service or host keys are required.
Normally, service or host keys are not required unless the client system is hosting Kerberized services.
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.
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.
Specify if the client will use Kerberized NFS.
NFS service keys need to be created if the client will host NFS services using Kerberos.
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
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.
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. |
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 ! # |
This procedure uses the kclient installation utility without a installation profile.
Become superuser.
(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 |
Run the kclient installation script.
You need to provide the following information:
Password for the administrative principal
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. # |
In this procedure, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com
NFS server = denver.example.com
Client = client.example.com
admin principal = kws/admin
User principal = mre
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in the Online Help URL in the Graphical Kerberos Administration Tool.
Become superuser.
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 |
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.
(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.
(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.
(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.
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: |
(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: |
(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: |
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: |
(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: |
Quit kadmin.
kadmin: quit |
(Optional) Enable Kerberos with NFS.
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 |
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.
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 |
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.
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 } |
@ 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" |
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 |
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:
The client IP address is dynamically assigned. For instance, a DHCP client.
The client is not configured to host any services, so no host principal was created.
The host key is not stored on the client.
Become superuser.
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 ... |
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.
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.
Become superuser.
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: |
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: |
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: |
Quit kadmin.
kadmin: quit |
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:
Realm name = EXAMPLE.COM
Master KDC = kdc1.example.com
Machine hosting the migration service = server1.example.com
Migration service principal = host/server1.example.com
Setup server1 as a Kerberos client of the realm EXAMPLE.COM. See Configuring Kerberos Clients for more information.
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 |
Make changes to the PAM configuration file.
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 |
(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 |
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 |
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 |
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 * |
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 |
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 |
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.
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.
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.
Ensuring that the KDCs and Kerberos clients maintain synchronized clocks involves implementing the following steps:
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.
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.
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).
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.
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.
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.
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 |
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.
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).
On the new master KDC, start kadmin.
kdc4 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
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: |
Quit kadmin.
kadmin: quit |
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 |
On the new master KDC, verify that the update is complete.
kdc4 # /usr/sbin/kproplog -h |
On the new master KDC, restart the KDC service.
kdc4 # svcadm enable -r network/security/krb5kdc |
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 |
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 |
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 } |
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 |
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 |
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 |
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 |
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 |
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 } |
On the new master KDC, start kadmind and krb5kdc.
kdc4 # svcadm enable -r network/security/krb5kdc kdc4 # svcadm enable -r network/security/kadmin |
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 |
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 |
On the old master KDC, start kpropd and krb5kdc.
kdc1 # svcadm enable -r network/security/krb5_prop kdc1 # svcadm enable -r network/security/krb5kdc |
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.
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.
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 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 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.
Become superuser on the master KDC.
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...]] |
Prints the name of each principal and policy that is being backed up.
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.
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.
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.
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 |
Become superuser on the master KDC.
On the master, stop the KDC daemons.
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin |
Restore the Kerberos database by using the load command of the kdb_util command.
# /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename] |
Prints the name of each principal and policy that is being restored.
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.
Updates the existing database. Otherwise, a new database is created or the existing database is overwritten.
Defines the file from which to restore the database. You can specify an absolute path for the file.
Start the KDC daemons.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
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 |
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.
Make sure that the database is using an older format.
On the master, stop the KDC daemons.
kdc1 # svcadm disable network/security/krb5kdc kdc1 # svcadm disable network/security/kadmin |
Create a directory to store a temporary copy of the database.
kdc1 # mkdir /var/krb5/tmp kdc1 # chmod 700 /var/krb5/tmp |
Dump the KDC database.
kdc1 # kdb5_util dump /var/krb5/tmp/prdb.txt |
Save copies of the current database files.
kdc1 # cd /var/krb5 kdc1 # mv princ* tmp/ |
Load the database.
kdc1 # kdb5_util load /var/krb5/tmp/prdb.txt |
Start the KDC daemons.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
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:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com
admin principal = kws/admin
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 } |
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: |
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 |
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 |
Restart kadmind.
kdc1 # svcadm restart network/security/kadmin |
Reconfigure all slave KDC servers that use incremental propagation.
See How to Reconfigure a Slave KDC to Use Incremental Propagation for complete instructions.
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 } |
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 |
Restart kpropd.
kdc2 # svcadm restart network/security/krb5_prop |
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:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com and kdc3.example.com
admin principal = kws/admin
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in the Online Help URL in the Graphical Kerberos Administration Tool.
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.
On the master KDC, become superuser.
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: |
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: |
Quit kadmin.
kadmin: quit |
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 } |
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 |
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
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.
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: |
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: |
Quit kadmin.
kadmin: quit |
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.
On the new slave, start the Kerberos propagation daemon.
kdc3 # svcadm enable network/security/krb5_prop |
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 |
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> |
(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.
On the new slave, start the KDC daemon (krb5kdc).
kdc3 # svcadm enable network/security/krb5kdc |
If incremental propagation has been configured, this procedure ensures that the information on the slave KDC has been updated.
On the KDC master server, run the kproplog command.
kdc1 # /usr/sbin/kproplog -h |
On a KDC slave server, run the kproplog command.
kdc2 # /usr/sbin/kproplog -h |
Check that the last serial # and the last timestamp values match.
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.
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.
Do not use this procedure if you are using incremental propagation.
Become superuser on the master KDC.
(Optional) Back up the database by using the kdb5_util command.
# /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans |
Propagate the database to a slave KDC by using the kprop command.
# /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC |
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 |
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.
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.
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:
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).
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.
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.
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.
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 |
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.
Become superuser on the KDC that contains the stash file.
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.
If you need to re-create the stash file, you can use the -f option of the kdb5_util command.
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. | |
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 |
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:
Directory Server = dsserver.example.com
user principal = willf@EXAMPLE.COM
Become superuser.
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 |
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 |
(Optional) If the KDC records are stored in DB2, migrate DB2 entries.
(Optional) Add the principal attributes to the KDC.
# kadmin.local -q 'addprinc willf' |
This procedure can be used if a different LDAP Directory Server has been configured to handle a realm.
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 | |
Restricting access to the KDC servers |
Increases the security of the KDC servers and their data. | |
Increasing password security by using a dictionary file |
Increases the security of any new passwords by checking the new password against a dictionary. |
This procedure restricts network access to the server that is running telnet, ftp, rcp, rsh, and rlogin to use Kerberos authenticated transactions only.
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" |
(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" |
Disable other services.
The in.rshd and in.rlogind daemons should be disabled.
# svcadm disable network/shell # svcadm disable network/login:rlogin |
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.
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 |
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.
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.
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.
Become superuser on the master KDC.
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 } |
Restart the Kerberos daemons.
kdc1 # svcadm restart -r network/security/krb5kdc kdc1 # svcadm restart -r network/security/kadmin |
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.
This section provides information about Kerberos error messages, including why each error occurs and a way to fix it.
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.
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:
Add the SUNWcry and SUNWcryr packages to the KDC server. This increases the number of encryption types supported by the KDC.
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.
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.
This section provides troubleshooting information for the Kerberos software.
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.
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.
If mounting a Kerberized NFS file system fails, make sure that the /var/rcache/root file exists on the NFS server. If the file system is not owned by root, remove it and try the mount again.
If you have a problem accessing a Kerberized NFS file system, make sure that the gssd service is enabled on your system and the NFS server.
If you see either the invalid argument or bad directory error message when you are trying to access a Kerberized NFS file system, the problem might be that you are not using a fully qualified DNS name when you are trying to mount the NFS file system. The host that is being mounted is not the same as the host name part of the service principal in the server's keytab file.
This problem might also occur if your server has multiple Ethernet interfaces, and you have set up DNS to use a “name per interface” scheme instead of a “multiple address records per host” scheme. For the Kerberos service, you should set up multiple address records per host as follows [Ken Hornstein, “Kerberos FAQ,” [http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html], accessed 11 December 1998.] :
my.host.name. A 1.2.3.4 A 1.2.4.4 A 1.2.5.4 my-en0.host.name. A 1.2.3.4 my-en1.host.name. A 1.2.4.4 my-en2.host.name. A 1.2.5.4 4.3.2.1 PTR my.host.name. 4.4.2.1 PTR my.host.name. 4.5.2.1 PTR my.host.name.
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.
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.
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.
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.
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:
kadmin – Uses Kerberos authentication to operate securely from anywhere on the network
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.
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:
Create new principals that are based on default values or existing principals.
Create new policies that are based on existing policies.
Add comments for principals.
Set up default values for creating new principals.
Log in as another principal without exiting the tool.
Print or save principal lists and policy lists.
View and search principal lists and policy lists.
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.
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 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.
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:
List of available principals on the specified master KDC
List of available policies on the specified master KDC
The currently selected principal or the loaded principal
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.
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.
Start the SEAM Tool by using the gkadmin command.
$ /usr/sbin/gkadmin |
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.
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.
Type a password for the specified principal name.
Click OK.
A window showing all of the principals is displayed.
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.
Task |
Description |
For Instructions |
---|---|---|
View the list of principals. |
View the list of principals by clicking the Principals tab. | |
View a principal's attributes. |
View a principal's attributes by selecting the Principal in the Principal List, then clicking the Modify button. | |
Create a new principal. |
Create a new principal by clicking the Create New button in the Principal List panel. | |
Duplicate a principal. |
Duplicate a principal by selecting the principal to duplicate in the Principal List, then clicking the Duplicate button. | |
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. | |
Delete a principal. |
Delete a principal by selecting the principal to delete in the Principal List, then clicking the Delete button. | |
Set up defaults for creating new principals. |
Set up defaults for creating new principals by choosing Properties from the Edit menu. | |
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. |
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.
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Principals tab.
The list of principals is displayed.
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.
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 |
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Principals tab.
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.
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.
When you are finished viewing, click Cancel.
The following example shows the first window when you are viewing the jdb/admin principal.
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 |
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
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 |
Click the Principals tab.
Click New.
The Principal Basics panel that contains some attributes for a principal is displayed.
Specify a principal name and a password.
Both the principal name and the password are mandatory.
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.
Specify the policy for the principal.
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.
Click Save to save the principal, or click Done on the last panel.
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.
The following example shows the Principal Basics panel when a new principal called pak is created. The policy is set to testuser.
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 |
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.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Principals tab.
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.
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.
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.
Click Save to save the principal, or click Done on the last panel.
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.
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Principals tab.
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.
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.
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.
Click Save to save the principal, or click Done on the last panel.
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.
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.
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Principals tab.
Select the principal in the list that you want to delete, then click Delete.
After you confirm the deletion, the principal is deleted.
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.
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 |
No command-line equivalent exists for this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Choose Properties from the Edit Menu.
The Properties window is displayed.
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.
Click Save.
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.
Become superuser on the master KDC.
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. |
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 |
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.
Task |
Description |
For Instructions |
---|---|---|
View the list of policies. |
View the list of policies by clicking the Policies tab. | |
View a policy's attributes. |
View a policy's attributes by selecting the policy in the Policy List, then clicking the Modify button. | |
Create a new policy. |
Create a new policy by clicking the Create New button in the Policy List panel. | |
Duplicate a policy. |
Duplicate a policy by selecting the policy to duplicate in the Policy List, then clicking the Duplicate button. | |
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. | |
Delete a policy. |
Delete a policy by selecting the policy to delete in the Policy List, then clicking the Delete button. |
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Policies tab.
The list of policies is displayed.
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.
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 |
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Policies tab.
Select the policy in the list that you want to view, then click Modify.
The Policy Details panel is displayed.
When you are finished viewing, click Cancel.
The following example shows the Policy Details panel when you are viewing the test policy.
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.
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Policies tab.
Click New.
The Policy Details panel is displayed.
Specify a name for the policy in the Policy Name field.
The policy name is mandatory.
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.
Click Save to save the policy, or click Done.
In the following example, a new policy called build11 is created. The Minimum Password Classes is set to 3.
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 |
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.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Policies tab.
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.
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.
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.
Click Save to save the policy, or click Done.
An example of the command-line equivalent follows this procedure.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for details.
$ /usr/sbin/gkadmin |
Click the Policies tab.
Select the policy in the list that you want to modify, then click Modify.
The Policy Details panel is displayed.
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.
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.
Click Save to save the policy, or click Done.
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 |
An example of the command-line equivalent follows this procedure.
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.
If necessary, start the SEAM Tool.
See How to Start the SEAM Tool for more information.
$ /usr/sbin/gkadmin |
Click the Policies tab.
Select the policy in the list that you want to delete, then click Delete.
After you confirm the deletion, the policy is deleted.
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.
This section provides descriptions of each panel in the SEAM Tool. Also, information about using limited privileges with SEAM Tool are provided.
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) |
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. |
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.
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.
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. | |
Remove a service principal from a keytab file. |
Use the ktremove command of kadmin to remove a service 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. | |
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 |
Make sure that the principal already exists in the Kerberos database.
See How to View the List of Kerberos Principals for more information.
Become superuser on the host that needs a principal added to its keytab file.
Start the kadmin command.
# /usr/sbin/kadmin |
Add a principal to a keytab file by using the ktadd command.
kadmin: ktadd [-e enctype] [-k keytab] [-q] [principal | -glob principal-exp] |
Overrides the list of encryption types defined in the krb5.conf file.
Specifies the keytab file. By default, /etc/krb5/krb5.keytab is used.
Displays less verbose information.
Specifies the principal to be added to the keytab file. You can add the following service principals: host, root, nfs, and ftp.
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.
Quit the kadmin command.
kadmin: quit |
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 |
Become superuser on the host with a service principal that must be removed from its keytab file.
Start the kadmin command.
# /usr/sbin/kadmin |
(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.
Remove a principal from the keytab file by using the ktremove command.
kadmin: ktremove [-k keytab] [-q] principal [kvno | all | old ] |
Specifies the keytab file. By default, /etc/krb5/krb5.keytab is used.
Displays less verbose information.
Specifies the principal to be removed from the keytab file.
Removes all entries for the specified principal whose key version number matches kvno.
Removes all entries for the specified principal.
Removes all entries for the specified principal, except those principals with the highest key version number.
Quit the kadmin command.
kadmin: quit |
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 |
Become superuser on the host with the keytab file.
Although you can create keytab files that are owned by other users, using the default location for the keytab file requires root ownership.
Start the ktutil command.
# /usr/bin/ktutil |
Read the keytab file into the keylist buffer by using the read_kt command.
ktutil: read_kt keytab |
Display the keylist buffer by using the list command.
ktutil: list |
The current keylist buffer is displayed.
Quit the ktutil command.
ktutil: quit |
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 |
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.
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.
Become superuser on the host with the keytab file.
Although you can create keytab files that are owned by other users, using the default location for the keytab file requires root ownership.
Save the current keytab file to a temporary file.
Start the ktutil command.
# /usr/bin/ktutil |
Read the keytab file into the keylist buffer by using the read_kt command.
ktutil: read_kt keytab |
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.
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.
Write the keylist buffer to a new keytab file by using the write_kt command.
ktutil: write_kt new-keytab |
Quit the ktutil command.
ktutil: quit |
Move the new keytab file.
# mv new-keytab keytab |
When you want to re-enable the service, copy the temporary (original) keytab file back to its original location.
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 |
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.
This section explains how to obtain, view, and destroy tickets. For an introduction to tickets, see How the Kerberos Service Works.
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.
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.
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.
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:
Preauthenticated
Postdatable
Postdated
Forwardable
Forwarded
Initial
Invalid
Proxiable
Proxy
Renewable
Types of Tickets describes the various attributes that a ticket can have.
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 |
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.
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.
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:
Words that can be found in a dictionary
Any common or popular name
The name of a famous person or character
Your name or user name in any form (for example: your name spelled backward, repeated twice, and so forth)
A spouse's name, child's name, or pet's name
Your birth date or a relative's birth date
Your social security number, driver's license number, passport number, or other similar identifying number
Any sample password that appears in this manual or any other manual
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:
Acronyms, such as “I2LMHinSF” (which is recalled as “I too left my heart in San Francisco”)
Easy-to-pronounce nonsense words, such as “WumpaBun” or “WangDangdoodle!”
Deliberately misspelled phrases, such as “6o'cluck” or “RrriotGrrrlsRrrule!”
Don't use these examples. Passwords that appear in manuals are the first passwords that an intruder will try.
If PAM is properly configured, you can change your Kerberos password in two ways:
With the usual UNIX passwd command. With the Kerberos service configured, the Solaris passwd command also automatically prompts for a new Kerberos password.
The advantage of using passwd instead of kpasswd is that you can set both UNIX and Kerberos passwords at the same time. However, you generally do not have to change both passwords with passwd. Often, you can change only your UNIX password and leave the Kerberos password untouched, or vice-versa.
The behavior of passwd depends on how the PAM module is configured. You might be required to change both passwords in some configurations. For some sites, the UNIX password must be changed, while other sites require the Kerberos password to change.
With the kpasswd command. kpasswd is very similar to passwd. One difference is that kpasswd changes only Kerberos passwords. You must use passwd if you want to change your UNIX password.
Another difference is that kpasswd can change a password for a Kerberos principal that is not a valid UNIX user. For example, david/admin is a Kerberos principal, but not an actual UNIX user, so you must use kpasswd instead of passwd.
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. |
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. |
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.
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:
You can take access away any time by removing the principal from your .k5login file.
Although users principals named in the .k5login file in your home directory have full access to your account on that machine (or sets of machines, if the .k5login file is shared, for example, over NFS). However, any Kerberized services will authorize access based on that user's identity, not yours. So jennifer can log in to joe's machine and perform tasks there. However, if she uses a Kerberized program such as ftp or rlogin, she does so as herself.
Kerberos keeps a log of who obtains tickets, so a system administrator can find out, if necessary, who is capable of using your user identity at a particular time.
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.
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 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.
The Kerberized network services are programs that connect to another machine somewhere on the Internet. These programs are the following:
ftp
rcp
rdist
rlogin
rsh
ssh
telnet
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:
Forward your tickets to the another host (if you initially obtained forwardable tickets).
Encrypt data transmitted between you and the remote host.
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:
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.
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.
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.
Requests tickets for the remote host in the specified realm, instead of determining the realm itself using the krb5.conf file.
Uses your tickets to authenticate to the remote host, but does not automatically log in.
Specifies the GSS-API security mechanism to use, as listed in the /etc/gss/mech file. Defaults to kerberos_v5.
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 |
|
|
|
|
X |
-f |
X |
|
X |
X |
X |
-F |
|
|
X |
X |
X |
-k |
|
X |
X |
X |
X |
-K |
|
|
|
|
X |
-m |
X |
|
|
|
|
-x |
X |
X |
X |
X |
X |
-X |
|
|
|
|
X |
Additionally, ftp allows the protection level for a session to be set at its prompt:
Sets the protection level to “clear” (no protection). This protection level is the default.
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.
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).
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.
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.
The following examples show how the options to the Kerberized commands work.
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.
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 % |
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.
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.
This section lists some commands that are included in the Kerberos product.
Table 27–2 Kerberos Commands
The following table lists the daemons that the Kerberos product uses.
Table 27–3 Kerberos Daemons
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.
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.
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:
Principal name of the service
Principal name of the user
IP address of the user's host
Timestamp
Value which defines the lifetime of the ticket
Copy of the session key
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.
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:
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.
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.
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.
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.
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.
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.
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:
The lifetime value that is specified by the -l option of kinit, if kinit is used to get the ticket. By default, kinit used the maximum lifetime value.
The maximum lifetime value (max_life) that is specified in the kdc.conf file.
The maximum lifetime value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm.
The maximum lifetime value that is specified in the Kerberos database for the user principal that requests the ticket.
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).
The renewable ticket lifetime is also determined from the minimum of four values, but renewable lifetime values are used instead, as follows:
The renewable lifetime value that is specified by the -r option of kinit, if kinit is used to obtain or renew the ticket.
The maximum renewable lifetime value (max_renewable_life) that is specified in the kdc.conf file.
The maximum lifetime renewable value that is specified in the Kerberos database for the service principal that provides the ticket. In the case of kinit, the service principal is krbtgt/realm.
The maximum lifetime renewable value that is specified in the Kerberos database for the user principal that requests the ticket.
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. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The KDC assumes that the first key/enctype associated with the server principal entry in the principal database is supported by the server.
On the KDC, you should make sure that the keys generated for the principal are compatible with the systems on which the principal will be authenticated. By default, the kadmin command creates keys for all supported encryption types. If the systems that the principal is used on do not support this default set of encryption types, then you should restrict the encryption types when creating a principal. You can restrict the encryption types through use of the -e flag in kadmin addprinc or by setting the supported_enctypes parameter in the kdc.conf file to this subset. The supported_enctypes parameter should be used when most of the systems in a Kerberos realm support a subset of the default set of encryption types. Setting supported_enctypes specifies the default set of encryption types kadmin addprinc uses when it creates a principal for a particular realm. As a general rule, it is best to control the encryption types used by Kerberos using one of these two methods.
When determining the encryption types a system supports, consider both the version of Kerberos running on the system as well as the cryptographic algorithms supported by the server application for which a server principal is being created. For example, when creating an nfs/hostname service principal, you should restrict the encryption types to the types supported by the NFS server on that host. Note that in the Solaris 10 release, all supported Kerberos encryption types are also supported by the NFS server.
The master_key_enctype parameter in the kdc.conf file can be used to control the encryption type of the master key that encrypts the entries in the principal database. Do not use this parameter if the KDC principal database has already been created. The master_key_enctype parameter can be used at database creation time to change the default master key encryption type from des-cbc-crc to a stronger encryption type. Make sure that all slave KDCs support the chosen encryption type and that they have an identical master_key_enctype entry in their kdc.conf when configuring the slave KDCs. Also, make sure that the master_key_enctype is set to one of the encryption types in supported_enctypes, if supported_enctypes is set in kdc.conf. If either of these issues are not handled properly, then the master KDC might not be able to work with the slave KDCs.
On the client, you can control which encryption types the client requests when getting tickets from the KDC through a couple of parameters in krb5.conf. The default_tkt_enctypes parameter specifies the encryption types the client is willing to use when the client requests a ticket-granting ticket (TGT) from the KDC. The TGT is used by the client to acquire other server tickets in a more efficient manner. The effect of setting default_tkt_enctypes is to give the client some control over the encryption types used to protect the communication between the client and KDC when the client requests a server ticket using the TGT (this is called a TGS request). Note, that the encryption types specified in default_tkt_enctypes must match at least one of the principal key encryption types in the principal database stored on the KDC. Otherwise, the TGT request will fail. In most situations, it is best not to set default_tkt_enctypes because this parameter can be a source of interoperability problems. By default, the client code requests that all supported encryption types and the KDC choose the encryption types based on the keys the KDC finds in the principal database.
The default_tgs_enctypes parameter restricts the encryption types the client requests in its TGS requests, which are used to acquire server tickets. This parameter also restricts the encryption types the KDC uses when creating the session key that the client and server share. For example, if a client wants to only use 3DES encryption when doing secure NFS, you should set default_tgs_enctypes = des3-cbc-sha1. Make sure that the client and server principals have a des-3-cbc-sha1 key in the principal database. As with default_tkt_enctype, it is probably best in most cases not to set this because it can cause interoperability problems if the credentials are not setup properly both on the KDC and the server.
On the server, you can control the encryption types accepted by the server with the permitted_enctypes in kdc.conf. In addition, you can specify the encryption types used when creating keytab entries. Again, it is generally best not to use either of these methods to control encryption types and instead let the KDC determine the encryption types to use because the KDC does not communicate with the server application to determine which key or encryption type to use.
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.
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:
Kerberos support of Solaris remote applications
Incremental propagation for the KDC database
Client configuration script
Localized error messages
BSM audit record support
Thread safe use of Kerberos using GSS-API
Use of the Encryption Framework for cryptography
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.