Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 14. Identity Management

The following chapters contain the most notable changes to Identity Management (IdM) between RHEL 8 and RHEL 9.

14.1. New features

A new passwordless authentication method is available in SSSD

As of RHEL 9.4, you can enable and configure passwordless authentication in SSSD to use a biometric device that is compatible with the FIDO2 specification, for example a YubiKey. You must register the FIDO2 token in advance and store this registration information in the user account in RHEL IdM, Active Directory, or an LDAP store. RHEL implements FIDO2 compatibility with the libfido2 library, which currently only supports USB-based tokens.

Identity Management API is now fully supported

As of RHEL 9.3, the Identity Management (IdM) API is a fully supported feature.

Users can use existing tools and scripts even if the IdM API is enhanced to enable multiple versions of API commands. These enhancements do not change the behavior of a command in an incompatible way. This has the following benefits:

  • Administrators can use previous or later versions of IdM on the server than on the managing client.
  • Developers can use a specific version of an IdM call, even if the IdM version changes on the server.

The communication with the server is possible, regardless if one side uses, for example, a newer version that introduces new options for a feature.

NOTE
While IdM API provides a JSON-RPC interface, this type of access is not supported. Red Hat recommends accessing the API with Python instead. Using Python automates important parts such as the metadata retrieval from the server, which allows listing all available commands.

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:

    Copy to Clipboard Toggle word wrap 
    # dnf install ipa-server

  • For a server with integrated DNS services:

    Copy to Clipboard Toggle word wrap 
    # 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:

  1. Configure SSSD. Choose one of the following options:

    1. Explicitly configure a local domain with the id_provider=files option in the sssd.conf configuration file.

      Copy to Clipboard Toggle word wrap 
      [domain/local]
id_provider=files
...

    2. Enable the files provider by setting the enable_files_domain=true option in the sssd.conf configuration file.

      Copy to Clipboard Toggle word wrap 
      [sssd]
enable_files_domain = true

  2. Configure the name services switch.

    Copy to Clipboard Toggle word wrap 
    # authselect enable-feature with-files-provider

  3. To restore caching and synchronization of user information, enable the integration between shadow-utils and sssd_cache by creating a symbolic link:

    Copy to Clipboard Toggle word wrap 
    # ln -s /usr/sbin/sss_cache /usr/sbin/sss_cache_shadow_utils

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-2 family 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-1 to AES 256 HMAC SHA-384.
Warning

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.

Adding the 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:

Copy to Clipboard Toggle word wrap 
  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.

Improved SSSD multi-threaded performance

Previously, SSSD serialized parallel requests from multi-threaded applications, such as Red Hat Directory Server and Identity Management. Starting with RHEL 9.1, all SSSD client libraries, such as nss and pam, do not serialize requests, therefore allowing requests from multiple threads to be executed in parallel for better performance.

To enable the previous behavior of serialization, set the environment variable SSS_LOCKFREE to NO.

ansible-freeipa now additionally provides the roles and modules as an Ansible collection in the ansible-freeipa-collection subpackage

To use the new collection:

  1. Install the ansible-freeipa-collection subpackage.
  2. 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 the modules that are part of the freeipa.ansible_freeipa collection by applying module_defaults.

HSM is now fully supported in IdM

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.

