Kerberosplanning for Kerberosconfiguration decisions planningKerberosconfiguration decisions This chapter should be studied by administrators who are involved in the installation and maintenance of the Kerberos service. The chapter discusses several installation and configuration options that administrators must resolve before they install or configure the service. This is a list of the topics that a system administrator or other knowledgeable support staff should study:Why Plan for Kerberos Deployments? Planning Kerberos Realms Mapping Host Names Onto Realms Client and Service Principal Names Ports for the KDC and Admin Services The Number of Slave KDCs Which Database Propagation System to Use Clock Synchronization Within a Realm Client Configuration Options KDC Configuration Options Kerberos Encryption Types Online Help URL in the Graphical Kerberos Administration Tool 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. realms (Kerberos)configuration decisions configuration decisionsKerberosrealms planningKerberosrealms 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.realms (Kerberos)names configuration decisionsKerberosrealm names planningKerberosrealm names Realm names can consist of any ASCII string. Usually, the realm name is the same as your DNS domain name, except that the realm name is in uppercase. This convention helps differentiate problems with the Kerberos service from problems with the DNS namespace, while using a name that is familiar. If you do not use DNS or you choose to use a different string, then you can use any string. However, the configuration process requires more work. The use of realm names that follow the standard Internet naming structure is wise. realms (Kerberos)number of configuration decisionsKerberosnumber of realms planningKerberosnumber of realms 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. realms (Kerberos)hierarchy configuration decisionsKerberosrealm hierarchy planningKerberosrealm hierarchy hierarchical realmsin Kerberos 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. configuration decisionsKerberosmapping host names onto realms realms (Kerberos)mapping host names onto mappinghost names onto realms (Kerberos) host namesmapping onto realms krb5.conf filedomain_realm section domain_realm sectionkrb5.conf file 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.conf4 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. configuration decisionsKerberosclient and service principal names planningKerberosclient and service principal names service principalplanning for names client namesplanning for in Kerberos DNSKerberos and FQDN (Fully Qualified Domain Name)in Kerberos 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.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. portsfor Kerberos KDC planningKerberosports configuration decisionsKerberosports krb5.conf fileports definition KDCports 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. KDCslave KDCplanning slave KDCsplanning for planningKerberosslave KDCs configuration decisionsKerberosslave KDCs backupslave KDCs Slave KDCs generate credentials for clients just as the master KDC does. Slave KDCs provide backup if the master becomes unavailable. Each realm should have at least one slave KDC. Additional slave KDCs might be required, depending on these factors: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. mapping GSS credentials credentialsmapping 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:How to Create a Credential Table How to Add a Single Entry to the Credential Table How to Provide Credential Mapping Between Realms Observing Mapping from GSS Credentials to UNIX Credentials 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. planningKerberosdatabase propagation configuration decisionsKerberosdatabase propagation databasesKDC propagation KDCdatabase propagation propagationKDC database 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. planningKerberosclock synchronization configuration decisionsKerberosclock synchronization clock synchronizingKerberos planning and clock skewKerberos planning and NTPKerberos planning and 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. configuration decisionsKerberosclients 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.conf4man 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. configuration decisionsKerberosKDC server Starting in the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, 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 10 5/08 and Solaris Express Developer Edition 1/08 releases, 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. configuration decisionsKerberosencryption types Kerberosencryption typesoverview encryption typesKerberos and encryption modesKerberos and encryption algorithmsKerberos and hashalgorithmsKerberos and 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. helpURL for online online helpURL for URL for online helpGraphical Kerberos Tool Kerberosonline help 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 .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.