Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapter 5. Authentication and Interoperability

SSSD in a container now fully supported

The rhel7/sssd container image, which provides the System Security Services Daemon (SSSD), is no longer a Technology Preview feature. The image is now fully supported. Note that the rhel7/ipa-server container image is still a Technology Preview feature.

Identity Management now supports FIPS

With this enhancement, Identity Management (IdM) supports the Federal Information Processing Standard (FIPS). This enables you to run IdM in environments that must meet the FIPS criteria. To run IdM with FIPS mode enabled, you must set up all servers in the IdM environment using Red Hat Enterprise Linux 7.4 with FIPS mode enabled.
Note that you cannot:
  • Enable FIPS mode on existing IdM servers previously installed with FIPS mode disabled.
  • Install a replica in FIPS mode when using an existing IdM server with FIPS mode disabled.

SSSD supports obtaining a Kerberos ticket when users authenticate with a smart card

The System Security Services Daemon (SSSD) now supports the Kerberos PKINIT preauthentication mechanism. When authenticating with a smart card to a desktop client system enrolled in an Identity Management (IdM) domain, users receive a valid Kerberos ticket-granting ticket (TGT) if the authentication was successful. Users can then use the TGT for further single sign-on (SSO) authentication from the client system.

SSSD enables logging in to different user accounts with the same smart card certificate

Previously, the System Security Services Daemon (SSSD) required every certificate to be uniquely mapped to a single user. When using smart card authentication, users with multiple accounts were not able to log in to all of these accounts with the same smart card certificate. For example, a user with a personal account and a functional account (such as a database administrator account) was able to log in only to the personal account.
With this update, SSSD no longer requires certificates to be uniquely mapped to a single user. As a result, users can now log in to different accounts with a single smart card certificate.

IdM web UI enables smart card login

The Identity Management web UI enables users to log in using smart cards.

New packages: keycloak-httpd-client-install

