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-servercontainer image is still a Technology Preview feature.
For details, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/using_containerized_identity_management_services. (BZ#1467260)
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.
For further details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#prerequisites. (BZ#1125174)
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.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sc-pkinit-auth.html. (BZ#1200767, BZ#1405075)
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.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html. (BZ#1340711, BZ#1402959)
IdM web UI enables smart card login
The Identity Management web UI enables users to log in using smart cards.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sc-web-ui-auth.html. (BZ#1366572)
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
httpdauthentication modules when registering as a Red Hat Single Sign-On (RH-SSO, also called Keycloak) federated Identity Provider (IdP) client.
For details on RH-SSO, see https://access.redhat.com/products/red-hat-single-sign-on.
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.
kcmservice 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-kcmservice 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
kcmservice runs in user space outside the kernel, unlike the KEYRING credential cache type that RHEL uses by default. With KCM, you can run the
kcmservice 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
kinitutility 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.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/using-the-ui.html#ad-users-idm-web-ui. (BZ#872671)
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.conffile with a name that follows this template:
For example, if the main IdM domain name is ipa.com and the trusted AD domain name is ad.com, 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_orderoption in the
[sssd]section of the
- By using an ID view
- Globally, in the IdM configuration
To disable the feature, set the
[domain/example.com]section of the
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
sssctlutility now includes a new command named
sssctl user-checkscommand helps debug problems in applications that use the System Security Services Daemon (SSSD) as a back end for user lookup, authentication, and authorization.
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-authpluggable authentication module (PAM) service.
- Additional options accepted by
sssctl user-checkscheck authentication or different PAM services.
For details on
sssctl user-checks, use the
sssctl user-checks --helpcommand. (BZ#1414023)
Support for secrets as a service
This update adds a responder named
secretsto 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
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).
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/dns-updates-external.html. (BZ#1409628)
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.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html#sc-one-card-multiple-accounts-links. (BZ#1402959)
New user-space tools enable a more convenient LMDB debugging
This update introduces the
mdb_stattool in the
/usr/libexec/openldap/directory. The addition includes relevant man pages in the
man/man1subdirectory. 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
winbinddservice starts. If the configuration is invalid,
winbinddfails to start. Use the
testparmutility to verify your
/etc/samba/smb.conffile. For further details, see the
IDENTITY MAPPING CONSIDERATIONSsection in the
- Uploading printer drivers from Windows 10 now works correctly.
- Previously, the default value of the
rpc server dynamic port rangeparameter was
1024-1300. With this update, the default has been changed to
49152-65535and now matches the range used in Windows Server 2008 and later. Update your firewall rules if necessary.
net ads unregistercommand 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 leasesparameter. 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 authparameter in the
eventsubcommand has been added to the
ctdbutility for interacting with event scripts.
idmap_hashID mapping back end is marked as deprecated will be removed in a future Samba version.
- The deprecated
usernameparameters have been removed.
Samba automatically updates its tdb database files when the
winbinddaemon 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
authconfigcommand 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_pkcs11is not installed. However, if
pam_pkcs11is installed, the
--smartcardmodule=sssdoption is ignored. Instead, the first pkcs11_module defined in the
/etc/pam_pkcs11/pam_pkcs11.confis used as default.
For details, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/auth-idm-client-sc.html. (BZ#1378943)
authconfig can now enable account locking
This update adds the
--enablefaillockoption for the
authconfigcommand. 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
- 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 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_lifetimeoption in the
/etc/ipa/default.conffile, and restart the
dbmon.sh script now uses instance names to connect to Directory Server instances
dbmon.shshell script enables you to monitor the Directory Server database and entry cache usage. With this update, the script no longer uses the
PORTenvironment variables. To support secure binds, the script now reads the Directory Server instance name from the
SERVIDenvironment 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
SERVID=slapd-localhost INCR=1 BINDDN="cn=Directory Manager" BINDPW="password" dbmon.sh
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
nsslapd-rootpwstorageschemeparameters in the
cn=configentry. 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
passwordStorageSchemeparameter is not set, and you are updating passwords stored in
- When the
nsslapd-rootpwstorageschemeparameter is not set, and you are updating the Directory Server manager password set in the
Directory Server now uses the
tcmalloc memory allocator
Red Hat Directory Server now uses the
tcmallocmemory allocator. The previously used standard
glibcallocator required more memory, and in certain situations, the server could run out of memory. Using the
tcmallocmemory allocator, Directory Server now requires less memory, and the performance increased. (BZ#1426275)
Directory Server now uses the
nunc-stansevent-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
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
memberOfplug-in has been improved. As a result, the
memberOfplug-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/errorslog 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: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/error-logs.html#error-logs-content (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:
- Directory Server threads: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Performance_Tuning_Guide/ds-threads (BZ#1426286)
New PKI configuration parameter allows control of the TCP
This update adds the
tcp.keepAliveparameter to the
CS.cfgconfiguration file. This parameter accepts boolean values, and is set to
trueby default. Use this parameter to configure the TCP
keepaliveoption 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 pkcs12command 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
Systemmenu 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
Systemmenu in the TPS user interface only displays menu items based on the
target.configure.listparameter for TPS administrators, and the
target.agent_approve.listparameter for TPS agents. These parameters can be modified in the instance
CS.cfgfile 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
CommonNameToSANDefaultprofile 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
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
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
searchBaseconfiguration option has been added to the
DirAclAuthzPKI 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=trueoption in the
/var/lib/pki/<instance>/kra/conf/CS.cfgfile 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)