Este contenido no está disponible en el idioma seleccionado.
Chapter 11. Using Kerberos
Maintaining 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 is an authentication protocol significantly safer than normal password-based authentication. With Kerberos, passwords are never sent over the network, even when services are accessed on other machines.
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.
11.1. About Kerberos
Kerberos uses symmetric-key cryptography[3] 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.
11.1.1. The Basics of How Kerberos Works
Most 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 user names 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 11.1, “Kerberos Authentication”, 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-granting 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.
Figure 11.1. Kerberos Authentication
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 store, the credential cache (ccache), which can be checked by Kerberos-aware services. Red Hat Enterprise Linux 7 supports the following types of credential caches:
- The persistent KEYRING ccache type, the default cache in Red Hat Enterprise Linux 7
- The System Security Services Daemon (SSSD) Kerberos Credential Manager (KCM), an alternative option since Red Hat Enterprise Linux 7.4
- FILE
- DIR
- MEMORY
With SSSD KCM, the Kerberos caches are not stored in a passive store, but managed by a daemon. In this setup, the Kerberos library, which is typically used by applications such as
kinit, is a KCM client and the daemon is referred to as a KCM server.
Having the Kerberos credential caches managed by the SSSD KCM daemon has several advantages:
- The daemon is stateful and can perform tasks such as Kerberos credential cache renewals or reaping old ccaches. Renewals and tracking are possible not only for tickets that SSSD itself acquired, typically via a login through
pam_sss.so, but also for tickets acquired, for example, thoughkinit. - Since the process runs in user space, it is subject to UID namespacing, unlike the Kernel KEYRING.
- Unlike the Kernel KEYRING-based cache, which is entirely dependent on the UID of the caller and which, in a containerized environment, is shared among all containers, the KCM server’s entry point is a UNIX socket that can be bind-mounted only to selected containers.
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 10 to 24 hours) and is stored in the client machine's credential 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 enter their password again 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.
11.1.2. About Kerberos Principal Names
The principal identifies not only the user or service, but also the realm that the entity belongs to. A principal name has two parts, the identifier and the realm:
identifier@REALM
For a user, the identifier is only the Kerberos user name. For a service, the identifier is a combination of the service name and the host name of the machine it runs on:
service/FQDN@REALM
The service name is a case-sensitive string that is specific to the service type, like
host, ldap, http, and DNS. Not all services have obvious principal identifiers; the sshd daemon, for example, uses the host service principal.
The host principal is usually stored in
/etc/krb5.keytab.
When Kerberos requests a ticket, it always resolves the domain name aliases (DNS CNAME records) to the corresponding DNS address (A or AAAA records). The host name from the address record is then used when service or host principals are created.
For example:
www.example.com CNAME web-01.example.com web-01.example.com A 192.0.2.145
A service attempts to connect to the host using its CNAME alias:
$ ssh www.example.com
The Kerberos server requests a ticket for the resolved host name,
web-01.example.com@EXAMPLE.COM, so the host principal must be host/web-01.example.com@EXAMPLE.COM.
11.1.3. About the Domain-to-Realm Mapping
When 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 the network, it must guess at the name of the Kerberos 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.orgEXAMPLE.ORG foo.example.com EXAMPLE.COM foo.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 /etc/krb5.conf file. For example:
[domain_realm] .example.com = EXAMPLE.COM example.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 using the "_kerberos TXT" records, for example:
$ORIGIN example.com _kerberos TXT "EXAMPLE.COM"
11.1.4. Environmental Requirements
Kerberos relies on being able to resolve machine names. Thus, it requires a working domain name service (DNS). 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.
Applications that accept Kerberos authentication require time synchronization. You can set up approximate clock synchronization between the machines on the network using a service such as
ntpd. For information on the ntpd service, see the documentation in /usr/share/doc/ntp-version-number/html/index.html or the ntpd(8) man page.
Note
Kerberos clients running Red Hat Enterprise Linux 7 support automatic time adjustment with the KDC and have no strict timing requirements. This enables better tolerance to clocking differences when deploying IdM clients with Red Hat Enterprise Linux 7.
11.1.5. Considerations for Deploying Kerberos
Although Kerberos removes a common and severe security threat, it is difficult to implement for a variety of reasons:
- 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. 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.
- To secure a network with Kerberos, one must either use Kerberos-aware versions of all client and server applications that transmit passwords unencrypted, or not use that client and server application at all.
- Migrating user passwords from a standard UNIX password database, such as
/etc/passwdor/etc/shadow, to a Kerberos password database can be tedious. There is no automated mechanism to perform this task. Migration methods can vary substantially depending on the particular way Kerberos is deployed. That is why it is recommended that you use the Identity Management feature; it has specialized tools and methods for migration.
Warning
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, are preferred to unencrypted services, but this is still not ideal.
11.1.6. Additional Resources for Kerberos
Kerberos can be a complex service to implement, with a lot of flexibility in how it is deployed. Table 11.1, “External Kerberos Documentation” and Table 11.2, “Important Kerberos Man Pages” list of a few of the most important or most useful sources for more information on using Kerberos.
| 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" web page from MIT | http://web.mit.edu/kerberos/www/ |
| 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 |
| An article for making a network Kerberos-aware. | http://www.ornl.gov/~jar/HowToKerb.html |
Any of the manpage files can be opened by running
man command_name.
| 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. |
[3]
A system where both the client and the server share a common key that is used to encrypt and decrypt network communication.