Note

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 Public-Key Cryptography Standard (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:

Copy to Clipboard Toggle word wrap 
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

named now uses OpenSSL to ensure DNSSEC validation

In RHEL 9, the named daemon in RHEL Identity Management (IdM) has adopted the OpenSSL PKCS#11 engine to secure DNS data with a digital signature to protect DNS from attacks. Previously in RHEL 8, IdM used a special version of the bind package, namely bind-pkcs11, for this purpose. Additionally, this update removes the bind-pkcs11-utils package. Use pkcs11-tool from the opensc package to manage PKCS#11 tokens or stored keys instead.

14.2. Technology previews

IdM-to-IdM migration is now available as a Technology Preview

In RHEL 9.5, 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.

DNS over TLS (DoT) in IdM deployments is available as a Technology Preview

As of RHEL 9.6, encrypted DNS using DNS over TLS (DoT) is available as a Technology Preview in Identity Management (IdM) deployments. 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:

  • --dot-forwarder to specify an upstream DoT-enabled DNS server.
  • --dns-over-tls-key and --dns-over-tls-cert to configure DoT certificates.
  • --dns-policy to set a DNS security policy to either allow fallback to unencrypted DNS or enforce strict DoT usage.

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.

14.3. Known issues

Users without SIDs cannot log in to IdM after an upgrade

After upgrading your Identity Management (IdM) replica to RHEL 9.2, the IdM Kerberos Distribution Centre (KDC) might fail to issue ticket-granting tickets (TGTs) to users who do not have Security Identifiers (SIDs) assigned to their accounts. Consequently, the users cannot log in to their accounts.

To work around the problem, generate SIDs by running the following command as an IdM administrator on another IdM replica in the topology:

Copy to Clipboard Toggle word wrap 
# ipa config-mod --enable-sid --add-sids

Afterward, if users still cannot log in, examine the Directory Server error log. You might have to adjust ID ranges to include user POSIX identities.

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 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. For more information, see the AD Domain Users unable to login in to the FIPS-compliant environment KCS solution.

Note

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.

14.4. Relocated packages

ansible-freeipa is now available in the AppStream repository with all dependencies

Previously in RHEL 8.5 and earlier, 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 rhel-9-for-x86_64-appstream-rpms repository.

ansible-freeipa in RHEL 9 contains all the modules that it contained in RHEL 8.5 and earlier.

Clustered Samba packages are now available from the Resilient Storage and Gluster Samba Repository

The 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.

14.5. Removed functionality

The nss-pam-ldapd package has been removed

The 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:

  • nss_nis
  • yp-tools
  • ypbind
  • ypserv

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

As the 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 ldap and 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.

To allow 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:

Copy to Clipboard Toggle word wrap 
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

The custodia package has been removed

The 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.

The nsslapd-conntablesize configuration parameter has been removed from 389-ds-base

The nsslapd-conntablesize configuration parameter has been removed from the 389-ds-base package in RHEL 9.3. Previously, the nsslapd-conntablesize configuration attribute specified the size of the connection table that managed established connections. With the introduction of the multi-listener feature, which improves the management of established connections, Directory Server now calculates the size of the connection table dynamically. This also resolves issues, when the connection table size was set too low and it affected the number of connections the server was able to support. Starting with RHEL 9.3, use only nsslapd-maxdescriptors and nsslapd-reservedescriptors attributes to manage the number of TCP/IP connections Directory Server can support.

Limited support for FreeRADIUS

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

  • The MySQL, PostgreSQL, SQlite, and unixODBC database connectors
  • The Perl language module
  • The REST API module
Note

The PAM authentication module and other authentication modules that are provided as part of the base package are not affected.

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

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

  • Using FreeRADIUS as an authentication provider with Identity Management (IdM) as the backend source of authentication. The authentication is happening through the krb5 and LDAP authentication packages or as PAM authentication in the main FreeRADIUS package.
  • Using FreeRADIUS to provide a source-of-truth for authentication in IdM, through the Python 3 authentication package.

In contrast to these removals, Red Hat is now strengthening its support of the following external authentication modules with FreeRADIUS:

  • Authentication based on krb5 and LDAP
  • Python 3 authentication

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

The nsslapd-changelogcompactdb-interval parameter has been removed from the 389-ds-base package

Starting with RHEL 9.0, the Directory Server changelog was integrated into the main database. As a result, the nsslapd-changelogcompactdb-interval parameter no longer exists.

The nsslapd-logging-hr-timestamps-enabled configuration parameter has been removed from the 389-ds-base package

The nsslapd-logging-hr-timestamps-enabled configuration parameter has been removed from the 389-ds-base package in RHEL 9.6. Before this update, you could turn off the high resolution timestamps in Directory Server and the log files would have the following timestamps:

Copy to Clipboard Toggle word wrap 
11/Feb/2025:20:30:48

Starting with RHEL 9.6, Directory Server log files use only high resolution timestamps:

Copy to Clipboard Toggle word wrap 
11/Feb/2025:20:30:48.736142391
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.