The keycloak-httpd-client-install packages provide various libraries and tools that can automate and simplify the configuration of Apache httpd authentication modules when registering as a Red Hat Single Sign-On (RH-SSO, also called Keycloak) federated Identity Provider (IdP) client.
As part of this update, new dependencies have been added to Red Hat Enterprise Linux:
  • The python-requests-oauthlib package: This package provides the OAuth library support for the python-requests package, which enables python-requests to use OAuth for authentication.
  • The python-oauthlib package: This package is a Python library providing OAuth authentication message creation and consumption. It is meant to be used in conjunction with tools providing message transport. (BZ#1401781, BZ#1401783, BZ#1401784)

New Kerberos credential cache type: KCM

This update adds a new SSSD service named kcm. The service is included in the sssd-kcm subpackage.
When the kcm service is installed, you can configure the Kerberos library to use a new credential cache type named KCM. When the KCM credential cache type is configured, the sssd-kcm service manages the credentials.
The KCM credential cache type is well-suited for containerized environments:
  • With KCM, you can share credential caches between containers on demand, based on mounting the UNIX socket on which the kcm service listens.
  • The kcm service runs in user space outside the kernel, unlike the KEYRING credential cache type that RHEL uses by default. With KCM, you can run the kcm service only in selected containers. With KEYRING, all containers share the credential caches because they share the kernel.
Additionally, the KCM credential cache type supports cache collections, unlike the FILE ccache type.
For details, see the sssd-kcm(8) man page. (BZ#1396012)

AD users can log in to the web UI to access their self-service page

Previously, Active Directory (AD) users were only able to authenticate using the kinit utility from the command line. With this update, AD users can also log in to the Identity Management (IdM) web UI. Note that the IdM administrator must create an ID override for an AD user before the user is able to log in.
As a result, AD users can access their self-service page through the IdM web UI. The self-service page displays the information from the AD users' ID override.

SSSD enables configuring an AD subdomain in the SSSD server mode

Previously, the System Security Services Daemon (SSSD) automatically configured trusted Active Directory (AD) domains. With this update, SSSD supports configuring certain parameters for trusted AD domains in the same way as the joined domain.
As a result, you can set individual settings for trusted domains, such as the domain controller that SSSD communicates with. To do this, create a section in the /etc/sssd/sssd.conf file with a name that follows this template:
For example, if the main IdM domain name is and the trusted AD domain name is, the corresponding section name is:

SSSD supports user and group lookups and authentication with short names in AD environments

Previously, the System Security Services Daemon (SSSD) supported user names without the domain component, also called short names, for user and group resolution and authentication only when the daemon was joined to a standalone domain. Now, you can use short names for these purposes in all SSSD domains in these environments:
  • On clients joined to Active Directory (AD)
  • In Identity Management (IdM) deployments with a trust relationship to an AD forest
The output format of all commands is always fully-qualified even when using short names. This feature is enabled by default after you set up a domain's resolution order list in one of the following ways (listed in order of preference):
  • Locally, by configuring the list using the domain_resolution_order option in the [sssd] section of the /etc/sssd/sssd.conf file
  • By using an ID view
  • Globally, in the IdM configuration
To disable the feature, set the use_fully_qualified_names option to True in the [domain/] section of the /etc/sssd/sssd.conf file. (BZ#1330196)

SSSD supports user and group resolution, authentication, and authorization in setups without UIDs or SIDs

In traditional System Security Services Daemon (SSSD) deployments, users and groups either have POSIX attributes set or SSSD can resolve the users and groups based on Windows security identifiers (SID).
With this update, in setups that use LDAP as the identity provider, SSSD now supports the following functionality even when UIDs or SIDs are not present in the LDAP directory:
  • User and group resolution through the D-Bus interface
  • Authentication and authorization through the plugabble authentication module (PAM) interface (BZ#1425891)

SSSD introduces the sssctl user-checks command, which checks basic SSSD functionality in a single operation

The sssctl utility now includes a new command named user-checks. The sssctl user-checks command helps debug problems in applications that use the System Security Services Daemon (SSSD) as a back end for user lookup, authentication, and authorization.
  • The sssctl user-checks [USER_NAME] command displays user data available through Name Service Switch (NSS) and the InfoPipe responder for the D-Bus interface. The displayed data shows whether the user is authorized to log in using the system-auth pluggable authentication module (PAM) service.
  • Additional options accepted by sssctl user-checks check authentication or different PAM services.
For details on sssctl user-checks, use the sssctl user-checks --help command. (BZ#1414023)

Support for secrets as a service

This update adds a responder named secrets to the System Security Services Daemon (SSSD). This responder allows an application to communicate with SSSD over a UNIX socket using the Custodia API. This enables SSSD to store secrets in its local database or to forward them to a remote Custodia server. (BZ#1311056)

IdM enables semi-automatic upgrades of the IdM DNS records on an external DNS server

To simplify updating the Identity Management (IdM) DNS records on an external DNS server, IdM introduces the ipa dns-update-system-records --dry-run --out [file] command. The command generates a list of records in a format accepted by the nsupdate utility.
You can use the generated file to update the records on the external DNS server by using a standard dynamic DNS update mechanism secured with the Transaction Signature (TSIG) protocol or the GSS algorithm for TSIG (GSS-TSIG).

IdM now generates SHA-256 certificate and public key fingerprints

Previously, Identity Management (IdM) used the MD5 hash algorithm when generating fingerprints for certificates and public keys. To increase security, IdM now uses the SHA-256 algorithm in the mentioned scenario. (BZ#1444937)

IdM supports flexible mapping mechanisms for linking smart card certificates to user accounts

Previously, the only way to find a user account corresponding to a certain smart card in Identity Management (IdM) was to provide the whole smart card certificate as a Base64-encoded DER string. With this update, it is possible to find a user account also by specifying attributes of the smart card certificates, not just the certificate string itself. For example, the administrator can now define matching and mapping rules to link smart card certificates issued by a certain certificate authority (CA) to a user account in IdM.

New user-space tools enable a more convenient LMDB debugging

This update introduces the mdb_copy, mdb_dump, mdb_load, and mdb_stat tool in the /usr/libexec/openldap/ directory. The addition includes relevant man pages in the man/man1 subdirectory. Use the new tools only to debug problems related to the Lightning Memory-Mapped Database (LMDB) back end. (BZ#1428740)

openldap rebased to version 2.4.44

The openldap packages have been upgraded to upstream version 2.4.44, which provides a number of bug fixes and enhancements over the previous version. In particular, this new version fixes many replication and Lightning Memory-Mapped Database (LMDB) bugs. (BZ#1386365)

Improved security of DNS lookups and robustness of service principal lookups in Identity Management

The Kerberos client library no longer attempts to canonicalize host names when issuing ticket-granting server (TGS) requests. This feature improves:
  • Security because DNS lookups, which were previously required during canonicalization, are no longer performed
  • Robustness of service principal lookups in more complex DNS environments, such as clouds or containerized applications
Make sure you specify the correct fully qualified domain name (FQDN) in host and service principals. Due to this change in behavior, Kerberos does not attempt to resolve any other form of names in principals, such as short names. (BZ#1404750)

samba rebased to version 4.6.2

The samba packages have been upgraded to version 4.6.2, which provides a number of bug fixes and enhancements over the previous version:
  • Samba now verifies the ID mapping configuration before the winbindd service starts. If the configuration is invalid, winbindd fails to start. Use the testparm utility to verify your /etc/samba/smb.conf file. For further details, see the IDENTITY MAPPING CONSIDERATIONS section in the smb.conf man page.
  • Uploading printer drivers from Windows 10 now works correctly.
  • Previously, the default value of the rpc server dynamic port range parameter was 1024-1300. With this update, the default has been changed to 49152-65535 and now matches the range used in Windows Server 2008 and later. Update your firewall rules if necessary.
  • The net ads unregister command can now delete the DNS entry of the host from the Active Directory DNS zone when leaving the domain.
  • SMB 2.1 leases are now enabled by default in the smb2 leases parameter. SMB leasing enables clients to aggressively cache files.
  • To improve security, the NT LAN manager version 1 (NTLMv1) protocol is now disabled by default. If you require the insecure NTLMv1 protocol, set the ntlm auth parameter in the /etc/samba/smb.conf file to yes.
  • The event subcommand has been added to the ctdb utility for interacting with event scripts.
  • The idmap_hash ID mapping back end is marked as deprecated will be removed in a future Samba version.
  • The deprecated only user and username parameters have been removed.
Samba automatically updates its tdb database files when the smbd, nmbd, or winbind daemon starts. Back up the databases files before starting Samba. Note that Red Hat does not support downgrading tdb database files.
For further information about notable changes, read the upstream release notes before updating. (BZ#1391954)

authconfig can enable SSSD to authenticate users with smart cards

This new feature allows the authconfig command to configure the System Security Services Daemon (SSSD) to authenticate users with smart cards, for example:
# authconfig --enablesssd --enablesssdauth --enablesmartcard --smartcardmodule=sssd --smartcardaction=0 --updateall
With this update, smart card authentication can now be performed on systems where pam_pkcs11 is not installed. However, if pam_pkcs11 is installed, the --smartcardmodule=sssd option is ignored. Instead, the first pkcs11_module defined in the /etc/pam_pkcs11/pam_pkcs11.conf is used as default.

authconfig can now enable account locking

This update adds the --enablefaillock option for the authconfig command. When the option is enabled, the configured account will be locked for 20 minutes after four consecutive failed login attempts within a 15-minute interval. (BZ#1334449)

Improved performance of the IdM server

The Identity Management (IdM) server has a higher performance across many of the common workflows and setups. These improvements include:
  • Vault performance has been increased by reducing the round trips within the IdM server management framework.
  • The IdM server management framework has been tuned to reduce the time spent in internal communication and authentication.
  • The Directory Server connection management has been made more scalable with the use of the nunc-stans framework.
  • On new installations, the Directory Server now auto-tunes the database entry cache and the number of threads based on the hardware resources of the server.
  • The memberOf plug-in performance has been improved when working with large or nested groups. (BZ#1395940, BZ#1425906, BZ#1400653)

The default session expiration period in the IdM web UI has changed

Previously, when the user logged in to the Identity Management (IdM) web UI using a user name and password, the web UI automatically logged the user out after 20 minutes of inactivity. With this update, the default session length is the same as the expiration period of the Kerberos ticket obtained during the login operation. To change the default session length, use the kinit_lifetime option in the /etc/ipa/default.conf file, and restart the httpd service. (BZ#1459153)

The script now uses instance names to connect to Directory Server instances

The shell script enables you to monitor the Directory Server database and entry cache usage. With this update, the script no longer uses the HOST and PORT environment variables. To support secure binds, the script now reads the Directory Server instance name from the SERVID environment variable and uses it to retrieve the host name, port, and the information if the server requires a secure connection. For example, to monitor the slapd-localhost instance, enter:
SERVID=slapd-localhost INCR=1 BINDDN="cn=Directory Manager" BINDPW="password"

Directory Server now uses the SSHA_512 password storage scheme as default

Previously, Directory Server used the weak 160-bit salted secure hash algorithm (SSHA) as default password storage scheme set in the passwordStorageScheme and nsslapd-rootpwstoragescheme parameters in the cn=config entry. To increase security, the default of both parameters has been changed to the strong 512-bit SSHA scheme (SSHA_512).
The new default is used:
  • When performing new Directory Server installations.
  • When the passwordStorageScheme parameter is not set, and you are updating passwords stored in userPassword attributes.
  • When the nsslapd-rootpwstoragescheme parameter is not set, and you are updating the Directory Server manager password set in the nsslapd-rootpw attribute. (BZ#1425907)

Directory Server now uses the tcmalloc memory allocator

Red Hat Directory Server now uses the tcmalloc memory allocator. The previously used standard glibc allocator required more memory, and in certain situations, the server could run out of memory. Using the tcmalloc memory allocator, Directory Server now requires less memory, and the performance increased. (BZ#1426275)

Directory Server now uses the nunc-stans framework

The nunc-stans event-based framework has been integrated into Directory Server. Previously, the performance could be slow when many simultaneous incoming connections were established to Directory Server. With this update, the server is able to handle a significantly larger number of connections without performance degradation. (BZ#1426278, BZ#1206301, BZ#1425906)

Improved performance of the Directory Server memberOf plug-in

Previously, when working with large or nested groups, plug-in operations could take a long time. With this update, the performance of the Red Hat Directory Server memberOf plug-in has been improved. As a result, the memberOf plug-in now adds and removes users faster from groups. (BZ#1426283)

Directory Server now logs severity levels in the error log file

Directory Server now logs severity levels in the /var/log/dirsrv/slapd-instance_name/errors log file. Previously, it was difficult to distinguish the severity of entries in the error log file. With this enhancement, administrators can use the severity level to filter the error log.
For further details, see the corresponding section in the Red Hat Directory Server Configuration, Command, and File Reference: (BZ#1426289)

Directory Server now supports the PBKDF2_SHA256 password storage scheme

To increase security, this update adds the 256-bit password-based key derivation function 2 (PBKDF2_SHA256) to the list of supported password-storage schemes in Directory Server. The scheme uses 30,000 iterations to apply the 256-bit secure hash algorithm (SHA256).
Note that the network security service (NSS) database in Red Hat Enterprise Linux prior to version 7.4 does not support PBKDF2. Therefore, you cannot use this password scheme in a replication topology with previous Directory Server versions. (BZ#1436973)

Improved auto-tuning support in Directory Server

Previously, you had to monitor the databases and manually tune settings to improve the performance. With this update, Directory Server supports optimized auto-tuning for:
  • The database and entry cache
  • The number of threads created
Directory Server tunes these settings, based on the hardware resources of the server.
Auto-tuning is now automatically enabled by default if you install a new Directory Server instance. On instances upgraded from earlier versions, Red Hat recommends to enable auto-tuning. For details, see:

New PKI configuration parameter allows control of the TCP keepalive option

This update adds the tcp.keepAlive parameter to the CS.cfg configuration file. This parameter accepts boolean values, and is set to true by default. Use this parameter to configure the TCP keepalive option for all LDAP connections created by the PKI subsystem. This option is useful in cases where certificate issuance takes a very long time and connections are being closed automatically after being idle for too long. (BZ#1413132)

PKI Server now creates PKCS #12 files using strong encryption

When generating PKCS #12 files, the pki pkcs12 command previously used the PKCS #12 deprecated key derivation function (KDF) and the triple DES (3DES) algorithm. With this update, the command now uses the password-based encryption standard 2 (PBES2) scheme with the password-based key derivation function 2 (PBKDF2) and the Advanced Encryption Standard (AES) algorithm to encrypt private keys. As a result, this enhancement increases the security and complies the Common Criteria certification requirements. (BZ#1426754)

CC-compliant algorithms available for encryption operations

Common Criteria requires that encryption and key-wrapping operations are performed using approved algorithms. These algorithms are specified in section FCS_COP.1.1(1) in the Protection Profile for Certification Authorities. This update modifies encryption and decryption in the KRA to use approved AES encryption and wrapping algorithms in the transport and storage of secrets and keys. This update required changes in both the server and client software. (BZ#1445535)

New options to allow configuring visibility of menu items in the TPS interface

Previously, menu items grouped under the System menu in the Token Processing System (TPS) user interface were determined statically based on user roles. In certain circumstances, the displayed menu items did not match components actually accessible by the user. With this update, the System menu in the TPS user interface only displays menu items based on the target.configure.list parameter for TPS administrators, and the target.agent_approve.list parameter for TPS agents. These parameters can be modified in the instance CS.cfg file to match accessible components. (BZ#1391737)

Added a profile component to copy certificate Subject Common Name to the Subject Alternative Name extension

Some TLS libraries now warn or refuse to validate DNS names when the DNS name only appears in the Subject Common Name (CN) field, which is a practice that was deprecated by RFC 2818. This update adds the CommonNameToSANDefault profile component, which copies the Subject Common Name to the Subject Alternative Name (SAN) extension, and ensures that certificates are compliant with current standards. (BZ#1305993)

New option to remove LDAP entries before LDIF import

When migrating a CA, if an LDAP entry existed before the LDIF import, then the entry was not recreated from the LDAP import, causing some fields to be missing. Consequently, the request ID showed up as undefined. This update adds an option to remove the LDAP entry for the signing certificate at the end of the pkispawn process. This entry is then re-created in the subsequent LDIF import. Now, the request ID and other fields show up correctly if the signing entry is removed and re-added in the LDIF import. The correct parameters to add are (X represents the serial number of the signing certificate being imported, in decimal):

Certificate System now supports externally authenticated users

Previously, you had to create users and roles in Certificate System. With this enhancement, you can now configure Certificate System to admit users authenticated by an external identity provider. Additionally, you can use realm-specific authorization access control lists (ACLs). As a result, it is no longer necessary to create users in Certificate System. (BZ#1303683)

Certificate System now supports enabling and disabling certificate and CRL publishing

Prior to this update, if publishing was enabled in a certificate authority (CA), Certificate System automatically enabled both certificate revocation list (CRL) and certificate publishing. Consequently, on servers that did not have certificate publishing enabled, error messages were logged. Certificate System has been enhanced, and now supports enabling and disabling certificate and CRL publishing independently in the /var/lib/pki/<instance>/ca/conf/CS.cfg file.
To enable or disable both certificate and CRL publishing, set:
ca.publish.enable = True|False
To enable only CRL publishing, set:
ca.publish.enable = True
ca.publish.cert.enable = False
To enable only certificate publishing, set:
ca.publish.enable = True
ca.publish.crl.enable = False

The searchBase configuration option has been added to the DirAclAuthz PKI Server plug-in

To support reading different sets of authorization access control lists (ACL), the searchBase configuration option has been added to the DirAclAuthz PKI Server plug-in. As a result, you can set the sub-tree from which the plug-in loads ACLs. (BZ#1388622)

For better performance, Certificate System now supports ephemeral

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, storing the state is not required. To improve performance, you can now set the kra.ephemeralRequests=true option in the /var/lib/pki/<instance>/kra/conf/CS.cfg file to no longer store requests in the LDAP back end. (BZ#1392068)

Section headers in PKI deployment configuration file are no longer case sensitive

The section headers (such as [Tomcat]) in the PKI deployment configuration file were previously case-sensitive. This behavior increased the chance of an error while providing no benefit. Starting with this release, section headers in the configuration file are case-insensitive, reducing the chance of an error occurring. (BZ#1447144)

Certificate System now supports installing a CA using HSM on FIPS-enabled Red Hat Enterprise Linux

During the installation of a Certificate System Certificate Authority (CA) instance, the installer needs to restart the instance. During this restart, instances on an operating system having the Federal Information Processing Standard (FIPS) mode enabled and using a hardware security module (HSM), need to connect to the non-secure HTTP port instead of the HTTPS port. With this update, it is now possible to install a Certificate System instance on FIPS-enabled Red Hat Enterprise Linux using an HSM. (BZ#1450143)

CMC requests now use a random IV for AES and 3DES encryption

With this update, Certificate Management over CMS (CMC) requests in PKI Server use a randomly generated initialization vector (IV) when encrypting a key to be archived. Previously, the client and server code used a fixed IV in this scenario. The CMC client code has been enhanced, and as a result, using random IVs increase security when performing encryption for both Advanced Encryption Standard (AES) and Triple Data Encryption Algorithm (3DES). (BZ#1458055)