--- title: What’s new description: Lists new features and enhancements in PingDS releases, with version-specific upgrade notes for 8.1 and earlier versions. component: pingds version: release-notes page_id: pingds::whats-new canonical_url: https://docs.pingidentity.com/pingds/release-notes/whats-new.html revdate: 2026-04-22T12:00:00Z keywords: ["Evaluation", "Features", "LDAP", "Upgrade"] section_ids: whats-new-81: DS 8.1 ds_8_1_0: DS 8.1.0 performance: Performance security: Security password_storage: Password storage fips: FIPS json_format_errors: JSON-format errors networking: Networking logging: Logging tools: Tools java: Java whats-new-80: DS 8.0 ds_8_0_3: DS 8.0.3 ds_8_0_2: DS 8.0.2 ds_8_0_1: DS 8.0.1 java_2: Java ds_8_0_0: DS 8.0.0 distributed_tracing: Distributed tracing jfr_support: JFR support faster_index_rebuilds: Faster index rebuilds additional_indexing_improvements: Additional indexing improvements additional_performance_improvements: Additional performance improvements look_through_limit: Look through limit passwords_and_password_policies: Passwords and password policies security_2: Security tools_2: Tools whats-new-75: DS 7.5 ds_7_5_3: DS 7.5.3 ds_7_5_2: DS 7.5.2 ds_7_5_1: DS 7.5.1 hdap: HDAP operating_systems: Operating systems tools_3: Tools ds_7_5_0: DS 7.5.0 disaster_recovery: Disaster recovery hdap_2: HDAP indexing: Indexing access_logs: Access logs monitoring: Monitoring resource_limits: Resource limits searches: Searches java_3: Java operating_systems_2: Operating systems tools_4: Tools whats-new-74: DS 7.4 ds_7_4_4: DS 7.4.4 ds_7_4_3: DS 7.4.3 ds_7_4_2: DS 7.4.2 disaster_recovery_2: Disaster recovery operating_systems_3: Operating systems resource_limits_2: Resource limits ds_7_4_1: DS 7.4.1 security_3: Security tools_5: Tools ds_7_4_0: DS 7.4.0 hdap_3: HDAP access_logs_2: Access logs debug_and_error_logs: Debug and error logs monitoring_2: Monitoring password_policy: Password policy collective_attributes: Collective attributes schema: Schema replication: Replication performance_2: Performance security_4: Security native_packages: Native packages tools_6: Tools whats-new-73: DS 7.3 ds_7_3_6: DS 7.3.6 ds_7_3_5: DS 7.3.5 disaster_recovery_3: Disaster recovery operating_systems_4: Operating systems resource_limits_3: Resource limits ds_7_3_4: DS 7.3.4 security_5: Security tools_7: Tools ds_7_3_3: DS 7.3.3 ds_7_3_2: DS 7.3.2 ds_7_3_1: DS 7.3.1 ds_7_3_0: DS 7.3.0 replication_2: Replication groups: Groups indexing_2: Indexing monitoring_3: Monitoring logging_2: Logging ldap: LDAP schema_2: Schema tools_8: Tools whats-new-72: DS 7.2 ds_7_2_5: DS 7.2.5 disaster_recovery_4: Disaster recovery resource_limits_4: Resource limits ds_7_2_4: DS 7.2.4 security_6: Security ds_7_2_3: DS 7.2.3 ds_7_2_2: DS 7.2.2 ds_7_2_1: DS 7.2.1 ds_7_2_0: DS 7.2.0 backup: Backup indexing_3: Indexing logging_3: Logging monitoring_4: Monitoring password_storage_2: Password storage performance_3: Performance proxy: Proxy replication_3: Replication rest_to_ldap: REST to LDAP schema_3: Schema security_7: Security tools_9: Tools virtual_attributes: Virtual attributes whats-new-71: DS 7.1 ds_7_1_8: DS 7.1.8 disaster_recovery_5: Disaster recovery ds_7_1_7: DS 7.1.7 ds_7_1_6: DS 7.1.6 ds_7_1_5: DS 7.1.5 ds_7_1_4: DS 7.1.4 ds_7_1_3: DS 7.1.3 rest_to_ldap_2: REST to LDAP ds_7_1_2: DS 7.1.2 performance_4: Performance tools_10: Tools ds_7_1_1: DS 7.1.1 java_4: Java ds_7_1_0: DS 7.1.0 backup_2: Backup indexing_4: Indexing logging_4: Logging passwords: Passwords replication_4: Replication rest_to_ldap_3: REST to LDAP samples: Samples security_8: Security tools_11: Tools whats-new-70: DS 7.0 ds_7_0_2: DS 7.0.2 ds_7_0_1: DS 7.0.1 ds_7_0_0: DS 7.0.0 access_control: Access control aliases_for_controls_and_extended_operations: Aliases for controls and extended operations authentication: Authentication multiple_identity_mappers: Multiple identity mappers backup_and_restore: Backup and restore new_simplified_implementation_with_cloud_storage_support: New, simplified implementation with cloud storage support cloud_deployments: Cloud deployments ready_for_docker_and_kubernetes: Ready for Docker and Kubernetes collective_attributes_2: Collective attributes relative_parent_support: Relative parent support data_storage: Data storage shared_database_cache_by_default: Shared database cache by default newer_je: Newer JE data_encryption: Data encryption portable_encrypted_data: Portable encrypted data gcm_with_aes: GCM with AES email_notifications: Email notifications secure_authenticated_connections: Secure, authenticated connections interoperability: Interoperability microsoft_ad_range_retrieval_support: Microsoft AD range retrieval support logging_5: Logging field_whitelisting: Field whitelisting error_messages_to_standard_output: Error messages to standard output more_information_about_operations_in_access_logs: More information about operations in access logs details_when_a_connection_handler_fails_to_start: Details when a connection handler fails to start monitoring_5: Monitoring monitor_account_replicated_by_default: Monitor account replicated by default networking_2: Networking advertised_listen_address: Advertised listen address passwords_2: Passwords scram_sasl_support: SCRAM SASL support full_featured_replicated_password_policies: Full-featured, replicated password policies stronger_password_storage_schemes: Stronger password storage schemes 128_bit_salt: 128-bit salt rehash_passwords: Rehash passwords password_quality_advice: Password quality advice performance_5: Performance faster_export: Faster export faster_rest_to_ldap_performance: Faster REST to LDAP performance proxy_2: Proxy mutual_tls_with_ldap_servers: Mutual TLS with LDAP servers ds_proxied_server: DS proxied server rest: REST path_references: Path references reverse_references: Reverse references password_quality_advice_2: Password quality advice account_usability_support: Account usability support sasl_external_and_sasl_scram_support: SASL EXTERNAL and SASL SCRAM support per_server_password_policies_over_rest: Per-Server password policies over REST replication_5: Replication replication_at_setup_time: Replication at setup time new_command_to_manage_replication: New command to manage replication string_based_server_ids: String-based server IDs one_server_id_per_server: One server ID per server the_command_the_existing_global_server_id_if_available: The command the existing global server ID, if available. otherwise_the_command_uses_the_first_server_id_found_in_cnadmin_data: Otherwise, the command uses the first server ID found in cn=admin data. if_replication_has_not_yet_been_configured_the_command_generates_a_new_id_for_the_server: If replication has not yet been configured, the command generates a new ID for the server. one_group_id_per_server: One group ID per server replication_delay_metrics: Replication delay metrics replay_performance: Replay performance replication_of_offline_ldif_changes: Replication of offline LDIF changes automatic_purge_of_stale_replicas: Automatic purge of stale replicas exclude_domains_from_changelog_indexes: Exclude domains from changelog indexes cts_excluded_from_changelog_indexing: CTS excluded from changelog indexing more_details_about_unresolved_conflicts: More details about unresolved conflicts samples_2: Samples sample_for_building_custom_docker_images: Sample for building custom Docker images updated_sample_for_grafana_and_prometheus: Updated sample for Grafana and Prometheus schema_4: Schema require_true_or_false_boolean_values: Require TRUE or FALSE boolean values security_9: Security secure_by_default: Secure by default simple_private_pki: Simple private PKI keystores_reload_without_restart: Keystores reload without restart simple_key_rotation: Simple key rotation alternative_pkcs11_types: Alternative PKCS#11 types multiple_trust_managers: Multiple trust managers multiple_certificate_mappers: Multiple certificate mappers indexes_for_certificate_attributes: Indexes for certificate attributes richer_access_log_messages: Richer access log messages tools_12: Tools new_setup_profile_command: New setup-profile command configurable_domains_and_base_dns: Configurable domains and base DNs generate_systemd_service_files: Generate systemd service files generate_user_entries_for_evaluation: Generate user entries for evaluation proxied_authorization_for_rate_tools: Proxied authorization for rate tools support_for_formatted_integers: Support for formatted integers task_management: Task management set_task_ids_and_descriptions: Set task IDs and descriptions no_changes_when_reading_je_backends_offline: No changes when reading JE backends offline status_output_improvements: Status output improvements supportextract_improvements: Supportextract improvements byte_by_byte_ldif_comparisons: Byte-by-byte LDIF comparisons whats-new-65: DS 6.5 ds_6_5_6: DS 6.5.6 ds_6_5_5: DS 6.5.5 ds_6_5_4: DS 6.5.4 ds_6_5_3: DS 6.5.3 ds_6_5_2: DS 6.5.2 ds_6_5_1: DS 6.5.1 ds_6_5_0: DS 6.5.0 connection_limiting: Connection limiting data_distribution: Data distribution database_caching: Database caching logging_6: Logging monitoring_6: Monitoring platform_integration: Platform integration replication_6: Replication support: Support --- # What's new | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | * DS 7.4.0 If you use data encryption with default settings, avoid deploying DS 7.4.0. Use DS 7.4.1 or later instead, as these releases include a fix for OPENDJ-10211. If you deployed DS 7.4.0 with data encryption (confidentiality) using default settings, don't use the `upgrade` command to upgrade in-place. Instead, refer to [Upgrade from DS 7.4.0](https://docs.pingidentity.com/pingds/7.4/upgrade-guide/from-740.html). * DS 7.3.0 If you deployed DS 7.3.0 with static groups, important upgrade actions may be required. Contact [support](https://www.pingidentity.com/en/support/support-center.html) for details. | ## DS 8.1 ### DS 8.1.0 #### Performance * DS servers now process modify operations more efficiently, normalizing replication-related historical data only for modified attributes. * DS servers now more efficiently encode very large search result entries. * DS servers now return search results faster, normalizing values only for attributes in the search filter. This optimization can significantly improve search performance when returning entries with large attributes not in the search filter. * DS can now use a VLV index to optimize searches of the following form: ``` (&(vlv-filter)(sortKey1=value1)(sortKey2=value2)...(sortKeyN=valueN)) ``` This optimization works when: * The search filter is an intersection (`&`) of sub-filters. * The vlv-filter matches the VLV `filter` in the index configuration. * The remaining equality filters correspond to a leading subset of the index's sort keys. The remaining equality filters can omit trailing sort keys, but can't skip any. * The sort key attributes are single-valued in the LDAP schema. #### Security ##### Password storage * DS servers now support the [scrypt](https://www.rfc-editor.org/rfc/rfc7914.html) password storage scheme. Learn more in [Password storage](https://docs.pingidentity.com/pingds/8.1/security-guide/pwp-strong-safe.html#configure-pwd-storage). * DS servers now let you choose the Bcrypt algorithm version using the new `version` property of the password storage scheme configuration. Set `version: 2a` to use the original OpenBSD version or use `version: 2b` (default) to use the fixed version from 2014. ##### FIPS * DS servers now support configuring a dedicated signing key for backups. To use the feature, all DS servers' Crypto Managers must use the same master key and signing key pairs. Use a shared keystore containing both key pairs and set the `signing-key-alias` property of the Crypto Manager configuration to the signing key's alias. Learn more in [FIPS 140–3 compliance](https://docs.pingidentity.com/pingds/8.1/install-guide/fips.html). * DS commands using keystores and truststores now indicate the path, type, and provider with separate options. Learn more in the list of [deprecations since DS 8.1](deprecation.html#deprecated-81). #### JSON-format errors * DS servers now support a structured error control (`1.3.6.1.4.1.36733.2.1.5.9`) to request JSON-format structured error responses similar to the following: ``` # Structured error: { "reason": , "parameters": } ``` Use the *--control JsonError* option with DS tools to request structured error responses. Not all errors have structured error responses. #### Networking * DS connection handlers now support a boolean `match-sni-name` property (default: `false`) to use the client-provided Server Name Indication (SNI) value to select the certificate for TLS connections. Set this to `true` in deployments where DS serves requests on multiple hostnames, each with its own DS server certificate. #### Logging * JSON format file-based access log publishers now support the `log-file-permissions` setting. * External access log publishers, such as the `Console LDAP Access Logger` in the sample DS Docker image that writes to standard output, now support the following advanced settings to configure how they log modification requests: * `log-modified-attribute-values` * `exclude-values-of-attributes` * `include-values-of-attributes` JSON format file-based access log publishers have had these advanced settings since DS 7.4.0. * For search responses, DS servers now log the total size in bytes of all entries read from disk while processing the search operation. This appears in the access log message's `"response"` field as `"totalEntriesSize"`. #### Tools * The `backendstat dump-index` command now accepts the index's full name. The command-line interface was simplified as described in the list of [changes in DS 8.1](changes.html#changes-81). * The `supportextract` command now also collects information about virtual threads. #### Java * DS 8.1.0 requires Java 25 or later. ## DS 8.0 ### DS 8.0.3 DS 8.0.3 is the latest release targeted for DS 8 deployments. Download it from the [download page](https://product-downloads.pingidentity.com/browse/ds/all/productId:ds/minorVersion:8/version:8.0.3/releaseType:full). Use this release for an initial deployment or to update an existing DS 8.0.x or earlier deployment. ### DS 8.0.2 DS 8.0.2 is a maintenance release that doesn't include new features. ### DS 8.0.1 #### Java DS 8.0.1 introduces support for Java 25 in addition to Java 21. ### DS 8.0.0 #### Distributed tracing DS servers now support distributed tracing using the [OpenTelemetry](https://opentelemetry.io/) Java SDK. * Access log messages now include `traceId` and `spanId` string fields. * Servers support a [W3C trace context](https://www.w3.org/TR/trace-context) LDAP control. Learn more in [W3C trace context control](https://docs.pingidentity.com/pingds/8/ldap-reference/controls.html#w3c-trace-context-control). * Servers add span attributes following the [semantic conventions](https://opentelemetry.io/docs/specs/semconv/general/attributes/) with LDAP-specific attributes based on [HTTP conventions](https://opentelemetry.io/docs/specs/semconv/http/http-spans/). * An OpenTelemetry plugin, configured for new servers but disabled by default, pushes traces to an OpenTelemetry Protocol (OTLP) endpoint over HTTP. Learn more in [Push to an OpenTelemetry service](https://docs.pingidentity.com/pingds/8/monitoring-guide/opentelemetry.html). #### JFR support DS servers now use Java Flight Recorder (JFR) as a monitoring and diagnostic tool. JFR provides real-time, low-overhead continuous monitoring to capture critical CPU, memory, thread, and other metrics with minimal impact on the server and low overhead. With JFR data, qualified support personnel can more easily identify performance issues and bottlenecks. On Linux systems, JFR support is enabled by default. Learn more in [Java Flight Recorder](https://docs.pingidentity.com/pingds/8/maintenance-guide/troubleshooting.html#troubleshoot-use-jfr). #### Faster index rebuilds The `rebuild-index` command now optimizes disk access especially in offline mode to ensure maximum performance. #### Additional indexing improvements * A DS server now better detects when it can trust an index without needing to rebuild the index. A command to rebuild untrusted indexes affects all the indexes that need rebuilding and only those indexes. #### Additional performance improvements * DS servers now compress entries by default before storing them in JE backends. DS servers also compress replication changelog records by default. After compression is enabled, the server compresses each entry the next time it is updated. It only compresses all entries at once when you import the data from LDIF. The effectiveness of compression depends on the type of data in the entries. For text-based data and especially repetitive text-based data like JSON, compression can significantly reduce how much disk space a backend uses. * DS servers now more efficiently delete nested groups, improving performance especially in deployments with many static groups. * The default `db-log-filecache-size` setting for JE backends is now 10,000 for new servers. With the previous default settings, JE backends larger than 200 GB on disk were subject to file cache thrashing as the database had to close one database log file to open another. With the new default settings, the database can grow to 10 TB on disk before this becomes a concern. #### Look through limit * DS servers again support a global `lookthrough-limit` and an entry-specific `ds-rlimit-lookthrough-limit`. This limit approximates the computational cost of processing a search request. Its value reflects the number of *records* to look through. In DS 7.1 and earlier, the limit reflected the number of *entries* to look through. The number of records can be up to double the number of entries, so set the limits accordingly. For example, if you set `ds-rlimit-lookthrough-limit: 5000` in DS 7.1, set `ds-rlimit-lookthrough-limit: 10000` now. #### Passwords and password policies * DS servers now support the PBKDF2-HMAC-SHA512T256 password storage scheme for interoperability with Microsoft Entra ID. The new password storage scheme isn't enabled by default. If you need the new scheme, enable it with the `dsconfig set-password-storage-scheme-prop --scheme-name PBKDF2-HMAC-SHA512T256 --set enabled:true` command. * DS servers now enable a `ds-pwp-state-json` password policy state operational virtual attribute by default. It provides information similar to the `manage-account get-all` command without requiring controls, extended operations, or any special tools. For details, refer to the [LDAP example](https://docs.pingidentity.com/pingds/8/ldap-guide/passwords-and-accounts.html#ldap-read-pwp-state) or the [HTTP example](https://docs.pingidentity.com/pingds/8/rest-guide/action-rest.html#read-pwp-state). * DS attribute value password validators now check whether passwords contain attribute values shorter than the `min-substring-length` (default: 5). For example, the validator can reject a password containing `Bob` for a user named Bob even when `min-substring-length: 5`. #### Security * DS now supports Bouncy Castle FIPS to help with FIPS 140–3 compliance without requiring an HSM using a PKCS#11 interface. Learn more in [FIPS 140–3 compliance](https://docs.pingidentity.com/pingds/8/install-guide/fips.html). #### Tools * The `backendstat` and `verify-index` commands can now run while DS is online. The commands run with a read-only view of the data while DS continues to have a read-write view. This has the side effect of limiting or pausing database cleanup. DS uses extra disk space while the commands run. * The `dsrepl status` command now shows hostname information when used with the `--showReplicas` or `--showChangelogs` option. The command also shows a warning when different replication servers don't share the same generation ID. * The `rebuild-index` command now logs messages describing why newly created indexes with no data are implicitly trusted. * DS command output now wraps at 120 columns by default instead of 80 columns. ## DS 7.5 ### DS 7.5.3 DS 7.5.3 is the latest release targeted for DS 7.5 deployments and can be downloaded from the [download page](https://product-downloads.pingidentity.com/browse/ds/all/productId:ds/minorVersion:7.5/version:7.5.3/releaseType:full). The release can be deployed as an initial deployment or updated from an existing DS 7.5.x or earlier deployment. ### DS 7.5.2 DS 7.5.2 is a maintenance release that doesn't include new features. ### DS 7.5.1 #### HDAP * HDAP is no longer a *Technology Preview*. Customers can now use HDAP in production deployments. The interface stability for HDAP is *Evolving*. #### Operating systems * This release adds support for Windows Server 2022. #### Tools * The `dsrepl status` command now shows hostname information when used with the `--showReplicas` or `--showChangelogs` option. ### DS 7.5.0 #### Disaster recovery * DS servers now support safer disaster recovery procedures you can apply one server at a time. The procedures hinge on the new `dsrepl disaster-recovery` command. The new subcommand replaces the previous subcommands, which have been removed. For details, refer to the [disaster recovery](https://docs.pingidentity.com/pingds/7.5/use-cases/disaster-recovery.html) documentation. #### HDAP * HDAP now supports HTTP Bearer authorization with an access token. This is especially useful when performing multiple operations as a user with a strong password storage scheme. The computational cost to validate the password is high, but you only pay the cost once. The cost to validate a JWT token is low for each subsequent operation. For details, refer to [Bearer auth](https://docs.pingidentity.com/pingds/7.5/rest-guide/rest-operations.html#authenticate-rest-bearer) and to the code samples in the HDAP documentation. #### Indexing * DS servers no longer require rebuilding indexes for attributes that have never been used before. * DS servers are now more efficient in using equality indexes as a replacement for presence indexes when processing intersection search filters. * DS servers can now fall back to VLV indexes for some true and equality searches with appropriate sort keys. For details, refer to [Index use by matching rule](https://docs.pingidentity.com/pingds/7.5/config-guide/idx-what.html#index-fallbacks). #### Access logs * Log messages now list LDAP control aliases instead of OIDs in the response details. #### Monitoring * DS monitoring metrics now include specific metrics for persistent search etimes: * The LDAP attribute on an LDAP connection handler monitoring entry is `ds-mon-requests-psearch`. * The Prometheus metric is `ds_connection_handlers_ldap_requests_count{ldap_handler,type="psearch"}`. * DS Prometheus monitoring output now complies better with third-party applications. It follows the [Prometheus text format](https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format). To continue using the previous format for now, set `legacy-format:true` in the Prometheus endpoint configuration. This setting is deprecated and likely to be removed in a future release. #### Resource limits * DS resource limits now depend on the proxy authorization identity rather than the bind DN. #### Searches * DS now explicitly restricts persistent searches to a single backend. #### Java * DS now supports Java 17 and 21. #### Operating systems * This release adds support for Amazon Linux 2023. #### Tools * The new `dsrepl decode-csn` command helps debug replication issues. It displays the components of one or more valid CSNs to show when they were generated and which server generated them. * The `supportextract` command now includes the system hostname in the name of the archive file. * The `upgrade` command now stops the upgrade process if the previous version is DS 7.4.0 and the server uses data encryption (confidentiality) with the default AES/GCM cipher. For instructions, refer to [Upgrade from DS 7.4.0](https://docs.pingidentity.com/pingds/7.4/upgrade-guide/from-740.html). ## DS 7.4 ### DS 7.4.4 DS 7.4.4 is the latest release targeted for DS 7.4 deployments. Get it from the [download site](https://backstage.forgerock.com/downloads/browse/ds/all/productId:ds/minorVersion:7.4/version:7.4.4/releaseType:full). The release can be deployed as an initial deployment or updated from an existing DS 7.4.x or earlier deployment. ### DS 7.4.3 DS 7.4.3 is a maintenance release that doesn't include new features. ### DS 7.4.2 DS 7.4.2 is a maintenance release with the following improvements. #### Disaster recovery * DS servers now support safer disaster recovery procedures you can apply one server at a time. The procedures hinge on the new `dsrepl disaster-recovery` command. For details, refer to the [disaster recovery](https://docs.pingidentity.com/pingds/7.4/maintenance-guide/disaster-recovery.html) documentation. #### Operating systems * This release adds support for Amazon Linux 2023. #### Resource limits * DS resource limits now depend on the proxy authorization identity rather than the bind DN. ### DS 7.4.1 DS 7.4.1 is a maintenance release with the following improvements. #### Security * The DS Crypto Manager configuration now has an advanced property, `key-wrapping-mode`, to set the key wrapping mode for protecting symmetric keys. When using a FIPS-compliant security provider that doesn't allow direct encryption, change the Crypto Manager configuration to set `key-wrapping-mode: WRAP`. #### Tools * The `supportextract` command now includes the system hostname in the name of the archive file. ### DS 7.4.0 #### HDAP This release introduces the **H**TTP **D**irectory **A**ccess **P**rotocol (HDAP) API for HTTP access to LDAP data. Interface stability: [Technology Preview](stability.html) HDAP enables web-based HTTP applications and services to interact with LDAP directories. It uses HTTP as the transport protocol and JSON as the data format, making directory data easy to access and use in web applications. With HDAP, web-based systems and LDAP directories communicate and integrate simply and easily. HDAP exposes the full hierarchical object-oriented data model of DS with the following benefits: * Supports all features of the LDAP protocol and many extensions * Simplifies configuration; no complex data mappings * Manages LDAP schema as data * Lets applications validate resources using their JSON schema * Opens access to advanced administrative features such as collective attributes, password policy sub-entries, and access controls * Lets applications perform subtree searches and rename resources For details, read [Use HDAP](https://docs.pingidentity.com/pingds/7.4/rest-guide/preface.html). #### Access logs * DS log messages now include `elapsedQueueingTime`, the time the request waited in the queue, and `elapsedProcessingTime`, the time actively processing the request. For details, refer to [About logs](https://docs.pingidentity.com/pingds/7.4/logging-guide/about-logs.html). Use the following new access log filtering criteria for logs targeting outliers: * `response-etime-queueing-greater-than` * `response-etime-queueing-less-than` * `response-etime-processing-greater-than` * `response-etime-processing-less-than` * DS log messages with `additionalItems` fields now set their additional items to `true` instead of `null`. For example, the message for an unindexed search now includes `"additionalItems":{"unindexed":true}`. * DS can now record the attributes targeted by modification requests. For details, refer to [Log modifications](https://docs.pingidentity.com/pingds/7.4/logging-guide/ldap-access.html#log-common-audit-ldap-json-mods). * DS now logs security information about TLS handshake operations, including the negotiated protocol version and cipher, and the resulting security strength factor (SSF). A new `tls` setting for access log filtering criteria lets you filter on TLS handshakes. For details, refer to [About logs](https://docs.pingidentity.com/pingds/7.4/logging-guide/about-logs.html). * DS access logs messages now include the user-friendly name and criticality for LDAP controls. For request controls, the messages also include the values. For details, refer to [About logs](https://docs.pingidentity.com/pingds/7.4/logging-guide/about-logs.html). #### Debug and error logs * Configuring debug-level logging is simpler with predefined logging categories. For details, refer to [Debug-level logging](https://docs.pingidentity.com/pingds/7.4/maintenance-guide/troubleshooting.html#troubleshoot-enable-debug-logging). #### Monitoring * DS monitoring metrics now include information to help troubleshoot changelog purging: * The LDAP attributes under `cn=monitor` are:\ `ds-mon-changelog-file-count`\ `ds-mon-purge-waiting-for-change-number-indexing` * The Prometheus metrics are:\ `ds_replication_changelog_purge_waiting_for_change_number_indexing`\ `ds_replication_changelog_replica_dbs_changelog_file_count` #### Password policy * DS attribute value password validators with `ds-pwp-attribute-value-check-substrings:true` or `check-substrings:true` now check whether the password contains portions of attribute values *and* whether the attribute values contain portions of the password. #### Collective attributes * DS servers now let you rename collective attributes. For details, refer to [Rename an attribute](https://docs.pingidentity.com/pingds/7.4/config-guide/collective-attrs.html#rename-attr). #### Schema * New DS servers now check certificate lists, certificate pairs, and postal address syntax attributes for validity. The change affects attributes such as `certificateRevocationList`, `crossCertificatePair`, and `postalAddress`. The change doesn't apply to DS servers you upgrade in place. #### Replication * DS servers now log a warning message such as the following when replication status is `Bad data` and the problem seems to be the fractional replication configuration: ``` Replication server RS([.var]####) ignoring update [.var]#### for domain "[.var]####" from directory server DS([.var]####) at [.var]#### because the peer DS reported to be in BAD_DATA status. The generation ID matches, (DS is [.var]####, RS is [.var]####), there may be a problem with fractional replication configuration. Check the DS error logs for more details ``` #### Performance * DS servers now more efficiently process OR filters composed of equality filters using the same attribute types. An example LDAP search filter of this type is `(|(uid=uid1)(uid=uid2)…​(uid=uidN))`, where *N* can be large. #### Security * DS now supports accepting Kerberos authentication requests for more than one service principal. For details, refer to [Authenticate with Kerberos](https://docs.pingidentity.com/pingds/7.4/security-guide/auth.html#auth-kerberos) and the [GSSAPI SASL mechanism handler](https://docs.pingidentity.com/pingds/7.4/configref/objects-gssapi-sasl-mechanism-handler.html) configuration. * DS makes configuring a PKCS#11 HSM key manager easier than before. For details, refer to the example in [PKCS#11 hardware security module](https://docs.pingidentity.com/pingds/7.4/security-guide/pki-hsm.html). #### Native packages * DS Debian and Red Hat packages now use systemd instead of System V init files. For details, refer to [Use the Debian package](https://docs.pingidentity.com/pingds/7.4/install-guide/install-files.html#install-files-deb) or [Use the RPM package](https://docs.pingidentity.com/pingds/7.4/install-guide/install-files.html#install-files-rpm). #### Tools * The `dsconfig` command online help and [Configuration reference](https://docs.pingidentity.com/pingds/7.4/configref/preface.html) now label deprecated and legacy configuration objects and properties. * Many commands with the `--usePkcs11KeyStore` option now also support the following options: * `--providerArg` to specify the provider configuration. * `--providerClass` or `--providerName` to specify the implementation. * All `backendstat list-*` subcommands now display indexes ordered by name. ## DS 7.3 ### DS 7.3.6 DS 7.3.6 is the latest release targeted for DS 7.3 deployments and can be downloaded from the [download page](https://product-downloads.pingidentity.com/browse/ds/all/productId:ds/minorVersion:7.3/version:7.3.6/releaseType:full). The release can be deployed as an initial deployment or updated from an existing DS 7.3.x or earlier deployment. ### DS 7.3.5 #### Disaster recovery * DS servers now support safer disaster recovery procedures you can apply one server at a time. The procedures hinge on the new `dsrepl disaster-recovery` command. For details, refer to the [disaster recovery](https://docs.pingidentity.com/pingds/7.3/maintenance-guide/disaster-recovery.html) documentation. #### Operating systems * This release adds support for Amazon Linux 2023. #### Resource limits * DS resource limits now depend on the proxy authorization identity rather than the bind DN. ### DS 7.3.4 #### Security * The DS Crypto Manager configuration now has an advanced property, `key-wrapping-mode`, to set the key wrapping mode for protecting symmetric keys. When using a FIPS-compliant security provider that doesn't allow direct encryption, change the Crypto Manager configuration to set `key-wrapping-mode: WRAP`. #### Tools * The `supportextract` command now includes the system hostname in the name of the archive file. ### DS 7.3.3 DS 7.3.3 is a maintenance release that does not include new features. ### DS 7.3.2 DS 7.3.2 is a maintenance release that does not include new features. ### DS 7.3.1 DS 7.3.1 is a maintenance release that does not include new features. ### DS 7.3.0 #### Replication * DS servers now send data more efficiently when initializing a replica online, improving the speed of online initialization. This improvement requires that both servers run DS 7.3 or later. * DS replication now distinguishes when a replica requires reinitialization because it has fallen further behind the replication server than allowed by the `replication-purge-delay`. DS sets the `ds-mon-status` attribute for LDAP or `ds_replication_replica_status{status}` for Prometheus to `Too late`. Earlier versions of DS assigned `Bad generation id` status to such replicas. The `dsrepl status` output changed to take advantage of the new status. It now distinguishes the following states for a replicated data set: * `BAD - DATA MISMATCH` Requires reinitialization; verify the replication configuration * `BAD - TOO LATE` Requires reinitialization * `GOOD` Normal operation; nothing to do * `SLOW` Replication delay greater than five seconds #### Groups * DS now uses significantly less memory for the group cache and for entry caches. Revisit Java heap size and database cache settings after upgrading. For details on setting heap and cache sizes, refer to [Performance tuning](https://docs.pingidentity.com/pingds/7.3/maintenance-guide/tuning.html). * DS now more effectively reads and updates entries with attributes having many values, such as LDAP and POSIX group entries. DS entry caches are no longer necessarily required for these entries. If you have [enabled entry caches for large groups](https://docs.pingidentity.com/pingds/7.3/maintenance-guide/tuning.html#perf-entry-cache), consider removing them after upgrade. * DS monitoring metrics now include counts of static, dynamic, and virtual static groups, and statistics on the distribution of group sizes. For details, refer to [Groups (Prometheus)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/http-monitoring.html#monitoring-groups-http) and [Groups (LDAP)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/ldap-monitoring.html#monitoring-groups-ldap). #### Indexing | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | When you upgrade DS directory servers in place, you must rebuild all indexes. The rebuilt indexes reflect required string normalization fixes.If possible, trigger this rebuild during in place upgrade. Normal operations can result in degraded index errors until you rebuild the indexes. | * DS servers now let you monitor index cost, which enables you to determine which indexes are causing write contention. For details, refer to [Index cost](https://docs.pingidentity.com/pingds/7.3/config-guide/idx-what.html#index-cost). * DS servers now support a new matching rule, making it easier to monitor progress when migrating passwords to a new storage scheme. For an example, refer to [Eliminate reversible password storage](https://docs.pingidentity.com/pingds/7.3/upgrade-guide/after-you-upgrade.html#eliminate-deprecated-passwords). * DS servers now display a message when you configure an unnecessary presence index for an attribute that already has an equality index DS can use for presence searches. DS servers also display the message at startup. #### Monitoring * DS monitoring for Prometheus now includes a metric for replica status. For details, refer to [Replication status (Prometheus)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/http-monitoring.html#monitoring-replication-status-http). * DS monitoring metrics now include counts global and entry ACIs, and of the number of entries with ACIs. For details, refer to [ACIs (Prometheus)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/http-monitoring.html#monitoring-acis-http) and [ACIs (LDAP)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/ldap-monitoring.html#monitoring-acis-ldap). * DS monitoring metrics now include counts of the memory allocated to entry caches. For details, refer to [Entry cache size (Prometheus)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/http-monitoring.html#monitoring-entry-cache-http) and [Entry cache size (LDAP)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/ldap-monitoring.html#monitoring-entry-cache-ldap). * DS monitoring metrics now include a count of LDAP subentries. For details, refer to [Subentries (Prometheus)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/http-monitoring.html#monitoring-subentries-http) and [Subentries (LDAP)](https://docs.pingidentity.com/pingds/7.3/monitoring-guide/ldap-monitoring.html#monitoring-subentries-ldap). * DS monitoring metrics now include information to help troubleshoot change number indexing: * The Prometheus metrics are:\ `ds_change_number_indexing_state`\ `ds_change_number_time_since_last_indexing_seconds` * The LDAP attributes under `cn=monitor` are:\ `ds-mon-indexing-state`\ `ds-mon-replicas-preventing-indexing`\ `ds-mon-time-since-last-indexing` When the indexing state is not `INDEXING`, also read the replication logs for warning messages with additional details. * The metrics counting the number of indexed and unindexed searches have been renamed `ds-mon-backend-filter-indexed` and `ds-mon-backend-filter-unindexed`, and are now always maintained, even when index filter analysis is disabled. #### Logging * DS servers can now produce error messages in JSON format. For details, refer to [Log error messages as JSON](https://docs.pingidentity.com/pingds/7.3/logging-guide/manage-logs.html#log-error-json). #### LDAP * DS servers now compare `userCertificate` attribute values more efficiently. #### Schema * DS servers now allow `mail` addresses to include UTF-8 characters, not just ASCII. The change does not affect directory data but does affect `mail` indexes which may become degraded. When upgrading, you may need to rebuild degraded indexes. For details, refer to [When adding new servers](https://docs.pingidentity.com/pingds/7.3/upgrade-guide/add-new-servers.html) and [Update LDAP schema](https://docs.pingidentity.com/pingds/7.3/upgrade-guide/after-you-upgrade.html#update-schema). #### Tools * The `modrate` command now includes new options for adding and replacing values of multivalued attributes. This lets you use the command to simulate more realistic workloads. Previously, `modrate` only supported single-valued replace updates. The new options are: * `--strategy (modify|read_modify)` Set this option to `--strategy read_modify` to use the new feature, reading an entry, then modifying it by deleting and adding attribute values. The default, `--strategy modify`, uses single-valued replace updates as before. * `--valueCount number` Set this option to specify how many attribute values the multivalued attribute should contain following the modify operation. The *number* default is 1. * `--mvcc attribute` Optionally set this option to specify the *attribute* to use for MVCC. Default: `--mvcc eTag`. For details, refer to the [modrate](https://docs.pingidentity.com/pingds/7.3/tools-reference/modrate.html) reference page. ## DS 7.2 ### DS 7.2.5 DS 7.2.5 is the latest release targeted for DS 7.2 deployments and can be downloaded from the [download page](https://product-downloads.pingidentity.com/browse/ds/all/productId:ds/minorVersion:7.2/version:7.2.5/releaseType:full). You can deploy this release as an initial deployment or use it to update an existing DS 7.2.x deployment. #### Disaster recovery * DS servers now support safer disaster recovery procedures you can apply one server at a time. The procedures hinge on the new `dsrepl disaster-recovery` command. For details, refer to the [disaster recovery](https://docs.pingidentity.com/pingds/7.2/maintenance-guide/disaster-recovery.html) documentation. #### Resource limits * DS resource limits now depend on the proxy authorization identity rather than the bind DN. ### DS 7.2.4 #### Security * The DS Crypto Manager configuration now has an advanced property, `key-wrapping-mode`, to set the key wrapping mode for protecting symmetric keys. When using a FIPS-compliant security provider that doesn't allow direct encryption, change the Crypto Manager configuration to set `key-wrapping-mode: WRAP`. ### DS 7.2.3 DS 7.2.3 is a maintenance release that doesn't include new features. ### DS 7.2.2 DS 7.2.2 is a maintenance release that doesn't include new features. ### DS 7.2.1 DS 7.2.1 is a maintenance release that does not include new features. ### DS 7.2.0 #### Backup * DS servers now support Amazon AWS temporary credentials when backing up and restoring data using S3. You set the AWS session token using the `s3.sessionToken.env.var` storage property. For example, first set the session token as the value of the `AWS_SESSION_TOKEN` environment variable, then use `--storageProperty s3.sessionToken.env.var:AWS_SESSION_TOKEN` in the `dsbackup` commands. For additional examples, refer to [Cloud storage](https://docs.pingidentity.com/pingds/7.2/maintenance-guide/backup-restore.html#cloud-storage). * DS servers now send an alert notification when backup task completes. The new alert types are `org.opends.server.BackupSuccess` and `org.opends.server.BackupFailure`, and are documented in [Alert types](https://docs.pingidentity.com/pingds/7.2/monitoring-guide/alert-notifications.html#alert-types). #### Indexing * DS servers now support *big indexes*. A big index is a new kind of index optimized for attributes with few unique values. Big indexes let users more easily page through all the users in a US state, for example. For details, refer to [Big index](https://docs.pingidentity.com/pingds/7.2/config-guide/indexing.html#big-indexes) and [Indexes for attributes with few unique values](https://docs.pingidentity.com/pingds/7.2/config-guide/indexing.html#use-big-indexes). * DS servers now let you monitor index use, so you can determine which indexes are unused. For details, refer to [Unused indexes](https://docs.pingidentity.com/pingds/7.2/config-guide/indexing.html#unused-indexes). * DS servers now support a DN pattern matching rule that lets you index an attribute with DN values, and search with wildcard characters, so you can find matches for specific RDNs in the DN, for example. For details, refer to [DN patterns](https://docs.pingidentity.com/pingds/7.2/ldap-guide/search-ldap.html#dn-pattern-matching). * DS servers have improved output for debugging search indexes. For examples, refer to [Debug search indexes](https://docs.pingidentity.com/pingds/7.2/config-guide/indexing.html#debug-search). (As explained there, the format of `debugsearchindex` values is not a stable public interface, because it is intended for human beings, not scripts.) * The output for the `backendstat list-indexes` and `backendstat show-index-status` commands is easier to read and to understand. * DS servers now optimize searches for unresolved conflicts. * DS servers now more efficiently optimize searches for initial substrings. #### Logging * DS servers now include `entrySize` in access log messages. You can filter access logs based on minimum entry size with the log filtering criteria setting, `response-entry-size-greater-than`. For details, refer to [About logs](https://docs.pingidentity.com/pingds/7.2/logging-guide/about-logs.html). * By default, DS servers are configured to manage log file retention and rotation. For details on configuring this, refer to [Rotate and retain logs](https://docs.pingidentity.com/pingds/7.2/logging-guide/manage-logs.html#log-rotation). When an external program is also configured to manage DS log files, and moves or deletes log files in a way that a DS server does not expect, the DS now detects the change and logs an error message. Either let the DS server manage its log files, or configure an external program to do so, not both. #### Monitoring * DS monitoring now takes replication listener threads into account when calculating whether a server is healthy. Monitoring shows a server to be in a healthy state if the server is alive, the replication server is accepting connections on the configured port, and any replication delays are below the configured threshold. * DS servers now support histogram metrics, as described in [Metric types reference](https://docs.pingidentity.com/pingds/7.2/monitoring-guide/monitoring-types.html). As indicated in [LDAP metrics reference](https://docs.pingidentity.com/pingds/7.2/monitoring-guide/monitoring-metrics-ldap.html) and [Prometheus metrics reference](https://docs.pingidentity.com/pingds/7.2/monitoring-guide/monitoring-metrics-prometheus.html), DS servers expose the following histogram monitoring metrics: * LDAP `ds-mon-backend-entry-size-read`\ `ds-mon-backend-entry-size-written` * Prometheus `ds_backend_entry_size_read_bucket{backend,type,le}`\ `ds_backend_entry_size_written_bucket{backend,type,le}` * DS servers now let the monitor user read monitoring information over HTTP when some backends are offline, as long as backend with the monitor user entry remains online. #### Password storage * DS servers now support hashing passwords with [Argon2](https://www.rfc-editor.org/info/rfc9106) for password storage. For details, refer to [Password Storage](https://docs.pingidentity.com/pingds/7.2/security-guide/passwords.html#configure-pwd-storage). #### Performance * DS servers now generate ETag attribute values more efficiently. This improves the performance of REST to LDAP applications that use ETags for MVCC. The plugin generates real ETag attributes for adds and updates. The server relies on the existing virtual attribute implementation only when a real ETag is not available. The implementation depends on a server plugin that is only configured for new servers. After upgrading all servers, configure the plugin on each server to use the new feature. For details, refer to [Use the entity tag plugin for ETags](https://docs.pingidentity.com/pingds/7.2/upgrade-guide/after-you-upgrade.html#upgrade-etag-implementation). * DS servers now more efficiently verify passwords stored with PKCS5S2. * DS servers now run the `rebuild-index` command more efficiently when you identify specific indexes to rebuild. They also now run the `rebuild-index --rebuildDegraded` command more efficiently when there are no indexes to rebuild. * DS servers now start up more quickly when there are large numbers of groups. When the server starts, it runs an internal search to find all groups. DS servers now maintain a big index for `objectClass` that is specific to groups. In previous versions, the search for groups at startup could be unindexed. The workaround was to raise the index entry limit for the `objectClass` index, with the tradeoff of maintaining indexes for more object classes, and impacting write performance. The workaround is no longer necessary for new servers. Upgrading does not change the server configuration, however, so the index is not present after you upgrade. If you have applied the workaround of raising `index-entry-limit` for `objectClass`, and have upgraded your servers: 1. Install a new, throwaway server with the evaluation profile, as described in [Install DS for evaluation](https://docs.pingidentity.com/pingds/7.2/install-guide/setup-ds.html). 2. Review the configuration for the `big-equality` index for `objectClass`. For example: ``` dsconfig get-backend-index-prop --backend-name dsEvaluation --index-name objectClass --offline ``` 3. For your upgraded servers, consider adding a `big-equality` index for the groups, lowering `index-entry-limit` for `objectClass`, and rebuilding the `objectClass` indexes. Server startup time should be just as good, and write performance might improve. #### Proxy * DS servers now support the [Proxy Protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) from HAProxy. For details, refer to [Proxy protocol](https://docs.pingidentity.com/pingds/7.2/config-guide/proxy-protocol.html). * The proxy backend settings to regularly contact remote LDAP servers now offer additional configuration for more fine-grained control when keeping connections alive and checking remote server availability. For details, refer to [Proxy backend](https://docs.pingidentity.com/pingds/7.2/configref/objects-proxy-backend.html). #### Replication * DS replication servers now check that the port is available when you change the configuration. #### REST to LDAP * When you perform a paged results query whose corresponding LDAP search is indexed, the response now contains an estimated number of `"totalPagedResults"`, and `"totalPagedResultsPolicy" : "ESTIMATE"`. For an example, refer to [Paged results](https://docs.pingidentity.com/pingds/7.2/rest-guide/query-rest.html#query-rest-paged-results). * When you perform a query, you can now request the resource count only, using the new `_countOnly` query string parameter. REST to LDAP returns the count, and not the resources. This parameter requires protocol version 2.2 or later. Use a header like `Accept-API-Version: protocol=2.2,resource=1.0`, for example. For details, refer to [Query](https://docs.pingidentity.com/pingds/7.2/rest-guide/rest-operations.html#about-crest-query). * When converting JSON values, REST to LDAP now coerces: * Strings to booleans, integers, or JSON where possible. * Whole floating point numbers to integers. REST to LDAP also returns helpful errors when coercion fails. This improves interoperability with client applications that don't or can't perform the conversions before adding or updating resources. * The REST to LDAP gateway settings now let you configure: * Availability checks for load balancing. The default heartbeat check settings have also been changed to check that pooled connections are alive every five minutes with a three-second keep-alive heartbeat timeout. * As many pools of failover servers as needed. You specify the pools using the `"failoverLdapServers"` field. The gateway still accepts `"primaryLdapServers"` and `"secondaryLdapServers"` settings for compatibility. * A connection timeout. For details regarding these new settings, refer to [LDAP connection factories](https://docs.pingidentity.com/pingds/7.2/rest-guide/rest2ldap.html#config-json-ldapConnectionFactories). * Internally, REST to LDAP now simplifies search filters when possible. This can improve search performance. REST to LDAP removes redundant `objectClass` assertions from search filters, retaining specific classes, but removing the superclasses they inherit from. For example: ``` (&(objectClass=top)(objectClass=person)(objectClass=organizationalPerson) ``` Becomes: ``` (objectClass=organizationalPerson) ``` * REST to LDAP now updates single-valued LDAP attributes by replacing the value, which reduces the network bandwidth and historical change data needed to replicate the update. #### Schema * The schema definitions in the `db/schema/04-rfc2307bis.ldif` file now align with those of the latest [RFC 2703bis Internet-Draft](https://datatracker.ietf.org/doc/html/draft-howard-rfc2307bis-02), *An Approach for Using LDAP as a Network Information Service*. The change does not affect directory data, but when upgrading you may need to rebuild degraded indexes. For details, refer to [When adding new servers](https://docs.pingidentity.com/pingds/7.2/upgrade-guide/add-new-servers.html) and [Update LDAP schema](https://docs.pingidentity.com/pingds/7.2/upgrade-guide/after-you-upgrade.html#update-schema). #### Security * [PKCS#11 hardware security module](https://docs.pingidentity.com/pingds/7.2/security-guide/pki-hsm.html) now explains how to use an HSM for all asymmetric keys, including the shared master key, for data that is not (yet) encrypted. If you plan to use an HSM for the shared master key, read the documentation carefully *before you install DS*. When you set up the server, you must avoid accidentally encrypting data while using the wrong shared master key. For details, refer to [Store the shared master key](https://docs.pingidentity.com/pingds/7.2/security-guide/pki-hsm.html#hsm-shared-master-key). #### Tools * A new DS `bash-completion` command generates a completion script for the Bash shell that makes it easier to write other DS commands. The completion script depends on support for `bash-completion`, which is not included by default on macOS. To set up Bash completion for DS commands, source the output of the script: * Bash 4 * Bash 3.2 macOS ```bash source <(/path/to/opendj/bin/bash-completion) ``` ```bash # First, install bash-completion support. # Next: eval "$( /path/to/opendj/bin/bash-completion )" ``` You can make completion available in any new interactive shell by adding it to your `~/.bash_profile` file, or `~/.bashrc` file if it is loaded by the new shell. * The new `dskeymgr show-deployment-id` command displays key information about a given deployment ID—​formerly known as a deployment key—​such as the expiration date for the derived CA certificate. For details, refer to [Show deployment ID information](https://docs.pingidentity.com/pingds/7.2/security-guide/key-management.html#show-deployment-id). * The `dsrepl status --showReplicas` command now displays an `Entry count` column. The entry counts in each row reflect the number of entries in the specified replica under the specified base DN. * The `supportextract` command now collects additional system information, including data to indicate whether the system is running in a virtual machine. * When collecting environment variable values, the `supportextract` command now excludes environment variables whose names contain `PASS`, `PWD`, and `_PW`. #### Virtual attributes * DS now lets you create virtual attributes based on the values of non-virtual attributes. For details, refer to [Template-based virtual attributes](https://docs.pingidentity.com/pingds/7.2/config-guide/virtual-attrs.html#virtual-attribute-templates). ## DS 7.1 ### DS 7.1.8 DS 7.1.8 is the latest release targeted for DS 7.1 deployments and can be downloaded from the [download page](https://product-downloads.pingidentity.com/browse/ds/all/productId:ds/minorVersion:7.1/version:7.1.8/releaseType:full). The release can be deployed as an initial deployment or updated from an existing DS 7.1.x or earlier deployment. #### Disaster recovery * DS servers now support safer disaster recovery procedures you can apply one server at a time. The procedures hinge on the new `dsrepl disaster-recovery` command. For details, refer to the *disaster recovery* documentation. ### DS 7.1.7 DS 7.1.7 is a maintenance release and does not include new features. ### DS 7.1.6 DS 7.1.6 is a maintenance release and does not include new features. ### DS 7.1.5 DS 7.1.5 is a maintenance release and does not include new features. ### DS 7.1.4 DS 7.1.4 is a maintenance release and does not include new features. ### DS 7.1.3 #### REST to LDAP * REST to LDAP now updates single-valued LDAP attributes by replacing the value, which reduces the network bandwidth and historical change data needed to replicate the update. ### DS 7.1.2 #### Performance * DS servers now run the `rebuild-index --rebuildDegraded` command more efficiently when there are no indexes to rebuild. #### Tools * The `supportextract` command now collects additional system information, including data to indicate whether the system is running in a virtual machine. * When collecting environment variable values, the `supportextract` command now excludes environment variables whose names contain `PASS`, `PWD`, and `_PW`. ### DS 7.1.1 DS 7.1.1 is a maintenance release that does not include new features. #### Java DS 7.1.1 introduces support for Java 17 (17.0.3 or later) in addition to Java 11: * In Java 17, the PCKS#12 keystore encryption/Mac algorithm has been upgraded to `HmacPBESHA256`. Update to at least Java 11.0.12 if you have an application that runs Java 11 and must read the keystore. * Use G1 GC (the default) instead of parallel GC. The setting is shown in *Java Settings*. Use of ZGC or Shenandoah is not recommended for production deployments at this stage. Learn more in [Java](requirements.html#prerequisites-java). If you are upgrading, refer to *Supported Java*. ### DS 7.1.0 #### Backup * The `dsbackup` command now lets you set a non-default storage provider endpoint. For details, refer to *Cloud Storage*. #### Indexing * The online rebuild index process is now less intrusive, more effective, and more robust. When you run a `rebuild-index` command while the server is online, the backend database remains available for directory operations during the rebuild. Individual indexes do appear as degraded and unavailable while the server rebuilds them. A search request that relies on an index in this state may temporarily fail as an unindexed search. #### Logging * DS log messages now include the authorization ID for every request. * DS servers now support logging the internal delete operations triggered by entry expiration. If you have set the `ttl-age` and `ttl-enabled` properties for a backend, use this feature by configuring an access log publisher to record messages about internal operations. When the server deletes an expired entry, it logs a message with `"additionalItems":{"ttl": null}` in the response. For background, refer to *Entry Expiration*. #### Passwords * Password quality checks using the password quality advice control now ensure that proposed passwords are not in the password history. If the server finds the proposed password in the password history, this appears in the failing criteria returned with the advice response control. In addition, the REST to LDAP response over HTTP now includes the password attribute type. #### Replication * DS servers now let you restrict which replicas you trust to send updates. By default, all directory servers in a replication topology trust all replicas. If a replica allows an update, then other servers relay and replay the update without further verification. This simplifies deployments where you control all the replicas. In deployments where you don't control all the replicas, you can configure replication servers to accept updates only from trusted replicas. The trust depends on the certificate that a replica presents to the replication server when connecting. For details, refer to *Trusted Replicas*. * DS servers now let you define replication group failover. This determines how a directory server selects the next group with replication servers to connect to when no replication server is available in the directory server's own group. To activate replication group failover, set the global configuration property, `group-id-failover-order`. For details on how a directory server chooses a replication server, refer to *Replication Connection Selection*. * When a replica's last change is older than the oldest change recorded in the replication server's changelog, the replication server now records the problem in its log, and sends a message to the replica. When it receives the message, a 7.1 replica remains connected to the replication server, but refuses update operations, effectively becoming read-only. A pre-7.1 replica closes the connection. In any case, the replica no longer applies replication updates. Its data diverges more and more from other replicas' data. Should this happen in your deployment, reinitialize the replica. For details, refer to *Manual Initialization*. * DS servers now log more explicit messages when they discover duplicate server IDs. #### REST to LDAP * This release introduces support for querying fields of `reference` or `reverseReference` resources that are subtypes of the resources you are searching. As an example, suppose that devices and users are both subtypes of a "managed object" type. Also, suppose that devices have a `deviceType` field, that users have a `surname` field, and that a basic managed object has neither of these fields. Now, your queries on a collection of managed objects can match properties of the referenced subtypes, such as `/managedObjects?_queryFilter=deviceType+eq+phone`, or `/managedObjects?_queryFilter=surname+eq+Jensen`. #### Samples * The sample for building custom DS Docker images now has a `USE_DEMO_KEYSTORE_AND_PASSWORDS` setting that simplifies getting started with a basic Docker image on your computer. For details, refer to `opendj/samples/docker/README.md`. #### Security * DS directory and proxy servers now allow access to the root DSE operational attribute `subSchemaSubEntry`. This attribute indicates the entry holding the LDAP schema definitions. Many applications retrieve this attribute, and the associated schema, to properly display or validate attribute values. If you can't upgrade yet, update the configuration of your DS server to grant all users read access to `subSchemaSubEntry` at least on the root DSE: * For DS 7 directory servers, add `subSchemaSubEntry` to the attribute list in the "User-Visible Root DSE Operational Attributes" global ACI. * For DS 7 directory proxy servers, add `allowed-attribute:subSchemaSubEntry` on the `Root DSE access` configuration object. For details on granting access to `subSchemaSubEntry` on entries in directory data, refer to *ACI: Access SubSchemaSubEntry Attribute*. * DS servers now support text-based Privacy-Enhanced Mail (PEM) keys and certificates for server key pairs, master keys, and trusted certificates. For details, refer to *Use PEM-Format Keys*. * The DS `fingerprint-certificate-mapper` now also supports fingerprints without colons. For example, the following SHA-256 fingerprints are equivalent: * `0555BDA5E14C35A6A54E78DD3EFDEA5A665DE0DC9CC5187EE9CAA91ECD874B78` * `05:55:BD:A5:E1:4C:35:A6:A5:4E:78:DD:3E:FD:EA:5A:66:5D:E0:DC:9C:C5:18:7E:E9:CA:A9:1E:CD:87:4B:78` #### Tools * DS command options that have secrets as arguments now support `:env` and `:file` modifier suffixes. For example, if the bind password is stored in a `~/.pass` file, use `--bindPassword:file ~/.pass`. If the password is stored in the environment variable `PASS`, use `--bindPassword:env PASS`. Use the modifiers with the following options to provide the secret in an environment variable (`:env`), or in a file (`:file`): * `--bindPassword[:env|:file]` * `--deploymentKeyPassword[:env|:file]` * `--keyStorePassword[:env|:file]` * `--monitorUserPassword[:env|:file]` * `--rootUserPassword[:env|:file]` * `--set[:env|:file]` (for setup profile parameters) * `--trustStorePassword[:env|:file]` * The `supportextract` command now uses the `jcmd` command, if available, for heap dumps. Otherwise, it uses the `jmap` command. * The `addrate`, `authrate`, `modrate`, and `searchrate` commands now include connection time as part of the response time for a request. ## DS 7.0 ### DS 7.0.2 There are no new features in DS 7.0.2, only bug fixes. DS 7.0.2 is the latest release targeted for DS 7.0.x deployments and can be downloaded from the [download page](https://product-downloads.pingidentity.com/browse/ds/all/productId:ds/minorVersion:7/version:7.0.2/releaseType:full). The release can be deployed as an initial deployment or updated from an existing DS 7.0.x deployment. ### DS 7.0.1 * The DS password synchronization plugin for IDM now supports OAuth 2.0 access token bearer authentication. For details, refer to *Synchronize Passwords With ForgeRock Directory Services (DS)* in the IDM documentation. * DS command options that have secrets as arguments now support `:env` and `:file` modifier suffixes. Use these with the following options to provide the secret in an environment variable (`:env`), or in a file (`:file`): `--bindPassword[:env|:file]`\ `--deploymentKeyPassword[:env|:file]`\ `--keyStorePassword[:env|:file]`\ `--monitorUserPassword[:env|:file]`\ `--rootUserPassword[:env|:file]`\ `--set[:env|:file]` (for setup profile parameters)\ `--trustStorePassword[:env|:file]` For example, if the bind password is stored in a `~/.pass` file, use `--bindPassword:file ~/.pass`. If the password is stored in the environment variable `PASS`, use `--bindPassword:env PASS`. * The `supportextract` command now uses the `jcmd` command, if available, for heap dumps. Otherwise, it uses the `jmap` command. (Issue: OPENDJ-7662) ### DS 7.0.0 #### Access control ##### Aliases for controls and extended operations DS 7.0.0 supports use of aliases in addition to OIDs for LDAP controls and extended operations in ACIs, making those ACIs significantly more human-readable. For details, refer to *Directory server ACIs*. Since previous releases support only OIDs, only use aliases in ACIs after upgrading all directory servers. Otherwise, older servers will log warning messages for the unrecognized aliases, such as the following: ```none Access Control Instruction (ACI) targetcontrol expression value "value" is invalid. A valid targetcontrol keyword expression value requires one or more valid control OID strings in the following format: oid [|| oid1] ... [|| oidN] ``` #### Authentication ##### Multiple identity mappers The following configuration objects can now reference multiple identity mappers: * *CRAM-MD5 SASL mechanism handler* * *DIGEST-MD5 SASL mechanism handler* * *GSSAPI SASL mechanism handler* * *HTTP Basic authorization mechanism* * *HTTP OAuth2 authorization mechanism* * *Password modify extended operation handlers* * *PLAIN SASL mechanism handler* * Global configuration, `proxied-authorization-identity-mapper` When resolving the identity, the server uses the first identity mapper that finds a match. If multiple identity mappers match different entries, however, then the server returns LDAP error code 19, Constraint Violation. For background information, refer to *Identity mappers*. #### Backup and restore ##### New, simplified implementation with cloud storage support The release provides a new, simplified implementation for DS backup and restore operations: * The new implementation replaces backup archives with collections of backup files. The collection includes backend files and backup metadata. The files always follow the same layout, regardless of what you back up. You manage backup files by retaining an entire backup directory. You are no longer required to use a separate backup directory for each backend. * You can now stream backup files directly to cloud storage, and restore directly from cloud storage. * You no longer have to make a choice between full and incremental backup operations. Backup operations are incremental by design. When you reuse the same backup directory, the process only backs up new data. * The new implementation includes a `purge` subcommand for removing old backup files. You can purge old files either as an external command, or as a server task. * In the event of a disaster, you can restore from a backup directory stored off-site using only the deployment key and password, and a backup copy of the server configurations. The new implementation protects (encrypts) the backup encryption keys with the shared master key. It stores the encrypted encryption keys in the backup files. You no longer need to configure replication between new replicas and a server from the existing topology. Instead, you first set up replacement replicas with the deployment key and password, restoring the backed up server configurations to match those servers lost in the disaster. You then restore the data using the off-site backup directory. * The new implementation always signs and verifies the integrity of backups, and always encrypts backup files. The new implementation encrypts the keys used for signing and encryption with the shared master key. It stores the encrypted keys in the backup files. You can verify the integrity and ability to decrypt backups before restoring a backend. * The new implementation makes it possible to list and verify backups while the server is online. * The new implementation improves restore performance compared to restore of incremental backups in previous versions. The previous implementation restored files from the full backup archive, and then restored files from each incremental backup archive. Files could be restored and then removed, or restored multiple times. The new implementation only restores one version of each file in the backup directory. * A new command, `dsbackup`, replaces the `backup` and `restore` commands. The `dsbackup` command performs operations formerly performed using separate commands: * `dsbackup create` performs backup operations. * `dsbackup list` displays a summary of available backups, and lets you verify them. * `dsbackup purge` removes old backup files. * `dsbackup restore` performs restore operations. * The new `dsbackup restore` command has a `--backendName` option, which lets you restore only the specified backend. For examples, refer to *Backup and restore*. #### Cloud deployments ##### Ready for Docker and Kubernetes DS 7.0.0 lifts restrictions on running DS servers in Docker and Kubernetes deployments. Many individual improvements make this possible, including the following: * Replication improvements let you scale the number of DS replicas in your stateful sets up and down. * The new `dsrepl` command runs well in Docker containers. ForgeRock supports customers deploying DS in Docker containers and Kubernetes platforms. To get started, try the following: * Use the `forgeops` repository and the unsupported, evaluation-only base images for the Ping Identity Platform. The images are available in ForgeRock's public Docker registry. * Build your own sample DS Docker image. Unpack the .zip distribution, then refer to the `opendj/samples/docker/README.md` file for instructions. #### Collective attributes ##### Relative parent support DS servers now support specifying the relative parent in collective attribute subentries. For details, refer to *Inherit from a parent entry*. #### Data storage ##### Shared database cache by default By default, DS servers now share cache memory among JE database backends. The server keeps JE database internal and leaf nodes in the database heap cache. For existing servers, the `upgrade` command does not change the database cache behavior. Consider setting the global property `je-backend-shared-cache-enabled:true`, and the JE backends' properties `db-cache-mode:cache-ln` after upgrade. For details, read about the following: * *Database cache settings* * *Java settings* * `je-backend-shared-cache-enabled` * `db-cache-mode` ##### Newer JE DS 7.0.0 upgrades JE backend databases to Berkeley DB Java Edition 18.3.12. | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Different DS server versions continue to replicate data during the upgrade process. However, the JE upgrade has the following implications for the portability of local DS data. Once you upgrade the data in a JE backend database:- You can't downgrade a directory server without also restoring JE backend data from a pre-upgrade server. - You can't restore backups of an upgraded JE backend on a pre-upgrade directory server. | In addition, several JE backend properties that affect cache sizing and database maintenance can now be changed at runtime without restarting the backend. For details, refer to *JE backend*. #### Data encryption ##### Portable encrypted data DS servers now store symmetric keys, encrypted with the shared master key, with the data they encrypt. It is no longer necessary for disaster recovery to maintain a file system backup of a server from each replication topology in your deployment. It is now sufficient to keep the backup directory and a means to recover the shared master key. As long as a server has the same shared master key as the server that encrypted the data, it can recover symmetric keys needed to decrypt data. Be aware that this feature is new, and not provided in previous versions of DS software. Replication is fully compatible with previous server versions, but backup files are not. *For this feature to work, you must use a backup from an upgraded or new server.* ##### GCM with AES DS directory servers now support Galois/Counter Mode (GCM) with AES for encrypted data confidentiality. GCM is efficient and improves integrity protection for encrypted backend data. Set the data encryption cipher transformation, as described in *Data encryption*. The default setting for the backend property `cipher-transformation` is now `AES/GCM/NoPadding`. #### Email notifications ##### Secure, authenticated connections Email notifications now support SMTP authentication and use of TLS. For details, refer to *Send account status mail* and *Mail server*. #### Interoperability ##### Microsoft AD range retrieval support DS software now supports the `*` character in malformed attribute options for interoperability with the Microsoft Active Directory "range retrieval" mechanism. #### Logging ##### Field whitelisting ForgeRock Common Audit loggers now whitelist all fields that are safe to log by default. The whitelist is processed before the blacklist, so blacklist settings overwrite the whitelist defaults. For details, refer to *Allow log message fields*. ##### Error messages to standard output DS servers can now send error messages to standard output. For details, refer to *Log errors to standard output*. ##### More information about operations in access logs DS servers now record additional information about LDAP operations in access log messages: * For LDAP bind operations, the security strength factor (SSF) negotiated for secure client connections appears in the `response` field of the access log message: ``` {..."request":{"protocol":"LDAPS","operation":"BIND"...}..."response":{..."additionalItems":"ssf=128"},...} ``` * For persistent searches, the log messages include `"additionalItems":"persistent"`. ##### Details when a connection handler fails to start When a connection handler fails to start, DS servers now log an error message indicating the cause. #### Monitoring ##### Monitor account replicated by default DS servers now replicate the monitor user created at setup time (default DN: `uid=monitor`). This lets commands like `dsrepl status` use the same account credentials to retrieve monitoring information from all servers. You can use the account in the same way for multi-server monitoring operations. #### Networking ##### Advertised listen address DS servers now have a new, required, global property, *advertised-listen-address*. This setting specifies the hostname or IP address that clients should use for connecting to the server. The `advertised-listen-address` can be multi-valued in systems with multiple network interfaces. DS servers also now have a global property, *listen-address*. The `listen-address` property can be set to the wildcard IP address, `0.0.0.0`, but the `advertised-listen-address` property can't. By default, replication and connection handlers inherit their settings for listen addresses from these global properties. This improvement lets DS servers make fewer DNS requests than before. When setting up a new server, the `setup` command sets the `advertised-listen-address` property to the IP address or the FQDN provided as the `--hostname` argument. During upgrade, the value for the `advertised-listen-address` property is assigned using the hostname derived from administrative data under `cn=admin data`. If any `listen-address` properties are set to the same value, then those settings are removed during upgrade, and the values are inherited instead. #### Passwords ##### SCRAM SASL support DS software now supports Salted Challenge Response Authentication Mechanism (SCRAM) SASL binds. A SASL SCRAM mechanism provides a secure alternative to transmitting plaintext passwords during binds. It is an appropriate replacement for DIGEST-MD5 and CRAM-MD5. With a SCRAM SASL bind, the client must demonstrate proof that it has the original plaintext password. During the SASL bind, the client must perform computationally intensive processing to prove that it has the plaintext password. This computation is like what the server performs for PBKDF2, but the password is not communicated during the bind. Once the server has stored the password, the client pays the computational cost to perform the bind. The server only pays a high computational cost when the password is updated, for example, when an entry with a password is added or during a password modify operation. A SASL SCRAM mechanism therefore offers a way to offload the high computational cost of secure password storage to client applications during authentication. Passwords storage using a SCRAM storage scheme is compatible with simple binds and SASL PLAIN binds. When a password is stored using a SCRAM storage scheme, the server pays the computational cost to perform the bind during a simple bind or SASL PLAIN bind. The SCRAM password storage scheme must match the SASL SCRAM mechanism used for authentication. In other words, SASL SCRAM-SHA-256 requires a SCRAM-SHA-256 password storage scheme. SASL SCRAM-SHA-512 requires a SCRAM-SHA-512 password storage scheme. DS software offers the following in the configuration for new servers: | Password Storage Scheme | SASL Mechanism | | ----------------------- | --------------- | | `SCRAM-SHA-256` | `SCRAM-SHA-256` | | `SCRAM-SHA-512` | `SCRAM-SHA-512` | For additional information, refer to *Password storage* for the server, and *LDAP connection factories* for the REST to LDAP gateway. ##### Full-featured, replicated password policies DS servers now support LDAP subentry password policies that match all features available in per-server password policies. Servers store subentry policies in the directory data, and therefore replicate them. This improvement significantly simplifies password policy management across multiple replicas. For details, refer to *DS subentry password policies*. Many samples in the documentation now demonstrate features of the improved subentry password policies. ##### Stronger password storage schemes DS servers now support additional password storage schemes, `PBKDF2-HMAC-SHA256` and `PBKDF2-HMAC-SHA512`. The new password storage schemes use SHA-256 and SHA-512 hash-based message authentication code settings. The `PBKDF2` password storage scheme uses SHA-1. To migrate passwords to a new storage scheme, refer to *Deprecate a password storage scheme*. ##### 128-bit salt Salted hashed password storage schemes now use 128-bit salt when generating a hash. This change applies to the following password storage schemes: `PBKDF2`\ `PBKDF2-HMAC-SHA256`\ `PBKDF2-HMAC-SHA512`\ `Salted MD5`\ `Salted SHA-1`\ `Salted SHA-256`\ `Salted SHA-384`\ `Salted SHA-512` ##### Rehash passwords You can now configure BCrypt and PBKDF2-based password storage schemes to recalculate password hashes after the iterations settings are changed. DS servers recalculate and store an account's password hash when the user binds successfully with their password. For details regarding BCrypt and PBKDF2-based schemes, refer to the reference for the property `rehash-policy`. ##### Password quality advice DS servers support a new control to request password quality advice when changing a password. Should the request fail due to low password quality, the response control indicates which password validator settings led to the failure. The `ldappasswordmodify` and `ldapmodify` commands support the new control. Use them to test and debug password policy validation settings. The new LDAP control has interface stability *Evolving*. It may be removed in a future release, or replaced with a more general mechanism. For details, refer to *Check password quality* (LDAP), and *Check password quality* (REST). #### Performance ##### Faster export The `export-ldif` command can now complete an export up to twice as fast as before. This improvement is particularly useful with large data sets including tens or hundreds of millions of entries. ##### Faster REST to LDAP performance DS servers now perform better for REST to LDAP searches, and operations that rely on ETags for MVCC. #### Proxy ##### Mutual TLS with LDAP servers The `setup` command now lets a proxy backend bind to remote servers with mutual TLS. The setup profile for a proxy server configures the server to use mutual TLS to authenticate when binding to backend servers. As a result, you must provision the key manager for the proxy with the proxy service account keys, and include the certificate in the proxy user account when using the DS proxy server setup profile. For details, refer to *Install a directory proxy*. ##### DS proxied server When setting up new DS replicas, use the `ds-proxied-server` setup profile to prepare the replicas for use with new DS proxy servers. For details, refer to *Install DS for use with DS proxy*. #### REST ##### Path references REST to LDAP mappings now support references by resource paths, simplifying access to all resource fields. REST clients can use this to issue graph-like queries. For example, the following path and query filter returns the groups that Babs Jensen's manager belongs to: ``` /users/bjensen?_fields=/manager/group ``` For an example, refer to *Graph-like queries*. To demonstrate this feature, the sample REST to LDAP mapping now uses resource paths. The configuration is simpler than the configuration with base DN references. For example, this excerpt shows a manager reference from the version that uses a base DN: ```json { "manager": { "type": "reference", "ldapAttribute": "manager", "baseDn": "..", "primaryKey": "uid", "mapper": { "type": "object", "properties": { "_id": { "type": "simple", "ldapAttribute": "uid", "isRequired": true }, "displayName": { "type": "simple", "ldapAttribute": "cn", "writability": "readOnlyDiscardWrites" } } } } } ``` The same manager reference using a resource path now looks like this: ```json { "manager": { "type": "reference", "resourcePath": ".." } } ``` The latter definition ensures access to all fields defined for the referenced resource. ##### Reverse references REST to LDAP mappings now support reverse references. Reverse references are similar to the `isMemberOf` LDAP attribute used for groups. For example, use a reference mapping to list a user's devices, or to list a manager's reports: ```json { "reports": { "type": "reverseReference", "resourcePath": "..", "propertyName": "manager" } } ``` For an example in context, refer to *Reverse references*. ##### Password quality advice REST to LDAP now supports `passwordQualityAdvice` and `dryRun` query string parameters. The `passwordQualityAdvice` parameter relies on the DS LDAP password quality advice control, OID `1.3.6.1.4.1.36733.2.1.5.5`, which users must have access to request. The `dryRun` parameter relies on the LDAP no-op control, OID `1.3.6.1.4.1.4203.1.10.2`. The password quality advice control and the `passwordQualityAdvice` parameter have interface stability: *Evolving*. They may be removed in a future release, or replaced with a more general mechanism. For details, refer to *Check password quality*. ##### Account usability support REST to LDAP now includes an `accountUsability` action. For details, refer to *Account usability action*. ##### SASL EXTERNAL and SASL SCRAM support The REST to LDAP gateway now supports SASL EXTERNAL and SASL SCRAM binds. For details, refer to *LDAP connection factories*. ##### Per-Server password policies over REST DS servers now let you create per-server (configuration-based) password policies over REST. For an example, refer to *Per-server password policies*. #### Replication ##### Replication at setup time The `setup` command now lets you configure replication at setup time. You no longer need to get all peer servers running before configuring replication. The server begins replicating with peer servers when it comes online, and when it can contact the peers. For this reason, the `setup` command no longer starts the server by default. To ensure replication proceeds smoothly from the beginning, *finish configuring the server before starting it for the first time*. These new `setup` command options enable replication: * When you set the `-r, --replicationPort` option, the server runs a replication service and maintains a changelog. If you add local application data at setup time, the server replicates the data with other replicas. There is no need to configure and initialize replication separately. * When you set the `--bootstrapReplicationServer` option, the server contacts the specified replication server(s) to discover peer replicas and replication servers. This option is required when replicating between multiple servers. Use this option multiple times to specify redundant bootstrap servers for availability. Specify the same list of bootstrap servers each time you set up a replica. Your first bootstrap server(s) must have replication ports, because the first bootstrap server(s) must play the replication server role. For examples, refer to *Installation*. ##### New command to manage replication After configuring servers to replicate as part of the setup process, use the new `dsrepl` command to manage replication. For details, refer to *Replication*. ##### String-based server IDs DS 7.0.0 lets you set server IDs to alphanumeric strings, such as `ds1-us-west`. When you set a server ID, take care to choose a relatively short string. The server ID appears in historical data values that include a *change sequence number*. For example, it shows up in monitoring metrics, and in the values of `ds-sync-state` and `ds-sync-hist` attributes in application data on DS replicas. As a result, historical data is potentially easier to interpret, but larger than in previous versions where server IDs were numbers. ##### One server ID per server Servers are now identified by a single, global server ID. For details, refer to `server-id`. For new servers, use the `setup` command to specify the server ID, or accept the generated default string. For existing servers, the `upgrade` command derives the ID in the following way: ##### The command the existing global server ID, if available. ##### Otherwise, the command uses the first server ID found in `cn=admin data`. Other server ID values are no longer used. ##### If replication has not yet been configured, the command generates a new ID for the server. ##### One group ID per server Servers now have a single, global group ID. For details, refer to `group-id`. For existing servers with group IDs, the `upgrade` command determines which ID is used most, and uses that ID as the single, global ID. ##### Replication delay metrics DS 7.0.0 introduces replication receive delay and replay delay monitoring metrics. These metrics provide the best means yet to help you estimate whether the data in your directory server replicas is converging toward a consistent state. For details, refer to *Replication delay (LDAP)*, or *Replication delay (Prometheus)*. ##### Replay performance DS 7.0.0 improves replication replay performance, reduces disk space used by the replication changelog database, and reduces replication delay in deployments under extreme load. ##### Replication of offline LDIF changes Servers now replicate changes made offline to an LDIF backend. The server replicates the offline changes once it starts again. ##### Automatic purge of stale replicas DS 7.0.0 purges out-of-date replicas from the changelog. The replica is purged when it has been out of contact for longer than the replication purge delay. This enables DS servers to eventually discard information about replicas that you have removed from service, for example. You can also use the `dsrepl purge-meta-data` to eliminate stale historical data. For details, refer to *Manual purge*. ##### Exclude domains from changelog indexes DS 7.0.0 introduces a new replication server property to exclude domains from the changelog indexes, `changelog-enabled-excluded-domains`. Use this to prevent applications that read the external change log from having to process update notifications for entries that are not relevant to them. This property eliminates the need for a separate external changelog domain configuration. For an example, refer to *Exclude a domain*. ##### CTS excluded from changelog indexing The `am-cts` setup profile now excludes the CTS base DN from change number indexing. There is no need to update the changelog configuration manually after installing a new DS replica for as a CTS store. ##### More details about unresolved conflicts DS servers now log additional information about naming conflicts, which helps you identify the server that generated the conflicting operation. #### Samples ##### Sample for building custom Docker images The DS server distribution now includes a sample `Dockerfile` and related files for building custom DS Docker images. ##### Updated sample for Grafana and Prometheus The DS server distribution now includes an updated sample monitoring dashboard for use with Grafana and Prometheus. #### Schema ##### Require TRUE or FALSE boolean values DS servers now support an option to require strict compliance for boolean attribute values. By default, DS servers accept a range of values for boolean attributes. For details, refer to `strict-format-boolean`. #### Security ##### Secure by default Default settings for new DS servers are more secure than before. The explicit `--productionMode` option has been removed, as server configurations and profiles are now secure by default. New server installations require: * Secure connections All operations except bind requests and StartTLS requests, and base object searches on the root DSE, require secure connections. This behavior is governed by the global configuration property, `unauthenticated-requests-policy`, which is now set to `allow-discovery`, instead of `allow`, unless the last setup profile applied is the `ds-evaluation` profile. For details on securing connections, refer to *Secure connections*. * Authentication By default, servers deny anonymous access to most LDAP operations, controls, and extended operations. For details on access control, refer to *Access control*. * Additional access policies By default, servers deny access to directory data. You must configure access policies to grant access to directory data. For details on granting access, refer to *Access control*. Only the evaluation setup profile is more lenient. It grants global permission to perform operations over insecure connections, and open access to sample Example.com data. For details, refer to *Install DS for evaluation*. * Stronger passwords Passwords must have at least 8 characters. Common passwords are rejected. For details on changing password policy, refer to *Passwords*. * Permission to read log files Log files are now read/write only by the DS server user. For details on log file permissions, refer to *File permissions*. As the upgrade process preserves the existing configuration, upgraded servers are not affected. ##### Simple private PKI The `setup` and `dskeymgr` commands simplify creation and management of a public key infrastructure (PKI). DS 7.0.0 introduces the concept of a deployment ID and deployment ID password. The deployment ID and password serve as an alternative to a private CA, simplifying evaluation, development, and testing, and managing directory services. They also serve to derive a shared master key to protect secret keys. The deployment ID and password are required as part of the setup process. For details, refer to *Cryptographic keys*. When you use an existing CA, you can continue to use key pairs with CA-signed certificates. For public-facing directory services, you can continue to configure connection handlers with additional key and trust manager providers using certificates signed by a well-known CA. For details, refer to *Key management*. To manage deployment keys, key pairs, CA certificates, and master keys after setting up a server, use the `dskeymgr` command. Many examples in the documentation now demonstrate use of deployment IDs and passwords. ##### Keystores reload without restart DS servers now reload file-based keystores and truststores when their contents change. This lets you rotate certificates and keys without restarting the key manager or trust manager components. ##### Simple key rotation DS 7.0.0 greatly simplifies rotating the key pairs used to secure replication connections. By default, replication now uses the same keys as the other connection handlers. For details on changing key pairs, refer to *Key management*. ##### Alternative PKCS#11 types PKCS#11 key managers and trust managers now let you set the keystore or truststore type. The default type is `PKCS11`. If your JVM supports other types, set the keystore or truststore type with one of the following properties: * `key-store-type` * `trust-store-type` ##### Multiple trust managers The following configuration objects can now reference multiple objects: * *Administration connector* * *HTTP connection handler* * *LDAP connection handler* Use this feature to allow trust for both well-known CAs whose certificates are stored in the JVM truststore, and internal or deployment-specific CAs whose certificates are stored in a separate truststore. ##### Multiple certificate mappers An external SASL mechanism handler can now reference multiple `certificate-mapper` configurations. The server uses the first certificate mapper that finds a successful match. ##### Indexes for certificate attributes When you create a user data backend using the `ds-user-data` setup profile, the setup process now configures equality indexes for the `ds-certificate-fingerprint` and `ds-certificate-subject-dn` attributes. Certificate mappers use these indexes during certificate-based authentication. ##### Richer access log messages DS servers now record additional items in access log messages when multiple password policy subentries apply to a user. The messages are logged only for bind, add, and modify operations. The messages show the DN of the user having more than one applicable policy, and the DN of the policy the server actually used for the operation. The server logs a message such as the following for a bind request with two conflicting policies: ``` "additionalItems":{"pwdpolicywarning":"Found 2 conflicting password policy subentries for user , used ","ssf":"0"} ``` As described in *Assign password policies*, you must not assign more than one password policy to the same account. #### Tools ##### New setup-profile command A new command, `setup-profile`, enables configuration of setup profiles following initial installation. Use the `setup-profile` command when the server is offline. This command is intended for use in DevOps deployments where you apply additional configuration to a base image that is the same for all deployments. If you have changes that apply to each server you set up, you can create and maintain your own setup profile. For details, refer to *Setup profiles*. ##### Configurable domains and base DNs All `setup` command profiles, except the `ds-evaluation` profile, now allow you to set the domain or the base DN. For details, refer to *Setup profiles*. ##### Generate systemd service files The `create-rc-script` command now produces a `systemd` service file when you use the `--systemdService` option. ##### Generate user entries for evaluation The `ds-evaluation` setup profile now lets you generate an arbitrarily large number of similar user entries. By default, the profile adds 100,000 generated users in addition to users previously included, such as Babs Jensen and Kirsten Vaughan. Each user entry has a `uid` RDN like `user.number`. Each user entry's password is `password`. The capability replaces the `setup` command option `-d, --sampleData`. ##### Proxied authorization for rate tools The `addrate`, `modrate`, and `searchrate` commands now support proxied authorization with the `-Y, --proxyAs {authzID}` option. ##### Support for formatted integers Formatted integers can now be supplied to some integer arguments, making commands easier to read. When setting the number of generated sample entries as an argument to the `setup` command, and when setting integer arguments for the `addrate`, `authrate`, `modrate`, and `searchrate` commands, you can now use formatted integers. For example, the following are equivalent to `10000000`: `10,000,000`\ `10.000.000`\ `"10'000'000"`\ `10_000_000`\ `"10 000 000"` Templates for the `makeldif` command can also accept formatted integers for numbers declared in a subordinate template. ##### Task management The `manage-tasks` command now has `--status` and `--type` options. When used with the `--summary` option, these options filter the list to include only tasks of the specified type and status. The option arguments are case-insensitive, and must be provided in the JVM locale. For example, to list only unscheduled tasks on a JVM with the French locale, use `--status "non planifié"` instead of `--status unscheduled`. ##### Set task IDs and descriptions When you schedule a task, you can now set its identifier with the `--taskId` option, and its description with the `--description` option. The identifiers and descriptions appear in output and messages that describe the task. These new options are especially useful for recurring tasks. Use the task identifier when managing the task in subsequent commands, for example. ##### No changes when reading JE backends offline The following tools now never write to JE backend databases when reading JE information: * `backendstat` * `export-ldif` * `verify-index` ##### Status output improvements The `status` command now displays the same types of information independently of the server configuration, and regardless of whether the command runs in online or offline mode. The command still displays more detailed information in online mode than in offline mode. ##### Supportextract improvements * The `supportextract` command now also collects: * The directory superuser and monitor user account files. * The archived configuration files. * The profile and backend database version files. * Information about the changelog database. * The `server.out` log file before capturing stack traces. * The server PID in a message in the tool's log. * The `cpuinfo`, `meminfo`, `slabinfo`, and `buddyinfo` files on Linux systems. * Stack traces with `jcmd` tool, falling back to the `jstack` tool, and then to `sigquit` (or `kill -3` on Linux) as necessary. * Environment variables used in configuration expressions. * The extract generated by the tool is now compatible with the Java 11 JVM unified logging framework. ##### Byte-by-byte LDIF comparisons The `ldifdiff` command now supports a new `-x, --exactMatch` option for byte-by-byte LDIF comparisons. This is useful for comparing LDAP schema files, for example. ## DS 6.5 ### DS 6.5.6 DS 6.5.6 is the final release targeted for DS 6.5.x deployments and can be downloaded from the [download page](https://product-downloads.pingidentity.com/browse/ds/all/productId:ds/minorVersion:6.5/version:6.5.6/releaseType:full). DS 6.5.6 can be deployed as an initial deployment or updated from an existing DS 6.5.x deployment. * The `supportextract` command now collects environment variables used in configuration expressions. ### DS 6.5.5 * DS servers now more effectively calculate reservable memory when using G1 garbage collection, and reduce the risk of long `fsync` pauses. This change introduces a `ds-mon-db-cache-size-total` metric to track the maximum size of the database cache. It also changes the `ds-mon-db-log-size-active` metric to reflect only live data. * The `supportextract` command now uses the `jcmd` command, if available, for heap dumps. Otherwise, it uses the `jmap` command. ### DS 6.5.4 There are no new features introduced in DS 6.5.4, only bug fixes. ### DS 6.5.3 DS servers now support storing the `ads-certificate` key pair and peer DS servers' trusted public keys in a PKCS#11 module, such as a hardware security module (HSM). This means you can store the keys used to secure replication traffic and to protect symmetric keys in an HSM. Previously, DS servers supported use of a PKCS#11 module only to store the keys used to secure other communications. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | DS servers support PKCS#11 modules through the JVM. How to configure the JVM to allow DS servers to use your module, how to generate keys in the module, and how to export and import public key certificates all depend on your specific HSM/PKCS#11 module.For details on how to perform such actions, refer to your PKCS#11 module's documentation. | Before trying this feature, perform these tests: * Test that the PKCS#11 module supports multiple aliases for the same certificate. * Test that the PKCS#11 module supports generating a key pair with an RSA self-signed certificate and a key size of 2048 bits. * Test the replication topology using the default JKS `ads-truststore` implementation. Verify that replication functions properly *before* using the PKCS#11 module. After validating the results of the tests, use the new feature by performing these steps for each server: 1. Configure JVM security to enable use of the PKCS#11 module for the server. 2. Generate a key pair using an RSA self-signed certificate and a key size of 2048 bits with the alias `ads-certificate` on the PKCS#11 module. 3. After generating the key pair: 1. Export the `ads-certificate` certificate, and reimport it on the PKCS#11 module using the MD5 fingerprint as the certificate alias. For example, if the `ads-certificate` certificate MD5 fingerprint is `07:35:80:D8:F3:CE:E1:39:9C:D0:73:DB:6C:FA:CC:1C`, reimport the certificate with the alias `073580D8F3CEE1399CD073DB6CFACC1C`. 2. Prepare LDIF to update `cn=admin data` for the new certificate. The LDIF adds the new certificate as an instance key, and sets the key ID for the current server to use the key. In the following example LDIF, the certificate alias is `073580D8F3CEE1399CD073DB6CFACC1C`, and the server *hostname*:\_admin-port\_ combination is `opendj.example.com:4444`: ```ldif dn: ds-cfg-key-id=073580D8F3CEE1399CD073DB6CFACC1C,cn=instance keys, cn=admin data changetype: add ds-cfg-key-id: 073580D8F3CEE1399CD073DB6CFACC1C ds-cfg-public-key-certificate;binary:: MIIB6zCCAVSgAwIBAgIEDKSUFjANBgkqhkiG9w0BA QUFADA6MRswGQYDVQQKExJPcGVuREogQ2VydGlmaWNhdGUxGzAZBgNVBAMTEm9wZW5hbS5leGFtcGxl LmNvbTAeFw0xMzAyMDcxMDMwMzNaFw0zMzAyMDIxMDMwMzNaMDoxGzAZBgNVBAoTEk9wZW5ESiBDZXJ 0aWZpY2F0ZTEbMBkGA1UEAxMSb3BlbmFtLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNAD CBiQKBgQCfGLAiUOz4sC8CM9T5DPTk9V9ErNC8N59XwBt1aN7UjhQl4/JZZsetubtUrZBLS9cRrnYdZ cpFgLQNEmXifS+PdZ0DJkaLNFmd8ZX0spX8++fb4SkkggkmNRmi1fccDQ/DHMlwl7kk884lXummrzcD GbZ7p4vnY7y7GmD1vZSP+wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAJciUzUP8T8A9VV6dQB0SYCNG1o 7IvpE7jGVZh6KvM0m5sBNX3wPbTVJQNij3TDm8nx6yhi6DUkpiAZfz/OBL5k+WSw80TjpIZ2+klhP1s srsST4Um4fHzDZXOXHR6NM83XxZBsR6MazYecL8CiGwnYW2AeBapzbAnGn1J831q1q objectClass: top objectClass: ds-cfg-instance-key dn: cn=opendj.example.com:4444,cn=Servers,cn=admin data changetype: modify replace: ds-cfg-key-id ds-cfg-key-id: 073580D8F3CEE1399CD073DB6CFACC1C ``` Don't yet update `cn=admin data`. You must not change the server key ID until the server is ready to use the PKCS#11 module. 4. Edit the `ads-truststore` trust manager provider configuration to access the PKCS#11 module with the following properties: * `trust-store-file` Leave this unchanged. * `trust-store-pin` Set this to the PIN for the PKCS#11 module. You can avoid exposing secrets in the configuration by using expressions. For details, refer to *Property value substitution*. * `trust-store-type` Set this to `PKCS11`. 5. Stop the DS server. 6. Using the `ldifmodify` command while the server is stopped, update `cn=admin data` for the server with the LDIF you prepared. This step changes the key ID for the server, letting it use its keys held in the PKCS#11 module. 7. *On another, running server replica*, use the `ldapmodify` command to update `cn=admin data` for the server with the LDIF you prepared. Replication propagates the change to the other running server replicas. This step changes the key ID for the server, letting other servers trust its new certificate once it restarts. 8. Restart the DS server. ### DS 6.5.2 There are no new features introduced in DS 6.5.2, only bug fixes. ### DS 6.5.1 There are no new features introduced in DS 6.5.1, only bug fixes. ### DS 6.5.0 #### Connection limiting DS servers now allow you to limit the number of concurrent connections per client. For details, refer to *Connection limits*. #### Data distribution DS proxy servers now support simple, non-elastic data distribution. You can configure a proxy server to equitably distribute LDAP write requests across multiple replication partitions to scale the directory service horizontally. As the present implementation does not permit elastic scaling or data redistribution, make sure that you understand the documented constraints of the present implementation before deploying it in production. For details, refer to *Data distribution*. #### Database caching A new DS directory server uses shared cache by default for all JE database backends. As a result, you are no longer required to set the database cache size using the `db-cache-percent` or `db-cache-size` setting for each backend. It remains possible to use these settings if necessary by configuring them appropriately. #### Logging * DS servers now support sending access log messages to standard output. For details, refer to *Log access to standard output*. When the new handler is used, standard output from the server includes a mix of JSON for access messages and non-JSON DS-format server event messages. * Common audit logging now supports denying log message fields to prevent them from showing up in log messages. For an example, refer to *Deny log message fields*. * Common audit logging now supports writing multiple file-based logs to the same directory by setting a different `log-file-name-prefix` for each file-based log. #### Monitoring DS servers now provide health status checks for anonymous requests over HTTP and LDAP. This allows a remote application to check that a server is "alive" and "healthy". Anonymous HTTP requests can retrieve "alive" and "healthy" status codes. Anonymous LDAP requests can retrieve "alive" and "healthy" boolean values. The "alive" and "healthy" status indicates that the server has passed its own internal tests. It is not, however, a guarantee that the server is free from other errors. If a server is *not* "alive," it requires administrative intervention. If a server is *not* "healthy," temporarily route requests to another server. When a server is not "alive" or "healthy," a user with privileges to read monitoring information receives health status error messages in the body of the HTTP response, and can obtain health status error messages over LDAP. No error messages are returned in response to anonymous requests. For examples demonstrating how to use this feature, refer to *Monitoring*. When you upgrade DS servers to 6.5.0, the anonymously accessible HTTP endpoints are not configured. To add the endpoints on an upgraded server that lacks them, use the `dsconfig` command: ```bash $ dsconfig \ create-http-endpoint \ --endpoint-name /alive \ --type alive-endpoint \ --set enabled:true \ --set authorization-mechanism:HTTP Anonymous \ --set authorization-mechanism:HTTP Basic \ --hostname opendj.example.com \ --port 4444 \ --bindDN "cn=Directory Manager" \ --bindPassword password \ --trustAll \ --no-prompt $ dsconfig \ create-http-endpoint \ --endpoint-name /healthy \ --type healthy-endpoint \ --set enabled:true \ --set authorization-mechanism:HTTP Anonymous \ --set authorization-mechanism:HTTP Basic \ --hostname opendj.example.com \ --port 4444 \ --bindDN "cn=Directory Manager" \ --bindPassword password \ --trustAll \ --no-prompt ``` #### Platform integration When setting up a directory server for use with other Ping Identity Platform component products, you can use available setup profiles to greatly simplify initial configuration. For details, refer to *Setup profiles*. #### Replication When configuring a replication server on a multi-homed system with multiple IP addresses, you can now specify which listen addresses to use. Set the property, `listen-address`, as shown in *Listen addresses*. #### Support The DS support extract command, `supportextract`, now ships with DS server software, making it easier to capture troubleshooting information. The command works on all supported platforms. For details, refer to `supportextract`.