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 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.
- 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 authparameter have been extended. The parameter now accepts the
disabledoptions. Additionally, the default value was renamed from
smbclientutility 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 protocolparameter 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
Samba automatically updates its tdb database files when the
winbinddaemon 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_groupsoption in the LDAP provider section in the
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)
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
pwdhashutility uses the storage scheme set in the
nsslapd-rootpwstorageschemeattribute in the
cn=configentry, if you run
pwdhashas a user with read permissions on the
/etc/dirsrv/slapd-instance_name/dse.ldiffile. 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-replcheckutility 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.
For further details, see https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/comparing_two_directory_server_databases. (BZ#1406351)
Directory Server now supports enabling the
memberOf plug-in on read-only replicas
If you previously enabled the
memberOfplug-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
memberOfattribute 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.
For further details, see https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/advanced_entry_management#considerations_when_using_the_memberof_plug-in. (BZ#1352121)
Directory Server rebased to version 188.8.131.52
The 389-ds-base packages have been upgraded to upstream version 184.108.40.206, 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:
Directory Server supports additional password storage schemes
For compatibility reasons, this update adds support for the following weak password storage schemes to Directory Server:
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
pki-corepackages 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
UniqueKeyConstraintenhanced profile constraint, which has also been updated to disallow renewal of a key shared by a revoked certificate. Additionally, it preserves the
origNotAfterattribute 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
origNotAfterattribute, it is not overwritten in this process in order to not interfere with the existing
renewal by serialflow. Additionally, the
caFullCMCUserSignedCert.cfgprofile has been updated to contain both the
RenewGracePeriodConstraint, which must be placed in the correct order. Note that by default, the
allowSameKeyRenewalparameter is set to
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
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:
Note that the default algorithm is still SHA1. Therefore, existing profiles will not automatically be updated. (BZ#1024558)
pki command-line interface automatically creates a default NSS database
pkicommand-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,
pkidisplayed 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. For details, see https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html/administration_guide/configuring-ciphers.
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
nextUpdatefield 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)