Chapter 12. Identity Management
The following chapters contain the most notable changes to Identity Management (IdM) between RHEL 9 and RHEL 10.
The IdM server functions only partially or not at all
In this release, changes introduced by OpenSSL have impacted the integrated DNS functionality within Identity Management (IdM). Most notably, the OpenSSL PKCS#11 engine is replaced by a new pkcs11-provider. This shift affects multiple components in IdM, including ipa, bind, bind-dyndb-ldap, softhsm, and python-cryptography.
The transition from the openssl-pkcs11 engine to the pkcs11-provider changes the way these components interact with security modules. As a result, all IdM components relying on the previous OpenSSL engine require updates to remain compatible with the new pkcs11-provider.
To support the new pkcs11-provider, a migration to Bind 9.20 is necessary. Bind 9.20 is the first version that provides compatibility with the pkcs11-provider, but it also introduces substantial architectural changes. These changes require a major rewrite of the bind-dyndb-ldap plugin to ensure that it continues functioning properly with the updated Bind and OpenSSL configurations.
Consequently, the IdM server functions only partially or not at all in RHEL 10-Beta. Specifically, you cannot install the ipa-server-dns package, and the embedded DNS server cannot be configured using the --setup-dns option. Until the necessary updates to bind-dyndb-ldap and other impacted components are completed, the integrated DNS feature remains unavailable.
IdM-to-IdM migration is now available as a Technology Preview
In RHEL 10, you can use the new ipa-migrate utility, which Red Hat provides as an unsupported Technology Preview, to migrate all IdM-specific data, such as SUDO rules, HBAC, DNA ranges, hosts, services, and more, to another IdM server. This can be useful, for example, when moving IdM from a development or staging environment into a production one or when migrating IdM data between two production servers.
ansible-freeipa now uses the Ansible collection format
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.
HSM support is available as a Technology Preview
Hardware Security Module (HSM) support is now available in IdM as a Technology Preview. You can store your key pairs and certificates for your IdM CA and 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.
Migration of an existing CA or KRA to an HSM-based setup is not supported. You need to reinstall the CA or KRA with keys on the HSM.
You need the following:
- A supported HSM
- The HSM PKCS#11 library
- An available slot, token, and the token password
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
The pam_console module has been removed
The pam_console module has been removed from RHEL 10. The pam_console module granted file permissions and authentication capabilities to users logged in at the physical console or terminals, and adjusted these privileges based on console login status and user presence. As an alternative to pam_console, you can use the systemd-logind system service instead. For configuration details, see the logind.conf(5) man page.
The libsss_simpleifp subpackage has been removed
The libsss_simpleifp subpackage that provided the libsss_simpleifp.so library was deprecated in Red Hat Enterprise Linux (RHEL) 9. The libsss_simpleifp subpackage has been removed in RHEL 10.
The enumeration feature has been removed for AD and IdM providers
Support for the enumeration feature, which enabled you to list all users or groups using getent passwd/group for AD and IdM providers, was deprecated in Red Hat Enterprise Linux (RHEL) 9. The enumeration feature has been removed in RHEL 10.
The NIS server emulator has been removed
RHEL IdM does not provide the NIS functionality anymore.
The 389-ds-base package now creates instances with LMDB by default
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:
- The migration procedure
- The database configuration parameters
- The database tuning
- Monitoring and log files
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:
nsslapd-mdb-max-sizesets the database maximum size in bytes. +- Important
-
Make sure that
nsslapd-mdb-max-sizeis high enough to store all intended data. However, the parameter size must not be too high to impact the performance because the database file is memory-mapped.
-
nsslapd-mdb-max-readerssets the maximum number of read operations that can be opened at the same time. Directory Server autotunes this setting. -
nsslapd-mdb-max-dbssets the maximum number of named database instances that can be included within the memory-mapped database file.
Along with the new LMDB settings, you can still use the nsslapd-db-home-directory database configuration parameter.
The BDB instances will not be supported in the future Directory Server releases. Therefore, migrate all instances to LMDB.
authselect is mandatory to configure authentication and identity sources
In RHEL 10, authselect is required by PAM and manages nsswitch.conf and selected PAM configuration, including system-auth, password-auth, smartcard-auth, fingerprint-auth, and postlogin in /etc/pam.d/.
For system upgrades from previous RHEL versions:
-
If an
authselectconfiguration already exists,authselect apply-changesautomatically updates the configuration to the latest version. If there was no previousauthselectconfiguration on your system, no changes are made. -
On systems managed by
authselect, any non-authselect configurations are now forcefully overwritten without a prompt during the nextauthselectcall. The--forceoption is no longer required.
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
The SSSD files provider has been removed
The SSSD files provider has been removed from RHEL 10.0. Previously, the SSSD files provider was responsible for smart card authentication and session recording for local users. As a replacement, you can configure the SSSD proxy provider.
Local profile is the new default authselect profile
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.
