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:
Unable to create and initialize directory '/<directory_path>'.
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 IDSubjectID
- 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 IDSubjectID
- 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 previous 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 previous 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 previous 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 $NonRoleUser$
. 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:
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.
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 previous 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 previous 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 next 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)