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:
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:
New Kerberos credential cache type: KCM
This update adds a new SSSD service named
kcm. The service is included in the sssd-kcm subpackage.
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.
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 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:
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
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/example.com] 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:
SSSD introduces the
sssctl user-checks command, which checks basic SSSD functionality in a single operation
sssctl utility now includes a new command named
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.
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
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
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_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.
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
event subcommand has been added to the
ctdb utility for interacting with event scripts.
idmap_hash ID mapping back end is marked as deprecated will be removed in a future Samba version.
only user and
username parameters have been removed.
Samba automatically updates its tdb database files when the
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
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.
plug-in performance has been improved when working with large or nested groups. (BZ#1395940
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
option in the
file, and restart the
dbmon.sh script now uses instance names to connect to Directory Server instances
dbmon.sh shell script enables you to monitor the Directory Server database and entry cache usage. With this update, the script no longer uses the
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" 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-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.
passwordStorageScheme parameter is not set, and you are updating passwords stored in
parameter 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
memory allocator. The previously used standard
allocator required more memory, and in certain situations, the server could run out of memory. Using the
memory allocator, Directory Server now requires less memory, and the performance increased. (BZ#1426275
Directory Server now uses the
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
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
plug-in has been improved. As a result, the
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.
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:
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
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
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
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
configuration option has been added to the
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
option in the
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
) 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