Chapter 18. Identity Management

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:

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

To retrieve user and group information from local files with SSSD:

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:

  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.

In AAH, ansible-freeipa roles and modules are distributed in the collection format. Note that you need an Ansible Automation Platform (AAP) subscription to access the content on the AAH portal. You also need ansible version 2.14 or later.

The redhat.rhel_idm collection has the same content as the traditional ansible-freeipa package. However, the collection format uses a fully qualified collection name (FQCN) that consists of a namespace and the collection name. For example, the redhat.rhel_idm.ipadnsconfig module corresponds to the ipadnsconfig module in ansible-freeipa provided by a RHEL repository. The combination of a namespace and a collection name ensures that the objects are unique and can be shared without any conflicts.

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

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

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

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.

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.

# kadmin.local getprinc K/M | grep -E '^Key:'

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

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.

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:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

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:

In contrast to these removals, Red Hat is now strengthening its support of 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.