Chapter 18. Identity Management
This chapter lists the most notable changes to Identity Management (IdM) between RHEL 8 and RHEL 9.
18.1. New features
Identity Management installation packages have been demodularized
Previously in RHEL 8, IdM packages were distributed as modules, which required you to enable a stream and install the profile that corresponds to your desired installation. IdM installation packages have been demodularized in RHEL 9, so you can use the following dnf commands to install IdM server packages:
For a server without integrated DNS services:
# dnf install ipa-server
For a server with integrated DNS services:
# dnf install ipa-server ipa-server-dns
The SSSD implicit files provider domain is disabled by default
The SSSD implicit
files provider domain, which retrieves user information from local files such as
/etc/shadow and group information from
/etc/groups, is now disabled by default.
To retrieve user and group information from local files with SSSD:
Configure SSSD. Choose one of the following options:
Explicitly configure a local domain with the
id_provider=filesoption in the
[domain/local] id_provider=files ...
filesprovider by setting the
enable_files_domain=trueoption in the
[sssd] enable_files_domain = true
Configure the name services switch.
# authselect enable-feature with-files-provider
New realm configuration template for KDC enabling FIPS 140-3-compliant key encryption
This update provides a new,
EXAMPLE.COM, example realm configuration in the
/var/kerberos/krb5kdc/kdc.conf file. It brings two changes:
The FIPS 140-3-compliant
AES HMAC SHA-2family is added to the list of supported types for key encryption.
The encryption type of the KDC master key is switched from
AES 256 HMAC SHA-1to
AES 256 HMAC SHA-384.
This update is about standalone MIT realms. Do not change the Kerberos Distribution Center (KDC) configuration in RHEL Identity Management.
Using the new configuration template is recommended for new realms. The template does not affect any realm already deployed. If you are planning to upgrade the configuration of your realm according to the template, consider the following points:
For upgrading the master key, changing the setting in the KDC configuration is not enough. Follow the process described in the MIT Kerberos documentation.
AES HMAC SHA-2 family to the supported types for key encryption is safe at any point because it does not affect existing entries in the KDC. Keys will be generated only when creating new principals or when renewing credentials. Note that keys of this new type cannot be generated based on existing keys. To make these new encryption types available for a certain principal, its credentials have to be renewed, which means renewing keytabs for service principals too.
The only case where principals should not feature an
AES HMAC SHA-2 key is the Active Directory (AD) cross-realm ticket-granting ticket (TGT) ones. Because AD does not implement RFC8009, it does not use the
AES HMAC SHA-2 encryption types family. Therefore, a cross-realm TGS-REQ using an
AES HMAC SHA-2-encrypted cross-realm TGT would fail. The best way to keep the MIT Kerberos client from using
AES HMAC SHA-2 against AD is to not provide
AES HMAC SHA-2 keys for the AD cross-realm principals. To do so, ensure that you create the cross-realm TGT entries with an explicit list of key encryption types that are all supported by AD:
kadmin.local <<EOF add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[MIT realm]@[AD realm] add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[AD realm]@[MIT realm] EOF
To ensure the MIT Kerboros clients use the
AES HMAC SHA-2 encryption types, you must also set these encryption types as
permitted in both the client and the KDC configuration. On RHEL, this setting is managed by the crypto-policy system. For example, on RHEL 9, hosts using the
DEFAULT crypto-policy allow
AES HMAC SHA-2 and
AES HMAC SHA-1 encrypted tickets, while hosts using the
FIPS crypto-policy only accept
AES HMAC SHA-2 ones.
18.2. Known issues
Adding a RHEL 9 replica in FIPS mode to an IdM deployment in FIPS mode that was initialized with RHEL 8.6 or earlier fails
The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1.
This constraint does not allow you to add a RHEL 9 Identity Management (IdM) replica in FIPS mode to a RHEL 8 IdM environment in FIPS mode in which the first server was installed on a RHEL 8.6 or earlier systems. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types.
To work around the problem, enable the use of AES HMAC-SHA1 on the RHEL 9 replica:
# update-crypto-policies --set FIPS:AD-SUPPORT
By setting the cryptographic policy to
FIPS:AD-SUPPORT, you are adding the following encryption types to the list of already allowed encryption types that comply with FIPS 140-3:
As a result, adding the RHEL 9 replica to the IdM deployment proceeds correctly.
There is ongoing work to provide a procedure to generate missing AES HMAC-SHA2-encrypted Kerberos keys on RHEL 7 and RHEL 8 servers. This will achieve FIPS 140-3 compliance on the RHEL 9 replica. However, this process cannot be fully automated, because the design of Kerberos key cryptography makes it impossible to convert existing keys to different encryption types. The only way is to ask users to renew their passwords.
You can view the encryption type of your IdM master key by entering the following command on the first IdM server in the RHEL 8 deployment:
# kadmin.local getprinc K/M | grep -E '^Key:'
If the string in the output contains the
sha1 term, you must enable the use of AES HMAC-SHA1 on the RHEL 9 replica.
Microsoft’s Active Directory implementation does not yet support any of the RFC8009 Kerberos encryption types that use SHA-2 HMAC. If you have an IdM-AD trust configured, FIPS:AD-SUPPORT crypto subpolicy use is therefore required even if the encryption type of your IdM master key is
18.3. Relocated packages
ansible-freeipa is now available in the AppStream repository with all dependencies
Previously in RHEL 8, before installing the
ansible-freeipa package, you first had to enable the Ansible repository and install the
ansible package. In RHEL 9, you can install
ansible-freeipa without any preliminary steps. Installing
ansible-freeipa automatically installs
ansible-core as a dependency. Both packages are available in the
ansible-freeipa in RHEL 9 contains all the modules that it contained in RHEL 8.
Clustered Samba packages are now available from the Resilient Storage and Gluster Samba Repository
ctdb clustered Samba packages are now available from the Resilient Storage and Gluster Samba Repository. Previously in RHEL 8, clustered Samba packages were available from the BaseOS repository.
18.4. Removed functionality
The nss-pam-ldapd package has been removed
nss-pam-ldapd package has been removed from RHEL. Red Hat recommends migrating to SSSD and its
ldap provider, which fully replaces the functionality of the
nslcd service. SSSD has features that specifically address the needs of
nss-pam-ldapd users, such as:
- hosts databases
- networks databases
- services databases
NIS packages have been removed
The following Network Information Service (NIS) components have been removed from RHEL:
There is no direct replacement with fully compatible features because the NIS technology is based on outdated design patterns and is no longer considered secure.
Red Hat recommends using RHEL Identity Management and SSSD instead.
The openssh-ldap package has been removed
openssh-ldap subpackage is not maintained upstream, it has been removed from RHEL. Red Hat recommends using SSSD and the
sss_ssh_authorizedkeys helper, which integrate better with other IdM solutions and are more secure.
By default, the SSSD
ipa providers read the
sshPublicKey LDAP attribute of the user object, if available. Note that you cannot use the default SSSD configuration for the
ad provider or IdM trusted domains to retrieve SSH public keys from Active Directory (AD), since AD does not have a default LDAP attribute to store a public key.
To allow the
sss_ssh_authorizedkeys helper to get the key from SSSD, enable the
ssh responder by adding
ssh to the
services option in the
sssd.conf file. See the
sssd.conf(5) man page for details.
sshd to use
sss_ssh_authorizedkeys, add the following options to the
/etc/ssh/sshd_config file as described by the
sss_ssh_authorizedkeys(1) man page:
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser nobody
The custodia package has been removed
custodia package has been integrated into Red Hat Identity Management in RHEL 9 and is no longer shipped as a separate service.
The gssntlmssp package has been removed
As Windows New Technology LAN Manager (NTLM) is considered insecure, the
gssntlmssp package has been removed.