Este conteúdo não está disponível no idioma selecionado.
Chapter 20. Policy: Managing the Kerberos Domain
Kerberos authentication is the core of authentication within the IdM domain. The IdM server actually runs a Kerberos server within it, and this Kerberos server can be configured for custom policies for managing tickets and keytabs.
For more information on Kerberos concepts, see the MIT Kerberos documentation, http://web.mit.edu/kerberos/www/.
Important
Identity Management has its own command-line tools to use to manage Kerberos policies. Do not use
kadmin or kadmin.local to manage IdM Kerberos settings.
20.1. About Kerberos
Kerberos provides an authentication layer between services and users. Kerberos centralizes authentication into a single location; a user authenticates to the Kerberos server, and then when that user attempts to access any resource on the network, that resource can check the key distribution center (KDC) for the stored user credentials. This allows users to access multiple resources without having to supply credentials separately to each and every one.
All of the users and services, combined, and all of the KDCs and Kerberos servers that are aware of each other constitute a realm. Each user, machine, and service within the realm is identified by a unique name called the principal. The user or service uses the principal and a verifying credential (usually a password) to authenticate to the KDC. The credential that is shared with the KDC is a key and it is stored in a file called a key table or keytab.
When the KDC verifies the user's identity, it issues a ticket. The ticket is a long-term pass to any service and machine on the realm. The KDC issues the user a special kind of ticket called a ticket-granting ticket (TGT). Whenever the user tries to access a resource within the Kerberos realm, the resource sends a request for a ticket specifically for it. The TGT is used to issue a resource-specific ticket that the resource then uses to authenticate the user and grant access.
Note
When an IdM client is first configured, the host principal is automatically retrieved by the setup script and stored in the
/etc/krb5.keytab file. This host principal is stored within the host record so that local service commands cannot be used with this principal. This prepares the client to function in the IdM realm.
20.1.1. About Principal Names
The principal identifies not only the user or service, but also the realm that that 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 username. For a service, the identifier is a combination of the service name and the hostname 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 hostname 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 hostname,
web-01.example.com@EXAMPLE.COM, so the host principal must be host/web-01.example.com@EXAMPLE.COM.
20.1.2. About Protecting Keytabs
To protect keytab files, reset the permissions and ownership to restrict access to the files to only the keytab owner. For example, set the owner of the Apache keytab (
/etc/httpd/conf/ipa.keytab) to apache and the mode to 0600.
