Chapter 24. Authentication and Interoperability The IdM LDAP server no longer becomes unresponsive when resolving an AD user takes a long time When the System Security Services Daemon (SSSD) took a long time to resolve a user from a trusted Active Directory (AD) domain on the Identity Management (IdM) server, the IdM LDAP server sometimes exhausted its own worker threads. Consequently, the IdM LDAP server was unable to respond to further requests from SSSD clients or other LDAP clients. This update adds a new API to SSSD on the IdM server, which enables identity requests to time out. Also, the IdM LDAP extended identity operations plug-in and the Schema Compatibility plug-in now support this API to enable canceling requests that take too long. As a result, the IdM LDAP server can recover from the described situation and keep responding to further requests. (BZ# 1415162 , BZ# 1473571 , BZ# 1473577 ) Application configuration snippets in /etc/krb5.conf.d/ are now automatically read in existing configurations Previously, Kerberos did not automatically add support for the /etc/krb5.conf.d/ directory to existing configurations. Consequently, application configuration snippets in /etc/krb5.conf.d/ were not read unless the user added the include statement for the directory manually. This update modifies existing configurations to include the appropriate includedir line pointing to /etc/krb5.conf.d/ . As a result, applications can rely on their configuration snippets in /etc/krb5.conf.d . Note that if you manually remove the includedir line after this update, successive updates will not add it again. (BZ# 1431198 ) pam_mkhomedir can now create home directories under / Previously, the pam_mkhomedir module was unable to create subdirectories under the / directory. Consequently, when a user with a home directory in a non-existent directory under / attempted to log in, the attempt failed with this error: This update fixes the described problem, and pam_mkhomedir is now able to create home directories in this situation. Note that even after applying this update, SELinux might still prevent pam_mkhomedir from creating the home directory, which is the expected SELinux behavior. To ensure pam_mkhomedir is allowed to create the home directory, modify the SELinux policy using a custom SELinux module, which enables the required paths to be created with the correct SELinux context. (BZ#1509338) Kerberos operations depending on KVNO in the keytab file no longer fail when a RODC is used The adcli utility did not handle the key version number (KVNO) properly when updating Kerberos keys on a read-only domain controller (RODC). Consequently, some operations, such as validating a Kerberos ticket, failed because no key with a matching KVNO was found in the keytab file. With this update, adcli detects if a RODC is used and handles the KVNO accordingly. As a result, the keytab file contains the right KVNO, and all Kerberos operations depending on this behavior work as expected. (BZ# 1471021 ) krb5 properly displays errors about PKINIT misconfiguration in single-realm KDC environments Previously, when Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) was misconfigured, the krb5 package did not report the incorrect configuration to the administrator. For example, this problem occurred when the deprecated pkinit_kdc_ocsp option was specified in the /etc/krb5.conf file. With this update, krb5 exposes PKINIT initialization failures when only one realm is specified in the Kerberos key distribution center (KDC). As a result, single-realm KDCs report PKINIT misconfiguration properly. (BZ#1460089) Certificate System no longer incorrectly logs ROLE_ASSUME audit events Previously, Certificate System incorrectly generated the ROLE_ASSUME audit event for certain operations even if no privileged access occurred for a user. Consequently, the event was incorrectly logged. The problem has been fixed and ROLE_ASSUME events are no longer logged in the mentioned scenario. (BZ# 1461524 ) Updated attributes in CERT_STATUS_CHANGE_REQUEST_PROCESSED audit log event Previously, the CERT_STATUS_CHANGE_REQUEST_PROCESSED audit event in log files contained the following attributes: ReqID - The requester ID SubjectID - The subject ID of the certificate For consistency with other audit events, the attributes have been modified and now contain the following information: ReqID - The request ID SubjectID - The requester ID (BZ# 1461217 ) Signed audit log verification now works correctly Previously, due to improper logging system initialization and incorrect signature calculation by the verification tool, signed audit log verification could fail on the first log entry and after log rotation. With this update, the logging system and the verification tool have been fixed. As a result, signed audit log verification now works correctly in the mentioned scenarios. (BZ# 1404794 ) Certificate System now validates the banner file A version of Certificate System introduced a configurable access banner - a custom message to be displayed in the PKI console at the start of every secure session. The contents of this banner were not validated, which could cause a JAXBUnmarshalException error if the message contained invalid UTF-8 characters. With this update, the contents of the banner file are validated both on server startup and on client requests. If the file is found to contain invalid UTF-8 characters on server startup, the server will not start. If invalid characters are found when a client requests the banner, the server will return an error message and not send the banner to the client. (BZ#1446579) The TPS subsystem no longer fails when performing a symmetric key changeover on a HSM Previously, attempting to perform a symmetric key changeover with the master key on a Hardware Security Module (HSM) token failed with an error reported by the Certificate System Token Processing System (TPS) subsystem. This update fixes the way the master key on a HSM is used to calculate the new key set, allowing the TPS to successfully upgrade a token key set when the master resides on a HSM. The fix is currently verified with the G&D SmartCafe 6.0 HSM. (BZ#1465142) Certificate System CAs no longer display an error when handing subject DNs without a CN component Previously, an incoming request missing the Common Name (CN) component caused a NullPointerException on the Certificate Authority (CA) because the implementation expected the CN to be present in the subject Distinguished Name (DN) of the Certificate Management over CMS (CMC). This update allows the CA to handle subject DN without a CN component, preventing the exception from being thrown. (BZ# 1474658 ) The pki-server-upgrade utility no longer fails if target files are missing A bug in the pki-server-upgrade utiltiy caused it to attempt to locate a non-existent file. As a consequence, the upgrade process failed to complete, and could possibly leave the PKI deployment in an invalid state. With this update, pki-server-upgrade has been modified to correctly handle cases where target files are missing, and PKI upgrades now work correctly. (BZ# 1479663 ) The Certificate System CA key replication now works correctly A update to one of the key unwrapping functions introduced a requirement for a key usage parameter which was not being supplied at the call site, which caused lightweight Certiciate Authority (CA) key replication to fail. This bug has been fixed by modifying the call site so that it supplies the key usage parameter, and lightweight CA key replication now works as expected. (BZ# 1484359 ) Certificate System no longer fails to import PKCS #12 files An earlier change to PKCS #12 password encoding in the Network Security Services (NSS) caused Certificate System to fail to import PKCS #12 files. As a consequence, the Certificate Authority (CA) clone installation could not be completed. With this update, PKI will retry a failed PKCS #12 decryption with a different password encoding, which allows it to import PKCS #12 files produced by both old and new versions of NSS, and CA clone installation succeeds. (BZ# 1486225 ) The TPS user interface now displays the token type and origin fields Previously, the tps-cert-find and tps-cert-show Token Processing System (TPS) user interface utilites did not display the token type and origin fields which were present in the legacy TPS interface. The interface has been updated and now displays the missing information. (BZ#1491052) Certificate System issued certificates with an expiration date later than the expiration date of the CA certificate Previously, when signing a certificate for an external Certificate Authority (CA), Certificate System used the ValidityConstraint plug-in. Consequently, it was possible to issue certificates with a later expiry date than the expiry date of the issuing CA. This update adds the CAValidityConstraint plug-in to the registry so that it becomes available for the enrollment profiles. In addition, the ValidityConstraint plug-in in the caCMCcaCert profile has been replaced with the CAValidityConstraint plug-in which effectively sets the restrictions. As a result, issuing certificates with an expiry date later than the issuing CA is no longer allowed. (BZ# 1518096 ) CA certificates without SKI extension no longer causes issuance failures A update of Certificate System incorrectly removed a fallback procedure, which generated the Issuer Key Identifier. Consequently, the Certificate Authority (CA) failed to issue certificates if the CA signing certificate does not have the Subject Key Identifier (SKI) extension set. With this update, the missing procedure has been added again. As a result, issuing certificates no longer fails if the CA signing certificate does not contain the SKI extension. (BZ# 1499054 ) Certificate System correctly logs the user name in CMC request audit events Previously, when Certificate System received a Certificate Management over CMS (CMC) request, the server logged an audit event with the SubjectID field set to USDNonRoleUserUSD . As a result, administrators could not verify who issued the request. This update fixes the problem, and Certificate System now correctly logs the user name in the mentioned scenario. (BZ# 1506819 ) The Directory Server trivial word check password policy now works as expected Previously, when you set a userPassword attribute to exactly the same value as an attribute restricted by the passwordTokenMin setting with the same length, Directory Server incorrectly allowed the password update operation. With this update, the trivial word check password policy feature now correctly verifies the entire user attribute value as a whole, and the described problem no longer occurs. (BZ# 1517788 ) The pkidestroy utility now fully removes instances that are started by the pki-tomcatd-nuxwdog service Previously, the pkidestroy utility did not remove Certificate System instances that used the pki-tomcatd-nuxwdog service as a starting mechanism. As a consequence, administrators had to migrate pki-tomcatd-nuxwdog to the service without watchdog before using pkidestroy to fully remove an instance. The utility has been updated, and instances are correctly removed in the mentioned scenario. Note that if you manually removed the password file before running pkidestroy , the utility will ask for the password to update the security domain. (BZ# 1498957 ) The Certificate System deployment archive file no longer contains passwords in plain text Previously, when you created a new Certificate System instance by passing a configuration file with a password in the [DEFAULT] section to the pkispawn utility, the password was visible in the archived deployment file. Although this file has world readable permissions, it is contained within a directory that is only accessible by the Certificate Server instance user, which is pkiuser , by default. With this update, permissions on this file have been restricted to the Certificate Server instance user, and pkispawn now masks the password in the archived deployment file. To restrict access to the password on an existing installation, manually remove the password from the /etc/sysconfig/pki/tomcat/<instance_name>/<subsystem>/deployment.cfg file, and set the file's permissions to 600 . (BZ# 1532759 ) ACIs with the targetfilter keyword work correctly Previously, if an Access Control Instruction (ACI) in Directory Server used the targetfilter keyword, searches containing the geteffective rights control returned before the code was executed for template entries. Consequently, the GetEffectireRights() function could not determine the permissions when creating entries and returned false-negative results when verifying an ACI. With this update, Directory Server creates a template entry based on the provided geteffective attribute and verifies access to this template entry. As a result, ACIs in the mentioned scenario work correctly. (BZ# 1459946 ) Directory Server searches with a scope set to one have been fixed Due to a bug in Directory Server, searches with a scope set to one returned all child entries instead of only the ones that matched the filter. This update fixes the problem. As a result, searches with scope one only return entries which are matching the filter. (BZ# 1511462 ) Clear error message when sending TLS data to a non-LDAPS port Previously, Directory Server decoded TLS protocol handshakes sent to a port that was configured to use plain text as an LDAPMessage data type. However, decoding failed and the server reported the misleading BER was 3 bytes, but actually was <greater> error. With this update, Directory Server detects if TLS data is sent to a port configured for plain text and returns the following error message to the client: As a result, the new error message indicates that an incorrect client configuration causes the problem. (BZ# 1445188 ) Directory Server no longer logs an error if not running the cleanallruv task After removing a replica server from an existing replication topology without running the cleanallruv task, Directory Server previously logged an error about not being able to replace referral entries. This update adds a check for duplicate referrals and removes them. As a result, the error is no longer logged. (BZ# 1434335 ) Using a large number of CoS templates no longer slow down the virtual attribute processing time Due to a bug, using a large number of Class of Service (CoS) templates in Directory Server increased the virtual attribute processing time. This update improves the structure of the CoS storage. As a result, using a large number of CoS templates no longer increases the virtual attribute processing time. (BZ# 1523183 ) Directory Server now handles binds during an online initialization correctly During an online initialization from one Directory Server master to another, the master receiving the changes is temporarily set into a referral mode. While in this mode, the server only returns referrals. Previously, Directory Server incorrectly generated these bind referrals. As a consequence, the server could terminate unexpectedly in the mentioned scenario. With this update, the server correctly generates bind referrals. As a result, the server now correctly handles binds during an online initialization. (BZ# 1483681 ) The dirsrv@.service meta target is now linked to multi-user.target Previously, the dirsrv@.service meta target had the Wants parameter set to dirsrv.target in its systemd file. When you enabled dirsrv@.service , this correctly enabled the service to the dirsrv.target , but dirsrv.target was not enabled. Consequently, Directory Server did not start when the system booted. With this update, the dirsrv@.service meta target is now linked to multi-user.target . As a result, when you enable dirsrv@.service , Directory Server starts automatically when the system boots. (BZ# 1476207 ) The memberOf plug-in now logs all update attempts of the memberOf attribute In certain situations, Directory Server fails to update the memberOf attribute of a user entry. In this case, the memberOf plug-in logs an error message and forces the update. In the Directory Server version, the second try was not logged if it was successful. Consequently, the log entries were misleading, because only the failed attempt was logged. With this update, the memberOf plug-in also logs the successful update if the first try failed. As a result, the plug-in now logs the initial failure, and the subsequent successful retry as well. (BZ# 1533571 ) The Directory Server password policies now work correctly Previously, subtree and user password policies did not use the same default values as the global password policy. As a consequence, Directory Server incorrectly skipped certain syntax checks. This bug has been fixed. As a result, the password policy features work the same for the global configuration and the subtree and user policies. (BZ# 1465600 ) A buffer overflow has been fixed in Directory Server Previously, if you configured an attribute to be indexed and imported an entry that contained a large binary value into this attribute, the server terminated unexpectedly due to an buffer overflow. The buffer has been fixed. As a result, the server works as expected in the mentioned scenario. (BZ# 1498980 ) Directory Server now sends the password expired control during grace logins Previously, Directory Server did not send the expired password control when an expired password had grace logins left. Consequently, clients could not tell the user that the password was expired or how many grace logins were left. The problem has been fixed. As a result, clients can now tell the user if a password is expired and how many grace logins remain. (BZ# 1464505 ) An unnecessary global lock has been removed from Directory Server Previously, when the memberOf plug-in was enabled and users and groups were stored in separate back ends, a deadlock could occur. An unnecessary global lock has been removed and, as a result, the deadlock no longer occurs in the mentioned scenario. (BZ# 1501058 ) Replication now works correctly with TLS client authentication and FIPS mode enabled Previously, if you used TLS client authentication in a Directory Server replication environment with Federal Information Processing Standard (FIPS) mode enabled, the internal Network Security Services (NSS) database token differed from a token on a system with FIPS mode disabled. As a consequence, replication failed. The problem has been fixed, and as a result, replication agreements with TLS client authentication now work correctly if FIPS mode is enabled. (BZ# 1464463 ) Directory Server now correctly sets whether virtual attributes are operational The pwdpolicysubentry subtree password policy attribute in Directory Server is flagged as operational. However, in the version of Directory Server, this flag was incorrectly applied to following virtual attributes that were processed. As a consequence, the search results were not visible to the client. With this update, the server now resets the attribute before processing the virtual attribute and Class of Service (CoS). As a result, the expected virtual attributes and CoS are now returned to the client. (BZ# 1453155 ) Backup now succeeds if replication was enabled and a changelog file existed Previously, if replication was enabled and a changelog file existed, performing a backup on this master server failed. This update sets the internal options for correctly copying a file. As a result, creating a backup now succeeds in the mentioned scenario. (BZ# 1476322 ) Certificate System updates the revocation reason correctly Previously, if a user temporarily lost a smart card token, the administrator of a Certificate System Token Processing System (TPS) in some cases changed the status of the certificate from on hold to permanently lost or damaged . However, the new revocation reason did not get reflected on the CA. With this update, it is possible to change a certificate status from on hold directly to revoked . As a result, the revocation reason is updated correctly. (BZ#1500474) A race condition has been fixed in the Certificate System clone installation process In certain situations, a race condition arose between the LDAP replication of security domain session objects and the execution of an authenticated operation against a clone other than the clone where the login occurred. As a consequence, cloning a Certificate System installation failed. With this update, the clone installation process now waits for the security domain login to finish before it enables the security domain session objects to be replicated to other clones. As a result, the clone installation no longer fails. (BZ#1402280) Certificate System now uses strong ciphers by default With this update, the list of enabled ciphers has been changed. By default, only strong ciphers, which are compliant with the Federal Information Processing Standard (FIPS), are enabled in Certificate System. RSA ciphers enabled by default: TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA Note that the TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA ciphers need to be enabled to enable the pkispawn utility to connect to the LDAP server during the installation and configuration. ECC ciphers enabled by default: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 In addition, the default ranges of the sslVersionRangeStream and sslVersionRangeDatagram parameters in the /var/lib/pki/<instance_name>/conf/server.xml file now use only TLS 1.1 and TLS 1.2 ciphers. (BZ# 1539125 ) The pkispawn utility no longer displays incorrect errors Previously, during a successful installation of Certificate System, the pkispawn utility incorrectly displayed errors related to deleting temporary certificates. The problem has been fixed, and the error messages no longer display if the installation succeeds. (BZ# 1520277 ) The Certificate System profile configuration update method now correctly handles backslashes Previously, a parser in Certificate System removed backslash characters from the configuration when a user updated a profile. As a consequence, affected profile configurations could not be correctly imported, and issuing certificates failed or the system issued incorrect certificates. Certificate System now uses a parser that handles backslashes correctly. As a result, profile configuration updates import the configuration correctly. (BZ# 1541853 )

Commands:
Unable to create and initialize directory '/<directory_path>'.
Incoming BER Element may be misformed. This may indicate an attempt to use TLS on a plaintext port, IE ldaps://localhost:389. Check your client LDAP_URI settings.