| Managing Single Sign-On and Smart CardsChapter 3. Using KerberosMaintaining system security and integrity within a network is critical, and it encompasses every user, application, service, and server within the network infrastructure. It requires an understanding of everything that is running on the network and the manner in which these services are used. At the core of maintaining this security is maintaining access to these applications and services and enforcing that access. Kerberos provides a mechanism that allows both users and machines to identify themselves to network and receive defined, limited access to the areas and services that the administrator configured. Kerberos authenticates entities by verifying their identity, and Kerberos also secures this authenticating data so that it cannot be accessed and used or tampered with by an outsider. Kerberos is a network authentication protocol created by MIT, and uses symmetric-key cryptography [1] to authenticate users to network services, which means passwords are never actually sent over the network. Consequently, when users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted. 3.1.1. How Kerberos WorksMost conventional network services use password-based authentication schemes, where a user supplies a password to access a given network server. However, the transmission of authentication information for many services is unencrypted. For such a scheme to be secure, the network has to be inaccessible to outsiders, and all computers and users on the network must be trusted and trustworthy. With simple, password-based authentication, a network that is connected to the Internet cannot be assumed to be secure. Any attacker who gains access to the network can use a simple packet analyzer, or packet sniffer, to intercept usernames and passwords, compromising user accounts and, therefore, the integrity of the entire security infrastructure. Kerberos eliminates the transmission of unencrypted passwords across the network and removes the potential threat of an attacker sniffing the network. Rather than authenticating each user to each network service separately as with simple password authentication, Kerberos uses symmetric encryption and a trusted third party (a key distribution center or KDC) to authenticate users to a suite of network services. The computers managed by that KDC and any secondary KDCs constitute a realm. When a user authenticates to the KDC, the KDC sends a set of credentials (a ticket) specific to that session back to the user's machine, and any Kerberos-aware services look for the ticket on the user's machine rather than requiring the user to authenticate using a password. As shown in Figure 3.1, "Kerberos Authentication, in Steps", each user is identified to the KDC with a unique identity, called a principal. When a user on a Kerberos-aware network logs into his workstation, his principal is sent to the KDC as part of a request for a ticket-getting ticket (or TGT) from the authentication server. This request can be sent by the login program so that it is transparent to the user or can be sent manually by a user through the kinit program after the user logs in.The KDC then checks for the principal in its database. If the principal is found, the KDC creates a TGT, encrypts it using the user's key, and sends the TGT to that user. The login or kinit program on the client then decrypts the TGT using the user's key, which it computes from the user's password. The user's key is used only on the client machine and is not transmitted over the network. The ticket (or credentials) sent by the KDC are stored in a local file, the credentials cache, which can be checked by Kerberos-aware services. After authentication, servers can check an unencrypted list of recognized principals and their keys rather than checking kinit; this is kept in a keytab. The TGT is set to expire after a certain period of time (usually ten to twenty-four hours) and is stored in the client machine's credentials cache. An expiration time is set so that a compromised TGT is of use to an attacker for only a short period of time. After the TGT has been issued, the user does not have to re-enter their password until the TGT expires or until they log out and log in again. Whenever the user needs access to a network service, the client software uses the TGT to request a new ticket for that specific service from the ticket-granting server (TGS). The service ticket is then used to authenticate the user to that service transparently. The Kerberos system can be compromised if a user on the network authenticates against a non-Kerberos aware service by transmitting a password in plain text. The use of non-Kerberos aware services (including telnet and FTP) is highly discouraged. Other encrypted protocols, such as SSH or SSL-secured services, is preferred to unencrypted services, bit this is still not ideal. Kerberos relies on being able to resolve machine names and on accurate timestamps to issue and expire tickets. Thus, Kerberos requires both adequate clock synchronization and a working domain name service (DNS) to function correctly. Approximate clock synchronization between the machines on the network can be set up using a service such as ntpd, which is documented in /usr/share/doc/ntp-version-number/html/index.html. Both DNS entries and hosts on the network must be properly configured, which is covered in the Kerberos documentation in /usr/share/doc/krb5-server-version-number.
3.1.2. Considerations for Deploying KerberosAlthough Kerberos removes a common and severe security threat, it is difficult to implement for a variety of reasons: Migrating user passwords from a standard UNIX password database, such as /etc/passwd or /etc/shadow, to a Kerberos password database can be tedious. There is no automated mechanism to perform this task. This is covered in question 2.23 in the online Kerberos FAQ for the US Navy. Kerberos assumes that each user is trusted but is using an untrusted host on an untrusted network. Its primary goal is to prevent unencrypted passwords from being transmitted across that network. However, if anyone other than the proper user has access to the one host that issues tickets used for authentication - the KDC - the entire Kerberos authentication system are at risk. For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. Applications modified in this way are considered to be Kerberos-aware, or kerberized. For some applications, this can be quite problematic due to the size of the application or its design. For other incompatible applications, changes must be made to the way in which the server and client communicate. Again, this can require extensive programming. Closed-source applications that do not have Kerberos support by default are often the most problematic. Kerberos is an all-or-nothing solution. If Kerberos is used on the network, any unencrypted passwords transferred to a non-Kerberos aware service are at risk. Thus, the network gains no benefit from the use of Kerberos. To secure a network with Kerberos, one must either use Kerberos-aware versions of all client/server applications that transmit passwords unencrypted, or not use that client/server application at all.
3.1.3. Additional Resources for KerberosKerberos can be a complex service to implement, with a lot of flexibility in how it is deployed. Table 3.1, "External Kerberos Documentation" and Table 3.2, "Important Kerberos Manpages" list of a few of the most important or most useful sources for more information on using Kerberos.Table 3.1. External Kerberos Documentation| Documentation | Location |
|---|
| Kerberos V5 Installation Guide (in both PostScript and HTML) | /usr/share/doc/krb5-server-version-number | | Kerberos V5 System Administrator's Guide (in both PostScript and HTML) | /usr/share/doc/krb5-server-version-number | | Kerberos V5 UNIX User's Guide (in both PostScript and HTML) | /usr/share/doc/krb5-workstation-version-number | | "Kerberos: The Network Authentication Protocol" webpage from MIT | http://web.mit.edu/kerberos/www/ | | The Kerberos Frequently Asked Questions (FAQ) | http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html | | Kerberos: An Authentication Service for Open Network Systems by Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Schille, the original paper describing Kerberos. In PostScript format. | ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS | | Designing an Authentication System: a Dialogue in Four Scenes, originally by Bill Bryant in 1988, modified by Theodore Ts'o in 1997. This document is a conversation between two developers who are thinking through the creation of a Kerberos-style authentication system. The conversational style of the discussion makes this a good starting place for people who are completely unfamiliar with Kerberos. | http://web.mit.edu/kerberos/www/dialogue.html | | A how-to article for kerberizing a network. | http://www.ornl.gov/~jar/HowToKerb.html | | Kerberos Network Design Manual is a thorough overview of the Kerberos system. | http://www.networkcomputing.com/netdesign/kerb1.html |
Any of the manpage files can be opened by running man command_name. Table 3.2. Important Kerberos Manpages| Manpage | Description |
|---|
| Client Applications | | kerberos | An introduction to the Kerberos system which describes how credentials work and provides recommendations for obtaining and destroying Kerberos tickets. The bottom of the man page references a number of related man pages. | | kinit | Describes how to use this command to obtain and cache a ticket-granting ticket. | | kdestroy | Describes how to use this command to destroy Kerberos credentials. | | klist | Describes how to use this command to list cached Kerberos credentials. | | Administrative Applications | | kadmin | Describes how to use this command to administer the Kerberos V5 database. | | kdb5_util | Describes how to use this command to create and perform low-level administrative functions on the Kerberos V5 database. | | Server Applications | | krb5kdc | Describes available command line options for the Kerberos V5 KDC. | | kadmind | Describes available command line options for the Kerberos V5 administration server. | | Configuration Files | | krb5.conf | Describes the format and options available within the configuration file for the Kerberos V5 library. | | kdc.conf | Describes the format and options available within the configuration file for the Kerberos V5 AS and KDC. |
Kerberos packages may be installed by default, but make sure that the appropriate packages are installed for the Kerberos server or client being configured. To install packages for a Kerberos server: # yum install krb5-server krb5-libs krb5-auth-dialog To install packages for a Kerberos client: # yum install krb5-workstation krb5-libs krb5-auth-dialog If the Red Hat Enterprise Linux system will use Kerberos as part of single sign-on with smart cards, then also install the required PKI/OpenSSL package: # yum install krb5-pkinit-openssl 3.3. Configuring a Kerberos 5 ServerWhen setting up Kerberos, install the master KDC first and then install any necessary secondary servers after the master is set up. 3.3.1. Configuring the Master KDC ServerEnsure that time synchronization and DNS are functioning correctly on all client and server machines before configuring Kerberos. Pay particular attention to time synchronization between the Kerberos server and its clients. If the time difference between the server and client is greater than the configured limit (five minutes by default), Kerberos clients cannot authenticate to the server. This time synchronization is necessary to prevent an attacker from using an old Kerberos ticket to masquerade as a valid user. The NTP documentation is located at /usr/share/doc/ntp-version-number/html/index.html and online at http://www.ntp.org. Install the krb5-libs, krb5-server, and krb5-workstation packages on the dedicated machine which runs the KDC. This machine needs to be very secure - if possible, it should not run any services other than the KDC. Edit the /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf configuration files to reflect the realm name and domain-to-realm mappings. A simple realm can be constructed by replacing instances of EXAMPLE.COM and example.com with the correct domain name - being certain to keep uppercase and lowercase names in the correct format - and by changing the KDC from kerberos.example.com to the name of the Kerberos server. By convention, all realm names are uppercase and all DNS hostnames and domain names are lowercase. The man pages of these configuration files have full details about the file formats. Create the database using the kdb5_util utility. /usr/sbin/kdb5_util create -s The create command creates the database that stores keys for the Kerberos realm. The -s argument creates a stash file in which the master server key is stored. If no stash file is present from which to read the key, the Kerberos server ( krb5kdc) prompts the user for the master server password (which can be used to regenerate the key) every time it starts. Edit the /var/kerberos/krb5kdc/kadm5.acl file. This file is used by kadmind to determine which principals have administrative access to the Kerberos database and their level of access. Most organizations can be accommodated by a single line: */[email protected] * Most users are represented in the database by a single principal (with a NULL, or empty, instance, such as [email protected]). In this configuration, users with a second principal with an instance of admin (for example, joe/[email protected]) are able to exert full administrative control over the realm's Kerberos database. After kadmind has been started on the server, any user can access its services by running kadmin on any of the clients or servers in the realm. However, only users listed in the kadm5.acl file can modify the database in any way, except for changing their own passwords. The kadmin utility communicates with the kadmind server over the network, and uses Kerberos to handle authentication. Consequently, the first principal must already exist before connecting to the server over the network to administer it. Create the first principal with the kadmin.local command, which is specifically designed to be used on the same host as the KDC and does not use Kerberos for authentication. Create the first principal using kadmin.local at the KDC terminal: /usr/sbin/kadmin.local -q "addprinc username/admin" Start Kerberos using the following commands: /sbin/service krb5kdc start/sbin/service kadmin start Add principals for the users using the addprinc command within kadmin. kadmin and kadmin.local are command line interfaces to the KDC. As such, many commands - such as addprinc - are available after launching the kadmin program. Refer to the kadmin man page for more information. Verify that the KDC is issuing tickets. First, run kinit to obtain a ticket and store it in a credential cache file. Next, use klist to view the list of credentials in the cache and use kdestroy to destroy the cache and the credentials it contains. By default, kinit attempts to authenticate using the same system login username (not the Kerberos server). If that username does not correspond to a principal in the Kerberos database, kinit issues an error message. If that happens, supply kinit with the name of the correct principal as an argument on the command line: kinit principal
3.3.2. Setting up Secondary KDCsWhen there are multiple KDCs for a given realm, one KDC (the master KDC) keeps a writable copy of the realm database and runs kadmind. The master KDC is also the realm's admin server. Additional secondary KDCs keep read-only copies of the database and run kpropd. The master-slave propagation procedure entails the master KDC dumping its database to a temporary dump file and then transmitting that file to each of its slaves, which then overwrite their previously-received read-only copies of the database with the contents of the dump file. To set up a secondary KDC: Copy the master KDC's krb5.conf and kdc.conf files to the secondary KDC. Start kadmin.local from a root shell on the master KDC. Use the kadmin.local add_principal command to create a new entry for the master KDC's host service. Use the kadmin.local ktadd command to set a random key for the service and store the random key in the master's default keytab file. This key is used by the kprop command to authenticate to the secondary servers. You will only need to do this once, regardless of how many secondary KDC servers you install. Authenticating as principal root/[email protected] with password. kadmin: add_principal -randkey host/masterkdc.example.comPrincipal "host/host/[email protected]" created. kadmin: ktadd host/masterkdc.example.comEntry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.kadmin: quit
Start kadmin from a root shell on the secondary KDC. Use the kadmin.local add_principal command to create a new entry for the secondary KDC's host service. Use the kadmin.local ktadd command to set a random key for the service and store the random key in the secondary KDC server's default keytab file. This key is used by the kpropd service when authenticating clients. Authenticating as principal jsmith/[email protected] with password. Password for jsmith/[email protected]: kadmin: add_principal -randkey host/slavekdc.example.comPrincipal "host/[email protected]" created. kadmin: ktadd host/[email protected] Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
With its service key, the secondary KDC could authenticate any client which would connect to it. Obviously, not all potential clients should be allowed to provide the kprop service with a new realm database. To restrict access, the kprop service on the secondary KDC will only accept updates from clients whose principal names are listed in /var/kerberos/krb5kdc/kpropd.acl. Add the master KDC's host service's name to that file. # echo host/[email protected] > /var/kerberos/krb5kdc/kpropd.acl Once the secondary KDC has obtained a copy of the database, it will also need the master key which was used to encrypt it. If the KDC database's master key is stored in a stash file on the master KDC (typically named /var/kerberos/krb5kdc/.k5.REALM), either copy it to the secondary KDC using any available secure method, or create a dummy database and identical stash file on the secondary KDC by running kdb5_util create -s and supplying the same password. The dummy database will be overwritten by the first successful database propagation. Ensure that the secondary KDC's firewall allows the master KDC to contact it using TCP on port 754 ( krb5_prop), and start the kprop service. Double-check that the kadmin service is disabled. Perform a manual database propagation test by dumping the realm database on the master KDC to the default data file which the kprop command will read ( /var/kerberos/krb5kdc/slave_datatrans). Use the kprop command to transmit its contents to the secondary KDC. Using kinit, verify that the client system is able to correctly obtain the initial credentials from the KDC. The /etc/krb5.conf for the client should list only the secondary KDC in its list of KDCs. Create a script which dumps the realm database and runs the kprop command to transmit the database to each secondary KDC in turn, and configure the cron service to run the script periodically.
3.4. Configuring a Kerberos 5 ClientAll that is required to set up a Kerberos 5 client is to install the client packages and provide each client with a valid krb5.conf configuration file. While ssh and slogin are the preferred methods of remotely logging in to client systems, Kerberized versions of rsh and rlogin are still available, with additional configuration changes. Be sure that time synchronization is in place between the Kerberos client and the KDC and that DNS is working properly on the Kerberos client. Install the krb5-libs and krb5-workstation packages on all of the client machines. Supply a valid /etc/krb5.conf file for each client (usually this can be the same krb5.conf file used by the KDC). To use kerberized rsh and rlogin services, install the rsh package. Before a workstation can use Kerberos to authenticate users who connect using ssh, rsh, or rlogin, it must have its own host principal in the Kerberos database. The sshd, kshd, and klogind server programs all need access to the keys for the host service's principal. Using kadmin, add a host principal for the workstation on the KDC. The instance in this case is the hostname of the workstation. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key: addprinc -randkey host/server.example.com The keys can be extracted for the workstation by running kadmin on the workstation itself and using the ktadd command. ktadd -k /etc/krb5.keytab host/server.example.com
To use other kerberized network services, install the krb5-server package and start the services. The kerberized services are listed in Table 3.3, "Common Kerberized Services".
Table 3.3. Common Kerberized Services| Service Name | Usage Information |
|---|
| ssh | OpenSSH uses GSS-API to authenticate users to servers if the client's and server's configuration both have GSSAPIAuthentication enabled. If the client also has GSSAPIDelegateCredentials enabled, the user's credentials are made available on the remote system. | | rsh and rlogin | Enable klogin, eklogin, and kshell. | | Telnet | Enable krb5-telnet. | | FTP | Create and extract a key for the principal with a root of ftp. Be certain to set the instance to the fully qualified hostname of the FTP server, then enable gssftp. | | IMAP | The cyrus-imap package uses Kerberos 5 if it also has the cyrus-sasl-gssapi package installed. The cyrus-sasl-gssapi package contains the Cyrus SASL plugins which support GSS-API authentication. Cyrus IMAP functions properly with Kerberos as long as the cyrus user is able to find the proper key in /etc/krb5.keytab, and the root for the principal is set to imap (created with kadmin). An alternative to cyrus-imap can be found in the dovecot package, which is also included in Red Hat Enterprise Linux. This package contains an IMAP server but does not, to date, support GSS-API and Kerberos. | | CVS | gserver uses a principal with a root of cvs and is otherwise identical to the CVS pserver. |
3.5. Domain-to-Realm MappingWhen a client attempts to access a service running on a particular server, it knows the name of the service ( host) and the name of the server ( foo.example.com), but because more than one realm can be deployed on your network, it must guess at the name of the realm in which the service resides. By default, the name of the realm is taken to be the DNS domain name of the server in all capital letters. foo.example.org ⤍ EXAMPLE.ORGfoo.example.com ⤍ EXAMPLE.COMfoo.hq.example.com ⤍ HQ.EXAMPLE.COM In some configurations, this will be sufficient, but in others, the realm name which is derived will be the name of a non-existent realm. In these cases, the mapping from the server's DNS domain name to the name of its realm must be specified in the domain_realm section of the client system's krb5.conf. For example: [domain_realm].example.com = EXAMPLE.COMexample.com = EXAMPLE.COM The configuration specifies two mappings. The first mapping specifies that any system in the example.com DNS domain belongs to the EXAMPLE.COM realm. The second specifies that a system with the exact name example.com is also in the realm. The distinction between a domain and a specific host is marked by the presence or lack of an initial period character. The mapping can also be stored directly in DNS. 3.6. Setting up Cross Realm AuthenticationAllowing clients (typically users) of one realm to use Kerberos to authenticate to services (typically server processes running on a particular server system) which belong to another realm requires cross-realm authentication. 3.6.1. Setting up Basic Trust RelationshipsFor the simplest case, for a client of realm A.EXAMPLE.COM to access a service in the B.EXAMPLE.COM realm, both realms must share a key for a principal named krbtgt/[email protected], and both keys must have the same key version number associated with them. To accomplish this, select a very strong password or passphrase, and create an entry for the principal in both realms using kadmin. kadmin: add_principal krbtgt/[email protected] password for principal "krbtgt/[email protected]":Re-enter password for principal "krbtgt/[email protected]":Principal "krbtgt/[email protected]" created.quitkadmin: add_principal krbtgt/[email protected] password for principal "krbtgt/[email protected]":Re-enter password for principal "krbtgt/[email protected]":Principal "krbtgt/[email protected]" created.quit Use the get_principal command to verify that both entries have matching key version numbers ( kvno values) and encryption types. A common, but incorrect, situation is for administrators to try to use the add_principal command's -randkey option to assign a random key instead of a password, dump the new entry from the database of the first realm, and import it into the second. This will not work unless the master keys for the realm databases are identical, as the keys contained in a database dump are themselves encrypted using the master key. Clients in the A.EXAMPLE.COM realm are now able to authenticate to services in the B.EXAMPLE.COM realm. Put another way, the B.EXAMPLE.COM realm now trusts the A.EXAMPLE.COM realm. This brings us to an important point: cross-realm trust is unidirectional by default. The KDC for the B.EXAMPLE.COM realm can trust clients from the A.EXAMPLE.COM to authenticate to services in the B.EXAMPLE.COM realm. However, this trust is not automatically reciprocated so that the B.EXAMPLE.COM realm are trusted to authenticate to services in the A.EXAMPLE.COM realm. To establish trust in the other direction, both realms would need to share keys for the krbtgt/[email protected] service - an entry with a reverse mapping from the previous example. 3.6.2. Setting up Complex Trust RelationshipsIf direct trust relationships were the only method for providing trust between realms, networks which contain multiple realms would be very difficult to set up. Luckily, cross-realm trust is transitive. If clients from A.EXAMPLE.COM can authenticate to services in B.EXAMPLE.COM, and clients from B.EXAMPLE.COM can authenticate to services in C.EXAMPLE.COM, then clients in A.EXAMPLE.COM can also authenticate to services in C.EXAMPLE.COM, even if C.EXAMPLE.COM does not directly trust A.EXAMPLE.COM. This means that, on a network with multiple realms which all need to trust each other, making good choices about which trust relationships to set up can greatly reduce the amount of effort required. The client's system must be configured so that it can properly deduce the realm to which a particular service belongs, and it must be able to determine how to obtain credentials for services in that realm. Taking first things first, the principal name for a service provided from a specific server system in a given realm typically looks like this: service/[email protected] service is typically either the name of the protocol in use (other common values include LDAP, IMAP, CVS, and HTTP) or host. server.example.com is the fully-qualified domain name of the system which runs the service. EXAMPLE.COM is the name of the realm. To deduce the realm to which the service belongs, clients will most often consult DNS or the domain_realm section of /etc/krb5.conf to map either a hostname ( server.example.com) or a DNS domain name ( .example.com) to the name of a realm ( EXAMPLE.COM). After determining the realm to which a service belongs, a client then has to determine the set of realms which it needs to contact, and in which order it must contact them, to obtain credentials for use in authenticating to the service. This can be done in one of two ways. The simplest is to use a shared hierarchy to name realms. The second uses explicit configuration in the krb5.conf file. 3.6.2.1. Configuring a Shared Hierarchy of NamesThe default method, which requires no explicit configuration, is to give the realms names within a shared hierarchy. For an example, assume realms named A.EXAMPLE.COM, B.EXAMPLE.COM, and EXAMPLE.COM. When a client in the A.EXAMPLE.COM realm attempts to authenticate to a service in B.EXAMPLE.COM, it will, by default, first attempt to get credentials for the EXAMPLE.COM realm, and then to use those credentials to obtain credentials for use in the B.EXAMPLE.COM realm. The client in this scenario treats the realm name as one might treat a DNS name. It repeatedly strips off the components of its own realm's name to generate the names of realms which are "above" it in the hierarchy until it reaches a point which is also "above" the service's realm. At that point it begins prepending components of the service's realm name until it reaches the service's realm. Each realm which is involved in the process is another "hop". For example, using credentials in A.EXAMPLE.COM, authenticating to a service in B.EXAMPLE.COM has three hops: A.EXAMPLE.COM ⤍ EXAMPLE.COM ⤍ B.EXAMPLE.COM . Another example, using credentials in SITE1.SALES.EXAMPLE.COM, authenticating to a service in EVERYWHERE.EXAMPLE.COM can have several series of hops: SITE1.SALES.EXAMPLE.COM ⤍ SALES.EXAMPLE.COM ⤍ EXAMPLE.COM ⤍ EVERYWHERE.EXAMPLE.COM SITE1.SALES.EXAMPLE.COM and SALES.EXAMPLE.COM share a key for krbtgt/[email protected]
There can even be hops between realm names whose names share no common suffix, such as DEVEL.EXAMPLE.COM and PROD.EXAMPLE.ORG. DEVEL.EXAMPLE.COM ⤍ EXAMPLE.COM ⤍ COM ⤍ ORG ⤍ EXAMPLE.ORG ⤍ PROD.EXAMPLE.ORG COM and ORG share a key for krbtgt/ORG@COMORG and EXAMPLE.ORG share a key for krbtgt/EXAMPLE.ORG@ORG 3.6.2.2. Configuring Paths in krb5.confThe more complicated, but also more flexible, method involves configuring the capaths section of /etc/krb5.conf, so that clients which have credentials for one realm will be able to look up which realm is next in the chain which will eventually lead to the being able to authenticate to servers. The format of the capaths section is relatively straightforward: each entry in the section is named after a realm in which a client might exist. Inside of that subsection, the set of intermediate realms from which the client must obtain credentials is listed as values of the key which corresponds to the realm in which a service might reside. If there are no intermediate realms, the value "." is used. [capaths]A.EXAMPLE.COM = {B.EXAMPLE.COM = .C.EXAMPLE.COM = B.EXAMPLE.COMD.EXAMPLE.COM = B.EXAMPLE.COMD.EXAMPLE.COM = C.EXAMPLE.COM}Clients in the A.EXAMPLE.COM realm can obtain cross-realm credentials for B.EXAMPLE.COM directly from the A.EXAMPLE.COM KDC. If those clients wish to contact a service in the C.EXAMPLE.COM realm, they will first need to obtain necessary credentials from the B.EXAMPLE.COM realm (this requires that krbtgt/[email protected] exist), and then use those credentials to obtain credentials for use in the C.EXAMPLE.COM realm (using krbtgt/[email protected]). If those clients wish to contact a service in the D.EXAMPLE.COM realm, they will first need to obtain necessary credentials from the B.EXAMPLE.COM realm, and then credentials from the C.EXAMPLE.COM realm, before finally obtaining credentials for use with the D.EXAMPLE.COM realm. Without a capath entry indicating otherwise, Kerberos assumes that cross-realm trust relationships form a hierarchy. Clients in the A.EXAMPLE.COM realm can obtain cross-realm credentials from B.EXAMPLE.COM realm directly. Without the "." indicating this, the client would instead attempt to use a hierarchical path, in this case: A.EXAMPLE.COM ⤍ EXAMPLE.COM ⤍ B.EXAMPLE.COM |
| |
