Upgrade Considerations

This upgrade moves to Jetty 9.4. As a result, the HTTPS connection handler will no longer support TLS_RSA ciphers by default. If you use any legacy HTTPS clients that still require TLS_RSA ciphers, modify the ssl-cipher-suite property of the HTTPS Connection Handler to include them.

Critical Fixes

This release of the PingDataSync Server addresses critical issues from earlier versions. Update all affected servers appropriately.

  • The following enhancements were made to the topology manager to make it easier to diagnose the connection errors described in PDSTAGING-570:

    - Added monitoring information for all the failed outbound connections (including the time since it's been failing and the last error message seen when the failure occurred) from a server to one of its configured peers and the number of failed outbound connections.

    - Added alarms/alerts for when a server fails to connect to a peer server within a configured grace period.

    • Fixed in: 7.3.0.0
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38334 PDSTAGING-570 SF#00655578
  • The topology manager will now raise a mirrored-subtree-manager-connection-asymmetry alarm when a server is able to establish outbound connections to its peer servers, but those peer servers are unable to establish connections back to the server within the configured grace period. The alarm is cleared as soon as there is connection symmetry.

    • Fixed in: 7.3.0.0
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38344 PDSTAGING-570 SF#00655578
  • The dsreplication tool has been fixed to work when the node being used to enable replication is currently out-of-sync with the topology master.

    • Fixed in: 7.3.0.0
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38335 PDSTAGING-570 SF#00655578
  • Fixed two issues in which the server could have exposed some clear-text passwords in files on the server file system.

    * When creating an encrypted backup of the alarms, alerts, configuration, encryption settings, schema, tasks, or trust store backends, the password used to generate the encryption key (which may have been obtained from an encryption settings definition) could have been inadvertently written into the backup descriptor. This problem does not affect local DB backends (like userRoot), the LDAP changelog backend, or the replication database.

    * When running certain command-line tools with an argument instructing the tool to read a password from a file, the password contained in that file could have been written into the server's tool invocation log instead of the path to that file. Affected tools include backup, create-initial-config, create-initial-proxy-config, dsreplication, enter-lockdown-mode, export-ldif, import-ldif, ldappasswordmodify, leave-lockdown-mode, manage-tasks, manage-topology, migrate-ldap-schema, parallel-update, prepare-endpoint-server, prepare-external-server, realtime-sync, rebuild-index, re-encode-entries, reload-http-connection-handler-certificates, reload-index, remove-defunct-server, restore, rotate-log, and stop-server. Other tools are not affected. Also note that this only includes passwords contained in files that were provided as command-line arguments; passwords included in the tools.properties file, or in a file referenced from tools.properties, would not have been exposed.

    In each of these cases, the files would have been written with permissions that make their contents only accessible to the system account used to run the server. Further, while administrative passwords may have been exposed in the tool invocation log, neither the passwords for regular users, nor any other data from their entries, should have been affected. We have introduced new automated tests to help ensure that such incidents do not occur in the future.

    We recommend changing any administrative passwords you fear may have been compromised as a result of this issue. If you are concerned that the passphrase for an encryption settings definition may have been exposed, then we recommend creating a new encryption settings definition that is preferred for all subsequent encryption operations, exporting your data to LDIF, and re-importing so that it will be encrypted with the new key. You also may wish to re-encrypt or destroy any existing backups, LDIF exports, or other data encrypted with a compromised key, and you may wish to sanitize or destroy any existing tool invocation log files that may contain clear-text passwords.

    • Fixed in: 7.3.0.0
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38897 DS-38908
  • The following enhancements were made to the topology manager to make it easier to diagnose the connection errors:

    - Added monitoring information for all the failed outbound connections (including the time since it's been failing and the last error message seen when the failure occurred) from a server to one of its configured peers and the number of failed outbound connections.

    - Added alarms/alerts for when a server fails to connect to a peer server within a configured grace period.

    • Fixed in: 7.2.1.0
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38334 SF#00655578
  • The topology manager will now raise a mirrored-subtree-manager-connection-asymmetry alarm when a server is able to establish outbound connections to its peer servers, but those peer servers are unable to establish connections back to the server within the configured grace period. The alarm is cleared when connection symmetry is achieved.

    • Fixed in: 7.2.1.0
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38344 SF#00655578
  • The dsreplication tool has been fixed to work when the node being used to enable replication is currently out-of-sync with the topology master.

    • Fixed in: 7.2.1.0
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38335 SF#00655578
  • Fixed two issues in which the server could have exposed some clear-text passwords in files on the server file system.

    * When creating an encrypted backup of the alarms, alerts, configuration, encryption settings, schema, tasks, or trust store backends, the password used to generate the encryption key (which may have been obtained from an encryption settings definition) could have been inadvertently written into the backup descriptor. This problem does not affect local DB backends (like userRoot), the LDAP changelog backend, or the replication database.

    * When running certain command-line tools with an argument instructing the tool to read a password from a file, the password contained in that file could have been written into the server's tool invocation log instead of the path to that file. Affected tools include backup, create-initial-config, create-initial-proxy-config, dsreplication, enter-lockdown-mode, export-ldif, import-ldif, ldappasswordmodify, leave-lockdown-mode, manage-tasks, manage-topology, migrate-ldap-schema, parallel-update, prepare-endpoint-server, prepare-external-server, realtime-sync, rebuild-index, re-encode-entries, reload-http-connection-handler-certificates, reload-index, remove-defunct-server, restore, rotate-log, and stop-server. Other tools are not affected. Also note that this only includes passwords contained in files that were provided as command-line arguments; passwords included in the tools.properties file, or in a file referenced from tools.properties, would not have been exposed.

    In each of these cases, the files would have been written with permissions that make their contents only accessible to the system account used to run the server. Further, while administrative passwords may have been exposed in the tool invocation log, neither the passwords for regular users, nor any other data from their entries, should have been affected. We have introduced new automated tests to help ensure that such incidents do not occur in the future.

    We recommend changing any administrative passwords you fear may have been compromised as a result of this issue. If you are concerned that the passphrase for an encryption settings definition may have been exposed, then we recommend creating a new encryption settings definition that is preferred for all subsequent encryption operations, exporting your data to LDIF, and re-importing so that it will be encrypted with the new key. You also may wish to re-encrypt or destroy any existing backups, LDIF exports, or other data encrypted with a compromised key, and you may wish to sanitize or destroy any existing tool invocation log files that may contain clear-text passwords.

    • Fixed in: 7.0.1.3
    • Introduced in: 7.0.0.0
    • Support identifiers: DS-38897 DS-38908
  • Fixed an issue with the sync connect and response timeouts being set with incorrect units of time.

    • Fixed in: 6.2.0.0
    • Introduced in: 6.0.0.0
    • Support identifiers: DS-18026 SF#00616763
  • Fixed an issue with the sync connect and response timeouts being set with incorrect units of time.

    • Fixed in: 6.2.0.0
    • Introduced in: 6.0.0.0
    • Support identifiers: DS-18026 SF#00616763
  • The server can now detect an "out of file handles" situation on the operating system, and shut down to prevent running in an unreliable state.

    • Fixed in: 5.1.0.0
    • Introduced in: 2.1.0.0
    • Support identifiers: DS-12579 SF#2655
  • Disabled support for SSLv3 by default in the LDAP, HTTP, and JMX connection handlers, and for replication communication. The recently-discovered POODLE vulnerability could potentially allow a network attacker to determine the plaintext behind an SSLv3-encrypted session, which would effectively negate the primary benefit of the encryption.

    SSLv3 was initially defined in 1996, but was supplanted by the release of the TLSv1 definition in 1999 (and subsequently by TLSv1.1 in 2006 and TLSv1.2 in 2008). These newer TLS protocols are not susceptible to the POODLE vulnerability, and the server has supported them (and preferred them over SSLv3) for many years. The act of disabling SSLv3 by default should not have any adverse effect on clients that support any of the newer TLS protocols. However, if there are any legacy client applications that attempt to communicate securely but do not support the newer TLS protocols, they should be updated to support the newer protocols. In the event that there are known clients that do not support any security protocol newer than SSLv3 and that cannot be immediately updated to support a newer protocol, SSLv3 support can be re-enabled using the newly-introduced allowed-insecure-tls-protocol global configuration property. However, since communication using SSLv3 can no longer be considered secure, it is strongly recommended that every effort be made to update all known clients still using SSLv3.

    It is possible to use the server access log to identify LDAP clients that use SSLv3 to communicate with the server. Whenever an LDAP client establishes a secure connection to the server, or whenever a client uses the StartTLS extended operation to secure an existing plaintext connection, the server will generate a SECURITY-NEGOTIATION access log message. The "protocol" element of a SECURITY-NEGOTIATION access log message specifies the name of the security protocol that has been negotiated between the client and the server, and any SECURITY-NEGOTIATION messages with a protocol of "SSLv3" suggest that the associated client is vulnerable to the POODLE attack. In addition, if any connections are terminated for attempting to use the disallowed SSLv3 protocol, the access log message for that disconnect should include a message stating the reason for the termination.

    • Fixed in: 5.0.0.0
    • Introduced in: 2.1.0.0
    • Support identifiers: DS-11782
  • Change the default behavior of the Synchronization Server to not lock entries across all Sync Pipes when processing changes.

    The Sync Server has a specialized mutex that ensures that changes to the same entry are processed serially. The primary reason for this mutex is to ensure that the server can safely process changes in parallel to achieve high throughput. However, we also use this mutex to ensure that two Sync Pipes don't process the same entry at the same time for deployments that synchronize changes bi-directionally. A consequence of this locking is that if one Sync Pipe is failing (because the destination is unavailable) then it retains the lock on an entry, and when other Sync Pipes try to process changes to that entry they will block that change and all changes that follow it while they wait on the lock.

    This change turns off using a shared mutex by default, but adds a new advanced configuration option on the Sync Pipe, shared-mutex-name, that specifies the name of a mutex that is shared by other Sync Pipes. This gives greater control over the locking so that two Sync Pipes that share end points can ensure that two changes to the same logical user are not processed concurrently, while not impacting other Sync Pipes.

    See the shared-mutex-name property for more information.

    This property is subject to change in a future release.

    • Fixed in: 3.2.0.0
    • Introduced in: 3.0.0.0
    • Support identifiers: DS-4202 SF#1527

Resolved Issues

The following issues have been resolved with this release of the PingDataSync Server:

Ticket ID Description
DS-40551

Fixed an issue that could prevent some tools from running properly with an encrypted tools.properties file.

DS-41074

Fixed an issue with the way the server reports memory usage after completing an explicitly requested garbage collection.

DS-41126

Updated the server to make the general monitor entry available to JMX clients.

DS-41235

Updated the cn=Cluster subtree to prevent clustered configuration changes when servers in the cluster have mixed versions. To make clustered configuration changes, either update all servers in the cluster to the same version, or temporarily create separate clusters by server version by changing the cluster-name property on the server instance configuration objects.

DS-41236

To avoid inconsistencies, changing clustered configuration will now require all servers in the cluster to be on the same product version. Servers will not pull any clustered configuration from the master of the cluster if they are on a different product version.

DS-41261

Fixed an issue with manage-profile replace-profile where certain configuration changes for recurring task chains were not being applied.

DS-41289

Fixed an issue that prevented password changes for topology administrators unless their password policy was configured to allow pre-encoded passwords.

DS-41784

Fixed a bug that could cause the duration of a sync operation to be miscalculated.

DS-42265

Upgrade to jetty 9.4

DS-42665

Fixed an issue that caused the resync tool to not take the attribute-comparison-method of the sync class into account. This caused resync to ignore when byte-for-byte comparison was configured.

DS-42687

Upgrade to jetty 9.4.30