Red Hat Training

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

Chapter 5. Authentication and Interoperability

Windows Server 2016 forest and domain functional levels now supported for trust

When using Identity Management, you can now establish a supported forest trust to Active Directory forests that run at the Windows Server 2016 forest and domain functional levels. (BZ#1484683)

Directory Server no longer displays replication conflict entries in search results

Previously, if replication conflict entries existed in a replication topology, Directory Server returned them by default as part of the search result. As a consequence, certain LDAP clients behaved incorrectly if the server returned such entries. With this update, the server no longer returns conflict entries in a search and you have to explicitly request them. As a result, clients work as expected.
In addition, the update improves the resolution of more complex conflict scenarios.
For further details, see https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_replication-solving_common_replication_conflicts. (BZ#1274430)

OpenLDAP is now compiled with OpenSSL instead of NSS

Previously, the OpenLDAP suite used the Mozilla implementation of Network Security Services (Mozilla NSS). With this update, OpenLDAP uses the OpenSSL library. Existing certificates in the NSS database (DB) are automatically extracted to the PEM format and passed to OpenSSL.
Note that NSS DBs continue to be supported. However, OpenSSL-like configuration, such as PEM files, is preferred over NSS-like configuration, such as NSS DB. (BZ#1400578)

Samba rebased to version 4.7.1

The samba packages have been upgraded to upstream version 4.7.1, which provides a number of bug fixes and enhancements over the previous version. Notable changes include:
  • 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.
  • Samba now uses the Advanced Encryption Standard (AES) instruction set of Intel CPUs to accelerate Server Message Block (SMB) 3 signing and encryption operations.
  • The options of the ntlm auth parameter have been extended. The parameter now accepts the ntlmv2-only (alias no), ntlmv1-permitted (alias yes), mschapv2-and-ntlmv2-only, and disabled options. Additionally, the default value was renamed from no to ntlmv2-only.
  • The smbclient utility no longer displays a banner with the domain, operating system, and server version when connecting to a server.
  • The default value of the client max protocol parameter has been changed to SMB3_11. This enables utilities, such as smbclient, to connect to servers using the SMB 3.11 protocol without setting the protocol version.
  • For a better interoperability, Samba no longer supports using mixed minor versions in a CTDB cluster.
Samba automatically updates its tdb database files when the smbd, nmbd, or winbind daemon starts. Back up the database 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:

The SSSD LDAP provider can now automatically create user private groups for users

When using the System Security Services Daemon (SSSD) LDAP provider, a user group must be assigned to each user. Previously, the administrator had to create a group for each user manually. With this update, SSSD automatically generates a user private group from the user entry and ensures that the UID and GID match. To activate this feature, enable the auto_private_groups option in the LDAP provider section in the /etc/sssd/sssd.conf file. (BZ#1327705)

SSSD enrolled to an AD domain remembers the discovered AD site after the first successful connection

Previously, the System Security Services Daemon (SSSD) sent an LDAP ping to any Active Directory (AD) domain controller (DC) in order to determine a client's AD site. If the contacted DC was unreachable, a timeout occurred, which delayed the connection for several seconds. With this update, SSSD remembers the client's site after the first successful discovery. All subsequent LDAP pings are performed on the DC from the client's site, which helps speed up the request. (BZ#1400614)

SSSD logs changes in its status to syslog

Previously, the System Security Services Daemon (SSSD) logged information about changing its online or offline status to the SSSD logs only. With this update, the changes in SSSD status are logged also to the syslog service, which improves the availability of the information to system administrators. (BZ#1416150)

SSSD performance has improved

This update provides several performance-related enhancements for the System Security Services Daemon (SSSD). Most notably:
  • Several missing indexes have been added in the SSSD cache, which makes lookups of cached objects faster.
  • Changes to how users and groups are saved prevent the SSSD cache performance degradation that occurred after the cache was populated with a large number of cached objects.
As a result, SSSD reads user and group objects, especially large groups, faster. Also, the SSSD cache performance can now remain stable even when the cache size and the number of cache objects increase. (BZ#1472255, BZ#1482555)

The pwdhash utility can now retrieve the storage scheme from the configuration directory

Previously, if you passed the path to the configuration directory to the pwdhash, the utility used the default storage scheme of Directory Server to encrypt the password. With this update, the pwdhash utility uses the storage scheme set in the nsslapd-rootpwstoragescheme attribute in the cn=config entry, if you run pwdhash as a user with read permissions on the /etc/dirsrv/slapd-instance_name/dse.ldif file. As a result, you no longer have to specify the storage scheme in the mentioned scenario if it differs from the Directory Server's default. (BZ#1467777)

New utility to compare two Directory Server instances

This update adds the ds-replcheck utility to Directory Server. This utility compares the data of two servers in online mode, or two LDIF-formatted files in offline mode. As a result, you can now verify the replication consistency of two Directory Servers.

Directory Server now supports enabling the memberOf plug-in on read-only replicas

If you previously enabled the memberOf plug-in on a read-only Directory Server replica server, the plug-in failed to update member entries. To use the plug-in in a replication topology, you could only enable it on write-enabled servers, and replicate the memberOf attribute to read-only replicas. With this update, you can now alternatively enable the plug-in on all servers. As a result, you can use the plug-in on read-only servers the same as on write-enabled server. (BZ#1352121)

Directory Server rebased to version 1.3.7.5

The 389-ds-base packages have been upgraded to upstream version 1.3.7.5, which provides a number of bug fixes and enhancements over the previous version. For a complete list of notable changes, read the upstream release notes before updating. (BZ#1470169)

Directory Server supports additional password storage schemes

For compatibility reasons, this update adds support for the following weak password storage schemes to Directory Server:
  • CRYPT-MD5
  • CRYPT-SHA256
  • CRYPT-SHA512
For security reasons, use these weak storage schemes only temporary for existing installations and consider migrating to a strong password storage schema. (BZ#1479012)

Directory Server now uses separate normalized DN caches for each worker thread

Previously, multiple worker threads used a single normalized Distinguished Name (DN) cache. Consequently, if multiple clients performed operations on Directory Server, performance decreased. With this update, Directory Server now creates separate normalized DN caches for each worker thread. As a result, performance no longer decreases in the mentioned scenario. (BZ#1458536)

pki-core rebased to version 10.5.1

The pki-core packages have been upgraded to upstream version 10.5.1, which provides a number of bug fixes and enhancements over the previous version. Notably, this update addresses the requirements for the Common Criteria Protection Profile for Certification Authorities Version 2.1. (BZ#1473452)

Certificate System supports installing CA, KRA, and OCSP subsystems with CMC

This enhancement provides a mechanism to install CA, KRA, or OCSP subsystems with Certificate Management over CMS (CMC). The installation will be done in two steps. The first step of the installation will generate the Certificate Signing Requests (CSR) for the system certificates. The CSRs can be used to issue the system certificates using CMC. The second step of the installation will use these system certificates and complete the subsystem installation. (BZ#1464549)

Certificate System supports creating instances running as a different user

Previously, Certificate System only used the systemd unit file from the /usr/lib/systemd/system/ directory to start the service. Consequently, it was not possible to create a server running as a different user or group as pkiuser. The pkispawn utility has been updated. If the configuration file passed to pkispawn contains a different user or group, the utility now creates an override file with the customized values in the /etc/systemd/system/pki-tomcatd@<instance_name>.service.d/user.conf file. As a result, running Certificate System user a different user or group as the default is possible. (BZ#1523410)

Certificate System can now create PKCS #12 files using PBES2 with PBKDF2 key derivation

This update enhances Certificate System and adds support for AES encryption of private keys recovered from the Key Recovery Authority (KRA), when token-based key recovery is disabled. Specifically, when AES encryption is enabled, exported PKCS #12 files containing the recovered key uses the PKCS #5 version 2.0 Password-Based Cryptography Specification version 2 (PBES2) with Password-Based Key Derivation Function 2 (PBKDF2) key derivation and AES 128 encryption. Using PBES2 with PBKDF2 makes the files created by Certificate System more secure. (BZ#1446786)

Certificate System CAs can now process CMC renewal requests signed by a previously issued signing certificate

This update enables the Certificate Authority (CA) to process Certificate Management over CMS (CMC) renewal requests signed by a previously issued signing certificate. The implementation uses the caFullCMCUserSignedCert with the UniqueKeyConstraint enhanced profile constraint, which has also been updated to disallow renewal of a key shared by a revoked certificate. Additionally, it preserves the origNotAfter attribute of the most recent certificate that shares the same key in the request, which allows the attribute to be used by the RenewGracePeriodConstraint. If there is an existing origNotAfter attribute, it is not overwritten in this process in order to not interfere with the existing renewal by serial flow. Additionally, the caFullCMCUserSignedCert.cfg profile has been updated to contain both the UniqueKeyConstraint and the RenewGracePeriodConstraint, which must be placed in the correct order. Note that by default, the allowSameKeyRenewal parameter is set to true in the UniqueKeyConstraint. (BZ#1419761)

Certificate System now uses the Mozilla NSS secure random number generator

With this update, Certificate System uses a secure random number generator provided by the Mozilla Network Security Services (NSS). This enables Red Hat Certificate System to synchronize its Deterministic Random Bit Generator (DRBG) with Red Hat Enterprise Linux as required by the Federal Information Processing Standard (FIPS) standard. (BZ#1452347)

Audit event changes in Certificate System

To provide more concise audit logs in Certificate System, the list of audit events enabled by default has been updated. Additionally, certain events have been merged or renamed.
For a full list of audit events in Red Hat Certificate System, including information in which subsystems they are enabled by default, see https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html/administration_guide/audit_events. (BZ#1445532)

krb5 now includes the kdcpolicy interface

This update introduces the Kerberos key distribution center (KDC) policy interface, known as kdcpolicy, to the krb5 package. Using kdcpolicy, administrators can provide a plug-in to krb5, which enables them to control ticket lifetimes and gives them more fine-grained control on service ticket issuance.
For details, see the MIT Kerberos Documentation: https://web.mit.edu/kerberos/krb5-1.16/doc/plugindev/kdcpolicy.html. (BZ#1462982)

Certificate System now supports configurable hashing algorithms for the SKI extension

Previously, Certificate System only supported the SHA1 hashing algorithm when generating the Subject Key Identifier (SKI) certificate extension. With this update, administrators can now configure the hashing algorithm for the SKI extension in certificate profiles.
The following algorithms are now available:
  • SHA1
  • SHA256
  • SHA384
  • SHA512
Note that the default algorithm is still SHA1. Therefore, existing profiles will not automatically be updated. (BZ#1024558)

The pki command-line interface automatically creates a default NSS database

The pki command-line interface requires a Network Security Services (NSS) database and its password to run operations over SSL connections, including basic authentication using a user name and password. Previously, pki displayed an error if the database did not exist or the database password was not specified. The command-line interface has been updated to automatically create a default NSS database without a password in the ~/.dogtag/nssdb/ directory. As a result, operations over SSL can be executed without specifying an NSS database or password. (BZ#1400645)

Certificate System disables weak 3DES ciphers by default

By default, Certificate System now disables ciphers based on the weak Triple Data Encryption Standard (3DES). This increases the security of the system. However, administrators are able to enable these ciphers again, if needed.
As a result, new Certificate System installations have only strong ciphers enabled by default. (BZ#1469169)

The Certificate System CA subsystem's OCSP provider now includes the nextUpdate field in responses

If the Certificate Authority (CA) is configured to use the Certificate Revocation List (CRL) cache, the CA subsystem's Online Certificate Status Protocol (OCSP) responder now includes the nextUpdate field in OCSP responses. As a result, in such scenarios, clients which conform to the Lightweight OCSP Profile (RFC 5019) are now able to process OCSP responses. (BZ#1523443)

ding-libs rebased to version 0.6.1

The ding-libs packages have been upgraded to version 0.6.1. The most notable change is that ding-libs can now work with much bigger values, because the hard-coded limit to number of characters in values has been removed and the only limitation now is the amount of memory available. (BZ#1480270)