Ping Identity Directory Server Products Do Not Use log4j
Recently, a very serious security issue (CVE-2021-44228) was identified in the Apache log4j library, which is used by many Java applications to provide logging support. None of the Ping Identity Directory Server, Directory Proxy Server, Synchronization Server, and Metrics Engine products make use of this library in any way, and it is not included as part of the server. Some of the libraries that we include with the server do have support for logging to log4j, but that functionality is not used, and the log4j library is not included as part of the server.
The standalone version of the Admin Console does include the log4j library, but it is included only as a transitive dependency of one of the other libraries used by the console, and the log4j library is not used in any way by the Admin Console. Because this vulnerability was disclosed very late in the release cycle for the Ping Identity server products, we have chosen to update to a non-vulnerable version of the library rather than remove it entirely, as that requires less testing. Again, even though the log4j library is included with the standalone Admin Console, it is not used in any way, so even if you are using an older version of the console with an older version of the log4j library, you are not vulnerable to the security issue.
The UnboundID LDAP SDK for Java does not include any third-party dependencies at all (other than a Java SE runtime environment at Java version 7 or later). It does not include or interact with log4j in any way.
Changes Affecting All Server Products
- Added cipher stream providers for PKCS #11 tokens, Azure Key Vault, and CyberArk Conjur. [more information]
- Added passphrase providers for Azure Key Vault and CyberArk Conjur. [more information]
- Added password storage schemes for authenticating with passwords stored in external services, including AWS Secrets Manager, Azure Key Vault, CyberArk Conjur, and HashiCorp Vault. [more information]
- Added extended operations for managing server certificates. [more information]
- Added the ability to redact the values of sensitive configuration properties when constructing the dsconfig representation for a configuration change. [more information]
- Included the original requester DN and client IP address in log messages for mirrored configuration changes. [more information]
- Added TLS configuration properties for outbound connections. [more information]
- Updated the Admin Console to support using PKCS #12 and BCFKS trust stores.
- Updated the file servlet to support authenticating with OAuth 2.0 access tokens and OpenID Connect ID tokens, which makes it possible to download collect-support-data archives and server profiles generated through the Admin Console when authenticated with SSO.
- Fixed an issue that could cause degraded performance and higher CPU utilization for some clients using TLSv1.3.
- Fixed an issue that prevented the manage-profile replace-profile tool from working properly for servers running in FIPS 140-2-compliant mode.
- Updated export-ldif to always base64-encode attribute values containing any ASCII control characters. Previously, only the null, line feed, and carriage return control characters caused values to be base64-encoded.
- Fixed an issue in which some tools that operate on the server’s configuration did not use the correct matching rule for attribute types configured to use case-sensitive matching. If a config entry had an attribute with multiple values differing only in capitalization, all but one of the values could be lost.
- Updated the Directory REST API to add support for attribute options.
- Added the ability to recognize JVM builds from Eclipse Foundation, Eclipse Adoptium, and BellSoft.
- Removed “-XX:RefDiscoveryPolicy=1” from the default set of options used to launch the JVM. In some cases, this option has been responsible for JVM crashes.
Changes Affecting the Directory Server
- Added support for pluggable pass-through authentication. [more information]
- Fixed an issue that could prevent authenticating with certain types of reversibly encrypted passwords that were encrypted on an instance that was subsequently removed from the topology. [more information]
- Fixed an issue that prevented decoding the value of a proxied authorization v2 request control when the authorization identity had a specific length.
- Fixed an issue that could cause sporadic failures when attempting to back up a backend with data encryption enabled. In such cases, the backup would likely succeed if re-attempted.
- Added a replica-partial-backlog attribute to the replication summary monitor entry to provide information about how each replica contributes to the overall replication backlog.
- Fixed an issue in which the server could use incorrect resource limit values (including size limit, time limit, lookthrough limit, and idle time limit) for users with custom limits who authenticated via pass-through authentication.
- Fixed an issue in which the server did not properly update certain password policy state information for simple bind attempts targeting users without a password.
- Fixed an issue in which the server may not handle other controls properly when processing an operation that includes the join request control. The server may have overlooked a control immediately following the join request control in the operation request, and it may have omitted appropriate non-join result controls from the response.
- Fixed an issue in which a newly initialized server could go into lockdown mode with a warning about missing changes if it was restarted immediately after initialization completed.
- Fixed an issue that could prevent changes applied to non-RDN attributes in the course of processing a modify DN operation from being replicated.
- Fixed an issue that could prevent composed attribute values from being properly updated for operations that are part of a muti-update extended operation.
- Improved performance for modify operations that need to update a composite index to add an entry ID to the middle of a very large ID set.
- Added limits for the maximum number of attributes in an add request and the maximum number of modifications in a modify request. [more information]
- Updated the dsreplication initialize-all command to support initializing multiple replicas in parallel.
- Updated remove-defunct-server to add a --performLocalCleanup option that can be used to remove replication metadata from a server that is offline.
- Added an option to the mirror virtual attribute provider to make it possible to bypass access control evaluation for the internal searches that it performs to retrieve data from other entries.
- Fixed an issue in which an entry added with a createTimestamp attribute could lose the original formatting for that attribute when replicated to other servers.
- Fixed an issue that could lead to long startup times in large topologies with data encryption enabled.
- Updated the ldap-diff tool to add several new features. [more information]
- Updated the migrate-ldap-schema tool to add several new features. [more information]
Changes Affecting the Directory Proxy Server
- Fixed an issue that could cause certain internal operations initiated in the Directory Proxy Server to fail when forwarded to a backend Directory Server whose default password policy was configured in a way that interfered with the account used to authorize internal operations.
- Improved the logic used to select the best error result to return to the client for operations broadcast to all backend sets. Previously, the server could have incorrectly returned a result indicating that the target entry did not exist when the operation failed for some other reason.
- Updated the entry counter, hash DN, and round-robin placement algorithms to support excluding specific backend sets.
Changes Affecting the Synchronization Server
- Added the ability to synchronize certain password policy state information from Active Directory to the Ping Identity Directory Server, including account disabled state and the password changed time.
- Fixed an issue that could prevent synchronizing changes to entries that have multiple attributes with the same base attribute type but different sets of attribute options, particularly if any of the attributes have more values than the replace-all-attr-values limit defined in the associated Sync Class.
- Added the ability to apply rate limiting when synchronizing changes to PingOne.
- Fixed an issue in which the max-rate-per-second property was not properly applied when running the resync tool.
Changes Affecting the Metrics Engine
- Fixed an issue that could prevent dashboard icons from being properly displayed.
New Cipher Stream Providers
The encryption settings database holds a set of definitions that include the keys used for data encryption. The encryption settings database is itself encrypted, and we use a component called a cipher stream provider for reading and writing that encrypted content. We already offered several cipher stream provider implementations, including:
- Generate the encryption key with a passphrase read from a file.
- Generate the encryption key with a passphrase provided interactively during server startup.
- Protect the encryption key with AWS Key Management Service (KMS).
- Generate the encryption key with a passphrase retrieved from AWS Secrets Manager.
- Generate the encryption key with a passphrase retrieved from a HashiCorp Vault instance.
- Use the Server SDK to develop your own custom cipher stream providers.
In the 18.104.22.168 release, we are introducing support for three new types of cipher stream providers:
- Wrap the encryption key with a certificate read from a PKCS #11 token, like a Hardware Security Module (HSM). Note that because of the limitations in Java’s support for key wrapping, only certificates with RSA key pairs can be used for this purpose.
- Generate the encryption key with a passphrase retrieved from Azure Key Vault.
- Generate the encryption key with a passphrase retrieved from a CyberArk Conjur instance.
New Passphrase Providers
Passphrase providers offer a means of obtaining clear-text secrets that the server may need for things like accessing protected content in a certificate key store or authenticating to an external service. We already offered several passphrase provider implementations, including:
- Read the secret from a file, which may optionally be encrypted with a key from the server’s encryption settings database.
- Read the secret from an obscured value stored in the server’s configuration.
- Read the secret from an environment variable.
- Read the secret from AWS Secrets Manager.
- Read the secret from a HashiCorp Vault instance.
- Use the Server SDK to develop your own custom passphrase providers.
In the 22.214.171.124 release, we are introducing support for two new types of passphrase providers:
- Read the secret from Azure Key Vault.
- Read the secret from a CyberArk Conjur instance.
Password Storage Schemes for External Services
Password storage schemes are used to protect passwords held in the server. We already offered a variety of password storage schemes, including:
- Schemes using salted 256-bit, 384-bit, and 512-bit SHA-2 digests. SHA-1 support is also available for legacy purposes, but is not recommended.
- Schemes using more resource-intensive, brute-force-resistant algorithms like PBKDF2, bcrypt, scrypt, and Argon2.
- A scheme that reversibly encrypts passwords with a 256-bit AES key obtained from the encryption settings database.
- Schemes that reversibly encrypt passwords with legacy keys stored in the topology registry.
In the 126.96.36.199 release, we are introducing support for new password storage schemes that allow users to authenticate with passwords stored in external secret stores, including:
- AWS Secrets Manager
- Azure Key Vault
- CyberArk Conjur
- HashiCorp Vault
In these cases, the storage scheme is configured with the information needed to connect and authenticate to the external service, and the encoded representation of the password contains a JSON object with the information needed to identify the specific secret in that service to use as the password for the associated user.
These password storage schemes can be used to authenticate with both LDAP simple authentication and SASL mechanisms that use a password. However, these schemes are read-only: users can authenticate with a password stored in the associated external service, but password changes need to be made through that service rather than over LDAP.
Extended Operations for Certificate Management
We have added support for a set of extended operations that can be used to remotely manage certificates in server instances, including replacing listener and inter-server certificates and purging information about retired certificates from the topology registry. These operations are especially useful for managing certificates in instances running in Docker or in other cases where command-line access may not be readily available to run the replace-certificate tool.
When replacing certificates, the new key store can be obtained in several ways:
- It can be read from a file that is already available to the server (for example, one that has been copied to the server or placed on a shared filesystem).
- The raw bytes that make up the new key store file can be included directly in the extended request.
- The individual certificates and private key can be provided in the extended request, in either PEM or DER form.
Many safeguards are in place to prevent these extended operations from being inappropriately used. These include:
- The extended operation handler providing support for these operations is not enabled by default. It must be enabled before they can be used.
- The extended operations will only be allowed over secure connections.
- The extended operations can only be requested by a user with the permit-replace-certificate-request privilege. No users have this privilege by default (not even root users or topology administrators).
- You can indicate which of the individual types of operations are allowed, and you can define connection and request criteria to further restrict the circumstances under which they may be used.
- By default, it will only allow reading certificates from a file on the server filesystem. You have to specifically enable the option to allow providing the new certificate information from a remote client.
- The server will generate administrative alerts for all successful and failed attempts to process these operations.
These extended operations can be invoked programmatically (support for them is included in the UnboundID LDAP SDK for Java). They can also be used through new subcommands in the replace-certificate command-line tool.
Redacting Sensitive Values in Configuration Changes
We have added a new redact-sensitive-values-in-config-logs global configuration property that can be used to indicate that the server should redact the values of sensitive configuration properties when generating the dsconfig representation for that configuration change, including the representation that is written to the config-audit.log file and included in alerts to notify administrators of the change.
By default, the values of sensitive configuration properties are obscured in a way that allows the server to obtain the clear-text value, but that is not readily apparent to an observer. This helps protect the values of these secrets while still allowing the config-audit.log file to be replayed. However, a determined user with access to this obfuscated representation may be able to determine the clear-text value that it represents.
If the redact-sensitive-values-in-config-logs property is set to true, then the values of sensitive configuration properties will be redacted rather than obscured. This prevents someone with access to the dsconfig representation of the change from being able to obtain the clear-text value of the secret, but it does mean that the config-audit.log file may no longer be replayable.
Original Requester Details for Mirrored Configuration Changes
When making configuration changes, log messages (including those written to the server’s access log and the config-audit.log file) include the DN of the user that requested the change and the IP address of the client system. However, for changes affecting mirrored configuration (including in the topology registry or cluster configuration), these values do not accurately reflect the DN and address of the original requester, but instead reflect either the details of an internal connection or of a connection from another server instance that has forwarded change to the topology master.
To address this, we have updated the server so that the DN and IP address of the original requester are included as part of changes to mirrored configuration. Records for these configuration changes that are written to config-audit.log and the server’s access log will now provide these values in the original-requester-dn and original-requester-ip fields.
New TLS Configuration Properties
We have updated the crypto manager configuration to add support for four new properties for configuring TLS communication:
- outbound-ssl-protocol — Can be used to specify the set of TLS protocols that may be used for outbound connections (e.g., those used for pass-through authentication or for synchronization with remote servers).
- outbound-ssl-cipher-suite — Can be used to specify the set of TLS cipher suites that may be used for outbound connections.
- enable-sha-1-cipher-suites — Can be used to enable the use of TLS cipher suites that rely on the SHA-1 digest algorithm, which is no longer considered secure and is disabled by default.
- enable-rsa-key-exchange-cipher-suites — Can be used to enable the use of TLS cipher suites that rely on the RSA key exchange algorithm, which does not provide support for forward secrecy and is disabled by default.
Pluggable Pass-Through Authentication
We have updated the Directory Server to add support for pluggable pass-through authentication. Previously, the server provided support for passing through simple bind attempts to another LDAP server or to PingOne. It is now possible to support pass-through authentication to other types of services, and the Server SDK has been updated to add support for creating custom pass-through authentication handlers.
This implementation includes an LDAP pass-through authentication handler that allows the new pluggable pass-through authentication plugin to be used as an alternative to the former LDAP-specific pass-through authentication plugin. The new implementation offers several advantages over the former one, including:
- Better default configuration properties (especially for the override-local-password property).
- The ability to indicate whether to attempt pass-through authentication for accounts in an usable password policy state (for example, those that are locked or that have expired passwords).
- The ability to set timeouts for interaction with the external LDAP servers.
- Improved diagnostic information about pass-through authentication attempts, including support for the password policy request control and password expired response control.
- A new monitor entry with metrics about the processing performed by the plugin.
Preserving Secret Keys for Instances Removed From the Topology
Previously, when a server was removed from the topology (for example, by using the remove-defunct-server tool), secret keys associated with that instance could be lost. This is unlikely to cause any problems in most cases because these keys are no longer used for most purposes. However, it could be an issue if the server is configured to use a legacy password storage scheme that protects passwords with reversible encryption. These schemes encrypt passwords with keys from the topology registry, and if a server was removed from the topology, then keys specific to that instance were also removed. This could prevent remaining servers from being able to decrypt passwords that were initially encrypted by the instance that was removed. To address this, we now preserve any secret keys that are associated with an instance before removing that instance from the topology.
Affected password storage schemes include AES, Blowfish, RC4, and 3DES. The newer AES256 password storage scheme is not affected by this issue.
Size Limits for Add and Modify Requests
We have added new maximum-attributes-per-add-request and maximum-modifications-per-modify-request properties to the global configuration. The former can be used to limit the number of attributes that may be included in an add request, and the latter can be used to limit the number of modifications that may be included in a modify request. Neither of these properties affects the number of values that individual attributes may have.
These limits can help avoid potential denial-of-service attacks that use specially crafted add and modify requests. By default, add requests are limited to 1000 attributes, and modify requests are limited to 1000 modifications, which should be plenty for virtually all real-world use cases.
New ldap-diff Features
We have updated the ldap-diff tool to provide several new features. These include:
- We have added an option to perform byte-for-byte comparisons when identifying differences. By default, the tool uses schema-aware matching, which may not flag differences in values that are logically equivalent but not identical (for example, values that differ only in capitalization for an attribute configured to use case-insensitive matching).
- You can now use a properties file to provide default values for some or all of the command-line arguments.
- We improved support for SASL authentication.
New migrate-ldap-schema Features
We have updated the migrate-ldap-schema tool to provide several new features. These include:
- We have added more flexibility when securing communication with servers over TLS, including the ability to use different key and trust managers for the source and destination servers.
- We have added support for SASL authentication.
- We have added support for using a properties file to obtain default values for some or all of the command-line arguments.
- We have added better validation for migrated attribute types and object classes.