Chapter 17. Identity Management
17.1. Identity Management packages are installed as a module
In RHEL 8, the packages necessary for installing an Identity Management (IdM) server and client are distributed as a module. The
client stream is the default stream of the
idm module, and you can download the packages necessary for installing the client without enabling the stream.
The IdM server module stream is called
DL1 and contains multiple profiles that correspond to the different types of IdM servers:
server: an IdM server without integrated DNS
dns: an IdM server with integrated DNS
adtrust: an IdM server that has a trust agreement with Active Directory
client: an IdM client
To download the packages in a specific profile of the
Enable the stream:
# yum module enable idm:DL1
Switch to the RPMs delivered through the stream:
# yum distro-sync
Install the selected profile:
# yum module install idm:DL1/profile
Replace profile with one of the specific profiles defined above.
17.2. Active Directory users can now administer Identity Management
In Red Hat Enterprise Linux (RHEL) 7, external group membership allows AD users and groups to access IdM resources in a POSIX environment with the help of the System Security Services Daemon (SSSD).
The IdM LDAP server has its own mechanisms to grant access control. RHEL 8 introduces an update that allows adding an ID user override for an AD user as a member of an IdM group. An ID override is a record describing what a specific Active Directory user or group properties should look like within a specific ID view, in this case the Default Trust View. As a consequence of the update, the IdM LDAP server is able to apply access control rules for the IdM group to the AD user.
AD users are now able to use the self service features of IdM UI, for example to upload their SSH keys, or change their personal data. An AD administrator is able to fully administer IdM without having two different accounts and passwords.
Currently, selected features in IdM may still be unavailable to AD users. For example, setting passwords for IdM users as an AD user from the IdM
admins group might fail.
17.3. Session recording solution for RHEL 8 added
A session recording solution has been added to Red Hat Enterprise Linux 8 (RHEL 8). A new
tlog package and its associated web console session player enable to record and playback the user terminal sessions. The recording can be configured per user or user group via the System Security Services Daemon (SSSD) service. All terminal input and output is captured and stored in a text-based format in a system journal. The input is inactive by default for security reasons not to intercept raw passwords and other sensitive information.
The solution can be used for auditing of user sessions on security-sensitive systems. In the event of a security breach, the recorded sessions can be reviewed as a part of a forensic analysis. The system administrators are now able to configure the session recording locally and view the result from the RHEL 8 web console interface or from the Command-Line Interface using the
17.4. Removed Identity Management functionality
NTP Server IdM server role
ntpd has been deprecated in favor of
chronyd in RHEL 8, IdM servers are no longer configured as Network Time Protocol (NTP) servers and are only configured as NTP clients. The RHEL 7
NTP Server IdM server role has also been deprecated in RHEL 8.
17.4.2. NSS databases not supported in OpenLDAP
The OpenLDAP suite in previous versions of Red Hat Enterprise Linux (RHEL) used the Mozilla Network Security Services (NSS) for cryptographic purposes. With RHEL 8, OpenSSL, which is supported by the OpenLDAP community, replaces NSS. OpenSSL does not support NSS databases for storing certificates and keys. However, it still supports privacy enhanced mail (PEM) files that serve the same purpose.
17.4.3. Selected Python Kerberos packages have been replaced
In Red Hat Enterprise Linux (RHEL) 8, the
python-gssapi package has replaced Python Kerberos packages such as
python-urllib2_kerberos. Notable benefits include:
python-gssapiis easier to use than
Additional Kerberos packages,
python-urllib-gssapi, are currently available in the Extra Packages for Enterprise Linux (EPEL) repository.
The GSSAPI-based packages allow the use of other Generic Security Services API (GSSAPI) mechanisms in addition to Kerberos, such as the NT LAN Manager
NTLM for backward compatibility reasons.
This update improves the maintainability and debuggability of GSSAPI in RHEL 8.
17.5.1. AD GPOs are now enforced by default
In RHEL 8, the default setting for the
ad_gpo_access_control option is
enforcing, which ensures that access control rules based on Active Directory Group Policy Objects (GPOs) are evaluated and enforced.
In contrast, the default for this option in RHEL 7 is
permissive, which evaluates but does not enforce GPO-based access control rules. With
permissive mode, a syslog message is recorded every time a user would be denied access by a GPO, but those users are still allowed to log in.
Red Hat recommends ensuring GPOs are configured correctly in Active Directory before upgrading from RHEL 7 to RHEL 8.
Misconfigured GPOs that do not affect authorization in default RHEL 7 hosts may affect default RHEL 8 hosts.
For more information on GPOs, see Applying Group Policy Object access control in RHEL and the
ad_gpo_access_control entry in the
sssd-ad Manual page.
In RHEL 8, the
authselect utility replaces the
authselect comes with a safer approach to PAM stack management that makes the PAM configuration changes simpler for system administrators.
authselect can be used to configure authentication methods such as passwords, certificates, smart cards and fingerprint.
authselect does not configure services required to join remote domains. This task is performed by specialized tools, such as
17.5.3. KCM replaces KEYRING as the default credential cache storage
In RHEL 8, the default credential cache storage is the Kerberos Credential Manager (KCM) which is backed by the
sssd-kcm deamon. KCM overcomes the limitations of the previously used KEYRING, such as its being difficult to use in containerized environments because it is not namespaced, and to view and manage quotas.
With this update, RHEL 8 contains a credential cache that is better suited for containerized environments and that provides a basis for building more features in future releases.
sssctl prints an HBAC rules report for an IdM domain
With this update, the
sssctl utility of the System Security Services Daemon (SSSD) can print an access control report for an Identity Management (IdM) domain. This feature meets the need of certain environments to see, for regulatory reasons, a list of users and groups that can access a specific client machine. Running
domain_name on an IdM client prints the parsed subset of host-based access control (HBAC) rules in the IdM domain that apply to the client machine.
Note that no other providers than IdM support this feature.
17.5.5. Local users are cached by SSSD and served through the
In RHEL 8, the System Security Services Daemon (SSSD) serves users and groups from the
/etc/groups files by default. The
sss nsswitch module precedes files in the
The advantage of serving local users through SSSD is that the
nss_sss module has a fast
memory-mapped cache that speeds up Name Service Switch (NSS) lookups compared to accessing the disk and opening the files on each NSS request. Previously, the Name service cache daemon (
nscd) helped accelerate the process of accessing the disk. However, using
nscd in parallel with SSSD is cumbersome, as both SSSD and
nscd use their own independent caching. Consequently, using
nscd in setups where SSSD is also serving users from a remote domain, for example LDAP or Active Directory, can cause unpredictable behavior.
With this update, the resolution of local users and groups is faster in RHEL 8. Note that the
root user is never handled by SSSD, therefore
root resolution cannot be impacted by a potential bug in SSSD. Note also that if SSSD is not running, the
nss_sss module handles the situation gracefully by falling back to
nss_files to avoid problems. You do not have to configure SSSD in any way, the files domain is added automatically.
17.5.6. SSSD now allows you to select one of the multiple smart-card authentication devices
By default, the System Security Services Daemon (SSSD) tries to detect a device for smart-card authentication automatically. If there are multiple devices connected, SSSD selects the first one it detects. Consequently, you cannot select a particular device, which sometimes leads to failures.
With this update, you can configure a new
p11_uri option for the
[pam] section of the
sssd.conf configuration file. This option enables you to define which device is used for smart-card authentication.
For example, to select a reader with the slot id
2 detected by the OpenSC PKCS#11 module, add:
p11_uri = library-description=OpenSC%20smartcard%20framework;slot-id=2
[pam] section of
For details, see the
man sssd.conf page.
17.6. Removed SSSD functionality
sssd-secrets has been removed
sssd-secrets component of the System Security Services Daemon (SSSD) has been removed in Red Hat Enterprise Linux 8. This is because Custodia, a secrets service provider, is no longer actively developed. Use other Identity Management tools to store secrets, for example the Identity Management Vault.