Chapter 13. Identity Management

Encrypted DNS using DNS over TLS (DoT) is available as a Technology Preview in Identity Management (IdM) deployments in RHEL 10. You can encrypt all DNS queries and responses between DNS clients and IdM DNS servers.

To start using this functionality, install the ipa-server-encrypted-dns package on IdM servers and replicas, and the ipa-client-encrypted-dns package on IdM clients. Administrators can enable DoT during the installation using the --dns-over-tls option.

IdM configures Unbound as a local caching resolver and BIND to receive DoT requests. This functionality is available through the command-line interface (CLI) and non-interactive installations of IdM.

The following options were added to installation utilities for IdM servers, replicas, clients, and the integrated DNS service:

By default, IdM uses the relaxed DNS policy, which allows fallback to unencrypted DNS. You can enforce encrypted-only communication by using the new --dns-policy option with the enforced setting.

You can also enable DoT on an existing IdM deployment by reconfiguring the integrated DNS service using ipa-dns-install with the new DoT options.

You can use Ansible to ensure that all DNS queries and responses between DNS clients and Identity Management (IdM) DNS servers are encrypted. Encrypted DNS using DNS over TLS (DoT) has been available as a Technology Preview in IdM deployments since RHEL 10. In RHEL 10.1, the functionality is available as a Technology Preview in the freeipa.ansible_freeipa collection.

To enable DoT during a deployment of IdM by using ansible-freeipa use the following options:

Additionally, you can set the dns_policy variable to enforce DoT-only communication, overriding the default behavior that allows fallback to unencrypted DNS.

SSSD now supports performing all dynamic DNS (dyndns) queries using DNS-over-TLS (DoT). You can securely update DNS records when IP addresses change, such as Identity Management (IdM) and Active Directory servers. To enable this functionality, you must install the nsupdate tool from the bind9.18-utils package.

You can use the following new options in the sssd.conf file to enable DoT and configure custom certificates for secure DNS updates:

For more details about these options, see the sssd-ad(5) and sssd-ad(5) man pages on your system.

In RHEL 10, the ansible-freeipa rpm installs the freeipa.ansible_freeipa collection only.

To use the new collection, add the freeipa.ansible_freeipa prefix to the names of roles and modules. Use the fully-qualified names to follow Ansible recommendations. For example, to refer to the ipahbacrule module, use freeipa.ansible_freeipa.ipahbacrule.

You can simplify the use of modules that are part of the freeipa.ansible_freeipa collection by applying module_defaults.

Hardware Security Modules (HSM) are now fully supported in Identity Management (IdM). You can store your key pairs and certificates for your IdM Cerificate Authority (CA) and Key Recovery Authority (KRA) on an HSM. This adds physical security to the private key material.

IdM relies on the networking features of the HSM to share the keys between machines to create replicas. The HSM provides additional security without visibly affecting most IPA operations. When using low-level tooling the certificates and keys are handled differently but this is seamless for most users.

You need the following:

To install a CA or KRA with keys stored on an HSM, you must specify the token name and the path to the PKCS#11 library. For example:

ipa-server-install -r EXAMPLE.TEST -U --setup-dns --allow-zone-overlap --no-forwarders -N --auto-reverse --random-serial-numbers --token-name=HSM-TOKEN --token-library-path=/opt/nfast/toolkits/pkcs11/libcknfast.so --setup-kra

ipa-server-install -r EXAMPLE.TEST -U --setup-dns --allow-zone-overlap --no-forwarders -N --auto-reverse --random-serial-numbers --token-name=HSM-TOKEN --token-library-path=/opt/nfast/toolkits/pkcs11/libcknfast.so --setup-kra

In RHEL 10, automated removal of expired certificates is now enabled by default in IdM on new replicas. A prerequisite for this is the generation of random serial numbers for certificates using RSNv3, which is now also enabled by default.

As a result, certificates are now created with random serial numbers and are removed automatically when expired, after a default retention period of 30 days after expiry.

Previously, Directory Server created instances with Berkeley Database (BDB). However, the libdb library that implements the BDB version used by 389-ds-base is no longer available in RHEL 10.

