Red Hat Security: Identity Management and Authentication
Manage Kerberos principal keytab files, implement Kerberos ticket policies to set restrictions on ticket access, duration, and renewal, and configure external systems to enable IdM user access using Kerberos credentials.
All actors in the Kerberos authentication process are represented as principals. This means that hosts and services can be principals, not only users.
When a user communicates with a Kerberos-enabled service, the service should use a dedicated service principal, although some legacy configurations might reuse the host principal.
To log in to a host that is a member of an IdM domain by using SSH, sshd uses the host principal as its identifier.
The host principal identifies a specific machine, which for SSH is all that is required.
For other services, service principals use the service-type/hostname@REALMHTTP/intranet.example.com@EXAMPLE.COM principal.
Each principal has an associated key that is used to encrypt tickets. For users, the key is derived from the user's password. Host and service principals do not have configurable passwords. For these types of principals, IdM creates a random password and the key is derived from it.
Hosts and services cannot enter passwords interactively, and so the key for a host or service principal must be downloaded and stored in a keytab file instead. The keytab file is similar to a certificate private key or a password; it should be protected accordingly.
A host or service credential is stored in a keytab file, and the service reads it when it starts.
The default storage location for a host principal credential is in the /etc/krb5.keytab file.
You can store service principal keytabs in any directory; the only condition is that the service must have permission to read the keytab.
Services store their passwords on the application server in a local keytab file so that they can start without intervention.
IdM creates the host principals when a host joins the domain.
The host principal credential is downloaded and stored in the /etc/krb5.keytab file.
You can create service principals as needed.
You can create service principals through the IdM web UI by navigating to → , and then clicking . Populate the required fields, and then click again.
You can also create service principals by using the ipa service-add command.
After using either of the described methods, you can download the keytab file by using the ipa-getkeytab command:
[user@host ~]$ ipa-getkeytab \
-s server.example.com \
-p HTTP/intranet.example.com \
-k /etc/httpd/conf/intranet.keytabImportant
Downloading the keytab for a service principal resets the secret, invalidating any previously downloaded keytabs.
There might be times when it is desirable to disable access to a host or service temporarily.
When a host or service principal is disabled, the keytab attribute is set to False.
Additionally, any managed services are also disabled for this host:
[user@host ~]$ipa service-showPrincipal name: HTTP/intranet.example.com@EXAMPLE.COM Principal alias: HTTP/intranet.example.com@EXAMPLE.COM Keytab:HTTP/intranet.example.comTrueManaged by: intranet.example.com [user@host ~]$ipa service-disable-------------------------------------------------------- Disabled service "HTTP/intranet.example.com@EXAMPLE.COM" -------------------------------------------------------- [user@host ~]$HTTP/intranet.example.comipa service-showPrincipal name: HTTP/intranet.example.com@EXAMPLE.COM Principal alias: HTTP/intranet.example.com@EXAMPLE.COM Keytab:HTTP/intranet.example.comFalseManaged by: intranet.example.com
To enable the service again, you must request a new keytab:
[user@host ~]$ ipa-getkeytab \
-s server.example.com \
-p HTTP/intranet.example.com \
-k /etc/httpd/conf/intranet.keytab
Keytab successfully retrieved and stored in: /etc/httpd/conf/intranet.keytabYou can delegate the management of an IdM service to the server hosting the service. Delegating service management enables IdM administrators to distribute responsibilities to service owners. By delegating to the host principal, any user with access to the server can retrieve an updated keytab or request a certificate for the service.
The process to manage the service requires a user to authenticate using the host keytab file:
[user@host ~]$ kinit -kt /etc/krb5.keytab host/$(hostname)To delegate a host control over a service, add the host's principal to the service by using the ipa service-add-host command:
[user@host ~]$ ipa service-add-host HTTP/utility.lab.example.com \
--hosts=client.lab.example.comThe following example shows how to manage the service by using the host's principal:
[user@host ~]$kinit -kt /etc/krb5.keytab host/client.lab.example.com[user@host ~]$ipa-getkeytab -s idm.lab.example.com \ -k utility.keytab -p HTTP/utility.lab.example.com
The Kerberos protocol uses Advanced Encryption Standard (AES) symmetric encryption. Each principal has a single key, which is stored in the key distribution center (KDC) database. That key is derived from the principal's password.
This means that when the password is changed, a new key is generated. As a result, you can see the key hash change when the password changes.
Note
Password and key hashes are not exposed through the IdM API. You can only see them by using the Directory Manager user for the back-end LDAP directory. Viewing these sensitive attributes is not required for regular IdM operations, and is only discussed here to emphasize the relationship between passwords and keys.
Kerberos Ticket Policies
When a user authenticates to the IdM domain, a ticket valid for some period of time is issued. The validity time is configurable at both a global and user level. A user ticket policy overrides the global ticket policy.
You can use the ipa krbtpolicy-mod command to change global and user-specific ticket policies.
If a user ID is included, then the command affects only that user.
Otherwise, the modification is global:
[user@host ~]$ ipa krbtpolicy-mod [userid] \
--maxrenew=seconds \
--maxlife=secondsIdM provides command options to manage the Kerberos flags for service principals; the most common flags are related to delegation:
-
OK_AS_DELEGATE You can use this option when a service is trusted to have a client's ticket-granting ticket (TGT) forwarded to it, and is used when IdM has a trust relationship with Active Directory. Active Directory forwards the user's TGT to the service if this flag is set.
-
OK_TO_AUTH_AS_DELEGATE You can use this option to allow a principal to get forwardable tickets from arbitrary users. This option is used when a service is trusted to authenticate as the client.
Important
Setting this flag means that the service can run without elevated privileges, and impersonate clients to perform work on their behalf.
-
REQUIRES_PRE_AUTH This option is enabled by default. You can use this option to disable preauthentication for a specific service. Disabling preauthentication reduces load on the KDC but reduces the security of the service credential. The preauthentication feature was introduced to mitigate a weakness in the Kerberos protocol that allowed an active attacker to perform offline password cracking.
Red Hat recommends that you do not disable preauthentication.
Use the ipa service-mod command to set one of these options for a service principal:
[user@host ~]$ ipa service-mod \
HTTP/intranet.example.com@EXAMPLE.COM \
--ok-as-delegate=1Use the kadmin.local command to see the current options set for a service principal:
[root@host ~]#kadmin.localAuthenticating as principal admin/admin@EXAMPLE.COM with password. kadmin.local:getprinc HTTP/intranet.example.com@EXAMPLE.COM...output omitted... Number of keys: 0 MKey: vno 1 Attributes:REQUIRES_PRE_AUTH OK_AS_DELEGATEPolicy: [none]
Notice that the kadmin.local command must be run as the root user.
User principals differ from host and service principals, in that password changes are common. Host and service principal credentials have random passwords generated when they are created, which are not subject to password expiry. A keytab is a sensitive item that must be protected, because gaining access to a keytab allows anyone to impersonate the host or service. If a keytab is suspected of being exposed, then you can request a new key. Rekeying is the process of requesting a new key from the KDC, which in turn increments the key version number (KVNO).
The following example requests a new key by using the ipa-getkeytab command.
The -p option specifies the principal, -s specifies the server to retrieve the keytab from, and -k specifies where to store it:
[user@host ~]$ ipa-getkeytab \
-p HTTP/intranet.example.com@EXAMPLE.COM \
-s server.example.com \
-k /etc/httpd/conf/intranet.keytabUse the klist -kt command to verify the new key version number:
[user@host ~]$klist -kt /etc/httpd/conf/intranet.keytabKeytab name: FILE:/etc/httpd/conf/intranet.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 16/03/18 09:35:13 HTTP/intranet.example.com@EXAMPLE.COM320/03/18 11:43:38 HTTP/intranet.example.com@EXAMPLE.COM
Note
The previous key version is still in the keytab to allow existing sessions to expire gracefully. New sessions use the latest version of the key.
Sometimes you might need to provide access to Kerberos-enabled services from a machine that is not a domain member.
Common situations might include visiting contractors on projects, meetings with business partners, visiting external auditors, and so on.
This section describes how to configure a machine to allow users to authenticate to IdM, and how to configure the GSSAPI negotiate authentication method for a typical web browser.
To perform Kerberos authentication on a host that is not a member of an IdM domain, you must first install the krb5-workstation package.
You must also configure Kerberos on the target host.
A quick method is to copy the /etc/krb5.conf configuration file from an existing domain member, and then edit it as required.
However, if DNS is properly configured, then the DNS server can automatically obtain the information.
If the host is configured to authenticate to a different Kerberos domain, then the configuration file for the IdM domain can be given a different name in the [realms] section:
[user@host ~]$sudo dnf install krb5-workstation...output omitted... [user@host ~]$sudo scp root@client:/etc/krb5.conf /etc/krb5.confkrb5.conf 100% 925 565.2KB/s 00:00 [user@host ~]$sudo vi /etc/krb5.conf[user@host ~]$kinit localadmin
With the krb5-workstation package installed and the Kerberos client configured, the Firefox web browser can be configured to use the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) authentication method.
SPNEGO allows a client and server to negotiate a common GSSAPI authentication method, but is disabled by default in most browsers.
If the Kerberos configuration file is not using the default name and location of /etc/krb5.conf, export the KRB5_CONFIG environment variable with the correct path and file name before launching the Firefox:
[user@host ~]$export KRB5_CONFIG=/etc/idm.conf[user@host ~]$kinit localadminPassword for localadmin@EXAMPLE.COM:localadmin12345[user@host ~]$firefox
In Firefox, navigate to about:config, and filter the settings by typing negotiate.
Set the network.negotiate-auth.trusted-uris option to the DNS name of the Kerberos domain.
The option supports a list of comma-separated URLs.
Navigate to a website configured to use Kerberos authentication, such as the IdM web UI, and then import the CA certificate to permanently trust the site.
The web browser should use your cached credentials to transparently authenticate you to the website.
To troubleshoot authentication failures, inspect the logs on the server side for applicable errors.
References
Further information is available in Managing IdM Users, Groups, Hosts, and Access Control Rules at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/managing_idm_users_groups_hosts_and_access_control_rules/index#role-of-idm-kdc_managing-kerberos-ticket-policies
For more information on single sign-on, go to the Configuring Firefox to Use Kerberos for Single Sign-on chapter in Configuring Authentication and Authorization in RHEL at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_authentication_and_authorization_in_rhel/index#Configuring_Firefox_to_use_Kerberos_for_SSO
