PingDirectory suite of products 9.2.0.0 (December 2022) - PingDirectory - 9.2

• Added a new "secure" access control bind rule that can be used to make access control decisions based on whether the client is using a secure connection (for example, LDAPS or LDAP with StartTLS) to communicate with the server. Using the bind rule secure="true" indicates that the ACI only applies to requests received over a secure connection, while secure="false" indicates that the ACI only applies to requests received over an insecure connection.
• Added a new "connectioncriteria" access control bind rule that can be used to make access control decisions based on whether the client connection matches a specified set of connection criteria. The value of the bind rule can be either the name or the full DN of the configuration object that defines the desired connection criteria.
• Added a new "requestcriteria" access control target that can be used to make access control decisions based on whether the operation request matches a specified set of request criteria. The value of the target can be either the name or the full DN of the configuration object that defines the desired request criteria.

For more information, see ACI bind rules and ACI targets.

Added a new "audit data security" recurring task that can be used to regularly examine server data for potential security-related issues. For more information, see Auditing data content.

Added new stats to track operations on account state when using an UnboundIDSyncDestination. They can be found on the monitor entry for the sync pipe associated with the destination.

The server can now run on Java 17.

Updated Groovy support from Groovy 2.x to Groovy 3.x for Java 17 compatibility. This change might introduce some minor incompatibilities in Groovy script support (for example, it appears that import statements split across multiple lines are no longer allowed), so deployments making use of Groovy-scripted extensions should carefully test these extensions in a temporary standalone instance to verify compatibility and make any necessary changes before updating existing instance.

Added a SCIM 2.0 sync destination. For more information, see Configuring synchronization to a SCIM 2.0 server.

Added new password storage schemes that provide support for the Argon2i, Argon2d, and Argon2id variants of the Argon2 password hash and proof-of-work function. We previously offered only a single Argon2 password storage scheme (which used Argon2i behind the scenes), but the new schemes make it possible to explicitly indicate which variant should be used for encoding passwords.

For more information about password storage schemes, see Supported password storage schemes.

Added an HTTP servlet extension that allows the values of numeric monitor attributes to be published as metrics in a form that can be consumed by a Prometheus monitoring server. For more information, see Monitoring server metrics with Prometheus.

• Fixed an issue in which the locked account data security auditor did not include the number of validator-locked entries in the summary generated when completing processing for a backend.
• Fixed an issue in which the expired password data security auditor could incorrectly report that an entry has an old password even when it has been changed more recently than the configured password evaluation age.
• Fixed an issue with the weakly encoded password data security auditor that could prevent it from detecting passwords encoded with certain schemes.
• Updated the weakly encoded password data security auditor so passwords encoded using unsalted SHA-1 digests, salted SHA-1 digests, salted MD5 digests, and the MD5 variant of the CRYPT password storage scheme are now considered weak by default.
• Updated the Server SDK to add support for creating custom data security auditors.

For more information about data security auditors, see Auditing data content.

Removed support for incremental backups, which had been deprecated since the 8.3.0.0 release. As an alternative, we recommend using LDIF exports, which are more useful, more portable, and much more compressible than full backups, and they can be taken more frequently than full backups without consuming as much disk space. Further, the extract-data-recovery-log-changes tool can be used in conjunction with either LDIF exports or backups to replay changes recorded in the data recovery log since the time the export or backup was created.

Fixed an issue where exploded indexes were unexpectedly created following an unclean shutdown.

Fixed an issue with the dsreplication tool where baseDNs and restricted baseDNs were improperly handled as case sensitive.

To close a vulnerability found in hibernate-validator 5.4.3 in the management console, we are updating the console to version 6.2.1. This newer version requires use of jakarta-validator 2.0.2 rather than the older javax-validator 1.1.0, therefore we are upgrading directory to use jakarta-validator 2.0.2 to preserve compatibility.

When moving to version 2, javax-validator was moved to jakarta, but still uses the javax namespace, and therefore no code changes need to be made other than dependencies. In the future, if we move to jakarta-validator v3 however, we will need to move to the jakarta namespace.

Fixed an issue where a replication initialize task that ran longer than the configured connection idle-timeout-limit would cause the initialize to fail.

Fixed an issue where resource limits for the topology admin user created during replication enable were not set.

Updated jQuery to 3.6.0.

Fixed an issue that caused replication enablement to fail if there is at least one topology-wide administrator with no password.

Resolved an issue with slow response time on PingDirectory servers configured with a large number (10,000 or more) of virtual static groups.

Fixed an issue encountered when using PingDataSync with a PingOne Sync Destination that caused sync to slow down significantly after 5 minutes and generate extraneous requests to the sync destination.

Fixed an issue where changes to certain Password Policy State attributes would not be applied to the correct entry when using a Ping Identity Sync Destination under very specific circumstances.

Updated the PingDirectoryProxy server to expose the maximum-attributes-per-add-request and maximum-modifications-per-modify-request properties in the global configuration. These properties were previously only visible in the PingDirectory server configuration, but they also apply to requests that pass through the PingDirectoryProxy server.

Modified the migrate-ldap-schema tool to remove incorrect single-quotes enclosing the attribute type syntax OID in schemas being imported from Microsoft Active Directory.

Fixed an issue in which the server could prevent users from changing their own passwords with the password modify extended operation if their account was in a "must change password" state and the request passed through the Directory Proxy Server.

Fixed an issue where new servers could not be enabled into a large topology.