Starting with RHEL 10, the 389-ds-base package uses the Lightning Memory-Mapped Database (LMDB) as the database type by default. This change impacts the following areas:

LMDB introduces the following configuration parameters that are stored under the new cn=mdb,cn=config,cn=ldbm database,cn=plugins,cn=config configuration entry:

Along with the new LMDB settings, you can still use the nsslapd-db-home-directory database configuration parameter.

The BDB instances are no longer supported in Directory Server. Therefore, migrate all instances to LMDB.

Before this update, you could configure Directory Server to prevent moving entries between sub-trees in a database. Because of the stability issues, this feature is removed. Consequently, the nsslapd-subtree-rename-switch parameter no longer exists.

As a result, you can no longer deactivate moving the entries between sub-trees. As an alternative, you can deactivate moving the entries by creating an access control instruction (ACI).

In RHEL 10, authselect-libs package now owns /etc/nsswitch.conf and selected PAM configuration, including system-auth, password-auth, smartcard-auth, fingerprint-auth, and postlogin in /etc/pam.d/. Ownership of these files has been transferred to authselect-libs package, with /etc/nsswitch.conf previously owned by the glibc package and the PAM configuration files previously owned by the pam package. Since authselect is required by the pam package, it cannot be uninstalled.

For system upgrades from previous RHEL versions:

If you require a special configuration, create a custom authselect profile. Note that you must manually update custom profiles to keep them up to date with your system.

You can opt-out from using authselect:

authselect opt-out

# authselect opt-out

Due to the removal of the SSSD files provider in RHEL 10.0, a new authselect local profile has been introduced to handle local user management without relying on SSSD. The local profile replaces the previous minimal profile and becomes the default authselect profile for new installations instead of the sssd profile.

During upgrades, the authselect utility automatically migrates existing configurations from minimal to local profile.

Additionally, the sssd authselect profile has been updated to remove the with-files-domain and with-files-access-provider options and it no longer handles local user accounts directly via these options. If you relied on these options, you must update your SSSD configuration to use proxy provider instead of files provider.

The sssd profile now supports the --with-tlog option, which enables session recording for users managed by SSSD.

As of RHEL 10.1, SSSD provides a new option, ldap_read_rootdse, to control how SSSD reads Root Directory Service Entry (RootDSE) from the LDAP server. By default, SSSD attempts to read the RootDSE anonymously before the user authenticates. However, this default behavior might conflict with strict security policies that typically restrict all anonymous binds to the LDAP server.

To manage this behavior, you can configure the ldap_read_rootdse option to authenticated to instruct SSSD to read the RootDSE only after a successful user authentication, or set it to never to completely prevent SSSD from attempting the read.

In RHEL 10.1, SSSD smart card authentication has been enhanced to handle authentication in environments that have multiple PKCS#11 tokens inserted simultaneously. This improves authentication, especially in STIG compliant environments that require multiple user accounts, each with distinct privileges and often tied to a separate PKI token.

Previously, SSSD might fail to authenticate if the first checked token did not contain a matching certificate, because SSSD did not continue searching for the appropriate certificate on other available tokens. With this update, SSSD scans all inserted PKCS#11 tokens for a matching authentication certificate, so that users can authenticate successfully.

The default Red Hat Enterprise Linux (RHEL) 10 FIPS cryptographic policy, which complies with FIPS 140-3, does not allow the use of the AES HMAC-SHA1 encryption type’s key derivation function.

This constraint prevents adding a RHEL 10 Identity Management (IdM) replica in FIPS mode to an existing IdM environment that uses a SHA-1-based Kerberos master key. While RHEL 9 and RHEL 10 both use AES HMAC-SHA2 by default, an IdM deployment might still use a SHA-1 master key if it was originally initialized on RHEL 8.6 or earlier.

In RHEL 10, the following external authentication modules are not supported as part of the FreeRADIUS offering:

You can find replacements for the removed modules in community-supported packages, for example in the Fedora project.

In addition, support for the freeradius package is now limited to the following use cases:

In contrast to these removals, Red Hat is enhancing its support for the following external authentication modules with FreeRADIUS:

The focus on these integration options is in close alignment with the strategic direction of Red Hat IdM.