Keep in mind the following upgrade considerations introduced in PingDirectory 8.x versions.
If you plan to upgrade servers using a mixed-version environment where one version is
earlier than 7.0 and some of the servers are still using the admin backend while
others have been updated to the topology registry, do not attempt to make size
changes to the topology. You cannot remove any existing servers (using
dsreplication disable) or add new servers (using
dsreplication enable) when in this transitional state of
partially-updated servers. When a topology has been completely migrated to a 7.0 or
later version with the topology registry, changes to the topology size are allowed,
even in mixed-version environments (for example, mixed 7.3 and 8.3).
Upgrade considerations introduced in 126.96.36.199
RFC 8996 was released, officially deprecating the TLSv1 and TLSv.1.1 protocols and explicitly stating that these must not be used. Per this specification, only TLSv1.2 and TLSv1.3 are considered acceptable for use. Therefore, for this release, TLSv1 and TLSv.1.1 are disabled by default. Disabling support for TLSv1 and TLSv1.1 does not prevent these protocols from being used, it only disables them by default. Support for these legacy protocols can be re-enabled in the configuration if necessary. Also, support for TLS cipher suites that use the SHA-1 message digest is being deprecated, as SHA-1 is no longer considered secure. We are also deprecating support for TLS cipher suites that use RSA key exchange because these do not provide forward secrecy.
Changes to entries made by the clients using the SCIMv2 API will now have the actual user ID, making the request stored in the access and audit logs. By default, the server will continue to use the "SCIM2 Servlet" user as the authorization identity for all SCIM2 requests, and the DN of this user will be recorded in the access log and in the creatorsName and modifiersName attributes. If you want to change this behavior, change the value of the map-access-tokens-to-local-users property from disabled to either optional or required. This will cause the server to map the token to a local user, and if the mapping is successful, the mapped user's DN will be used as the authorization identity for the operations.
Upgrade considerations introduced in 188.8.131.52
This upgrade moves to Jetty 9.4. As a result, the HTTPS Connection Handler no longer supports TLS_RSA ciphers by default. If you use any legacy HTTPS clients that still require TLS_RSA ciphers, modify the
ssl-cipher-suiteproperty of the HTTPS Connection Handler to include them.
Upgrade considerations introduced in 184.108.40.206
If you have upgraded a server that is in a cluster (that has a cluster name set in the Server Instance configuration object) to version 8.1, you will not be able to make cluster configuration changes until all servers with the same cluster name have been upgraded to version 8.1. If needed, you can create temporary clusters based on server versions and modify each of the servers' cluster name appropriately to minimize the impact while you are upgrading.
bypass-pw-policy privilegewas intended to provide a way for administrators to bypass certain password restrictions that would normally be imposed when managing passwords for other users. A user with this privilege could use it to bypass password validation for their own entry. The
bypass-pw-policyprivilege now only applies when changing another user’s password (that is, an administrative password reset), and only in the following scenarios:
- A user with this privilege will be permitted to set pre-encoded passwords.
- A user with this privilege will be permitted to set passwords that would otherwise be rejected by one or more password validators.
- A user with this privilege will be permitted to set passwords that match the current password or that are in the password history.
- Missing changes will now be detected when the backend is reverted and there are insufficient changes in the changelog database. When in this particular missing-changes state the local replica will not accept changes from the local replication server. privilege and check for compatibility issues. You can use the existing password validators and a custom password policy to enforce passwords for administrative users.
- Fixed an issue in which the server could incorrectly evaluate a matched values request control containing an extensible match filter that specified both an attribute type and a matching rule. The server incorrectly used the attribute type's equality matching rule instead of the matching rule specified in the filter.
- Updated the "delay bind response" failure lockout action to provide an option to delay the response to bind requests initiated by non-LDAP clients (for example, when using HTTP basic authentication). This option is disabled by default because delaying the bind response for non-LDAP clients may require temporarily blocking the thread used to process the request, which could increase the risk of a denial-of-service attack. To help mitigate this risk, if you enable delayed bind responses for non LDAP clients, we recommend that you also increase the number of request handler threads for all enabled HTTP connection handlers.
- privilege and check for compatibilityUpdated setup to create a second encryption settings definition if data
encryption is enabled. It will continue to create a definition for 128-bit AES
encryption for use as the preferred definition to preserve backward
compatibility with existing servers in the topology, but it will now also
generate a definition for 256-bit AES encryption. The 256-bit AES definition may
become the preferred definition in a future release, but you can use it now by
first ensuring that any existing instances are updated to contain the new
definition (with the
encryption-settings importcommands) and then making it the preferred definition (with
encryption-settings set-preferred) in all instances.
- Fixed an issue that could prevent the uninstaller from removing information about the instance from the topology registry.