The audit-data-security tool is used to identify potential risks or other notable security characteristics contained in directory data. This tool has been enhanced to use new data security auditors defined in the server configuration. The new data security auditors can identify:

• Accounts with password policy state issues that might currently or soon affect their usability.
• Accounts with an activation time in the future, an expiration time in the past, or an expiration time in the near future.
• Accounts with passwords encoded using deprecated password storage schemes.
• Accounts for users that have not authenticated in longer than a specified length of time.
• Accounts that are configured to use a nonexistent password policy and are therefore unable to authenticate.
• Entries that match a specified search filter.

Also, the locked account auditor is now able to identify validation-locked accounts, and the weakly encoded password auditor can now flag passwords encoded with SMD5, SHA, and SSHA, and also the MD5 variant of the CRYPT scheme.

For more information about the audit-data-security tool, see Auditing data content.

A number of features have been added to improve logging and the summarize-access-log tool to provide a better experience for administrators. The summarize-access-log tool already provided a list of the domain names of the target users for the most common bind failures, but the following metrics have been added to improve the detection of possible security issues:

• The IP addresses of the clients with the most failed bind attempts (in case a single client is trying to access multiple accounts, as might happen in a credential stuffing attack).
• The addresses of the users with the most consecutive authentication failures (that is, most failures between successes or most failures without a success).
• The identification of filters with parentheses, ampersands, pipes, single quotes, and double quotes, which might indicate an unsuccessful LDAP filter injection attempt.
• The identification of filters with the words "select" and "from", which might indicate an unsuccessful SQL injection attempt.
• The identification of the most common used and missing privileges.
• The tracking of the number of components used in filters as an increase in the number of filters with more components, which might suggest a successful injection attempt.

For more information about the summarize-access-log tool, see Logging Tools

PingDirectory provides a number of features to manage control to data within the data store including Access Control Instructions and connection criteria. In this release, the access control handler now provides support for a bind rule that can make it possible to make access control decisions based on whether the client connection is secure or whether the client connection matches a given set of connection criteria or if a target that makes it possible to determine whether the rule applies to a given request based on request criteria.

Updated the global configuration to define configuration properties that can be used to set alternative size limit, time limit, idle time limit, and lookthrough limit values for unauthenticated clients. By default, the server will use the same default limits for both authenticated and unauthenticated clients, but you can now set limits for unauthenticated clients that are different from the default limits imposed for authenticated clients. It is still possible to override these limits on a per-user basis with operational attributes in the user's entry.

Added support for generating digital signatures with a key obtained from an encryption settings definition. By default, the server's preferred encryption settings definition will be used to obtain the signing key, but you can use the signing-encryption-settings property in the crypto manager configuration to choose an alternative definition.

Previously, signatures were generated using a legacy key shared among servers in the topology, which could make it difficult to validate signatures outside of the topology. The legacy key will continue to be used in environments without any encryption settings definitions.

Updated the server to add HTTP forward proxy support for several server components that may need to establish HTTP and HTTPS connections to external services. Updated components include:

• The Amazon Key Manager cipher stream provider
• The Amazon Secrets Manager cipher stream provider
• The Amazon Secrets Manager passphrase provider
• The Amazon Secrets Manager password storage scheme
• The Azure Key Vault cipher stream provider
• The Azure Key Vault passphrase provider
• The Azure Key Vault password storage scheme
• The PingOne pass-through authentication plugin
• The PingOne sync source and destination
• The Pwned Passwords password validator
• The SCIMv1 sync destination
• The SCIMv2 sync destination
• The Twilio alert handler
• The Twilio OTP delivery mechanism
• The UNBOUNDID-YUBIKEY-OTP SASL mechanism handler

The replication-purge-obsolete-replicas global configuration property is now set to true by default for new and upgraded PingDirectory servers so that obsolete replicas are purged.

Updated the replace-certificate tool's behavior when running in interactive mode. Previously, when it prompted the user for the path to a file containing one or more certificates to be imported, it would exit with an error if the provided path represented a file that did not contain valid certificate information. It will now re-prompt the user for the path to a valid file after displaying the error message.

Updated replication enable synopsis to mention that schema initialization is part of the enable process and explain that the order of provided servers is significant for the initialization.

Updated the dsconfig tool to ensure that it uses the correct authentication type when applying changes to all servers in a server group. Previously, it would always attempt to use simple authentication, even if the connection to the initial server was authenticated using a different mechanism.

The replication server now continues to handle incoming replication connections even when there is an unexpected exception.

Updated the Amazon AWS external server configuration to provide more control over the method used to authenticate to AWS. Previously, it was only possible to authenticate with an access key or an IAM role. We have added an option to use an IRSA role, and we have also added an option to use a default credentials provider chain that attempts to identify an appropriate authentication method for cases in which the server is running in the AWS environment (for example, EC2 or EKS) based on locally available information like system properties and environment variables.

There is a known issue with the description of the dsreplication enable subcommand differing based on the operating system. On MacOS, an updated description is shown:

"Update the configuration of the servers to replicate the data under the specified base DN(s). If one of the two servers is already part of an existing replication topology, then that server must be specified as the first server. This is because the schema of the second server will be updated to match the schema of the first. The configuration of all the servers in the existing topology will also be updated, so it is sufficient to perform this operation once for each new server that is added to the topology. The server-to-server replication communication is always secured with SSL."

But on some operating systems, including Windows and CentOS, the older description is shown that doesn't mention the schema initialization.