Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 13. Identity Management

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

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

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:

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

Encrypted DNS with DoT is available in ansible-freeipa installations of IdM as a Technology Preview

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:

  • ipaserver_dns_over_tls with the freeipa.ansible_freeipa.ipaserver role for a new server.
  • ipareplica_dns_over_tls with the freeipa.ansible_freeipa.ipareplica role for a replica.
  • dot_forwarder to specify an upstream DoT-enabled DNS server.
  • dns_over_tls_key and dns_over_tls_cert to configure DoT certificates.

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

Compatibility between the ansible-freeipa RPM and RH AAH collections

Starting with RHEL 10.1, the freeipa.ansible_freeipa collection that the ansible-freeipa RPM package provides is now compatible with the namespace and name of the redhat.rhel_idm collection provided by Red Hat Ansible Automation Hub (RH AAH). If you have installed the RPM package, you can now run playbooks that reference the AAH roles and modules. Note that internally, the namespace and names from the RPM package are used.

Support for dynamic DoT updates in SSSD

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:

  • dyndns_dns_over_tls
  • dyndns_tls_ca_cert
  • dyndns_tls_cert
  • dyndns_tls_key

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

IdM-to-IdM migration is fully supported in IdM

IdM-to-IdM migration, previously available as a Technology Preview, is fully supported in RHEL 10.1. You can use the ipa-migrate command to migrate all IdM-specific data, such as SUDO rules, HBAC, DNA ranges, hosts, services, and more, from one IdM server to another. This can be useful, for example, when moving IdM from a development or staging environment into a production environment.

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

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

Automated removal of expired certificates is enabled by default

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.

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 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 RSA PKINIT method has been removed

The private key-based RSA method is no longer supported in the MIT Kerberos. It has been removed for security reasons, especially for its vulnerability to the Marvin attack. As a result, the -X flag_RSA_PROTOCOL parameter of the kinit commands has no effect anymore. The Diffie-Hellman key agreement method is used as the default PKINIT mechanism.

The 389-ds-base package now creates only LMDB instances

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-size sets the database maximum size in bytes. +

    Important
    Make sure that nsslapd-mdb-max-size is 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-readers sets the maximum number of read operations that can be opened at the same time. Directory Server autotunes this setting.
  • nsslapd-mdb-max-dbs sets 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 are no longer supported in Directory Server. Therefore, migrate all instances to LMDB.

nsslapd-subtree-rename-switch is removed from 389-ds-base

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

authselect is now required by PAM and cannot be uninstalled

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 an authselect configuration already exists, authselect apply-changes automatically updates the configuration to the latest version. If there was no previous authselect configuration 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 next authselect call. The --force option 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
Copy to Clipboard Toggle word wrap

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.

The dnssec-enable: no; option has been removed

The dnssec-enable: no; option in the /etc/named/ipa-options-ext.conf file has been removed in RHEL 10.0. DNS Security Extensions (DNSSEC) are enabled by default and cannot be disabled. The dnssec-validation: no; option still continues to be available.

The reconnection_retries option has been removed

The reconnection_retries option has been removed from the sssd.conf file in SSSD in RHEL 10.0. Because SSSD switched to a new architecture using internal IPC between SSSD processes and responders no longer connect to the backend, the reconnection_retries option is no longer used.

The new SSSD option ldap_read_rootdse to control RootDSE reads

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.

Improved smart card authentication for environments with multiple PKCS#11 tokens

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.

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