• The LDAP SDK and Server SDK both fully support soft-deletes.
  • There is little performance difference between retrieving a regular entry and a soft-deleted entry. However, there might be a performance impact when a search operation has to match criteria, such as uid=john.smith, for both active entries and soft-deleted entries. For example, if there is one active uid=john.smith entry and two soft-deleted uid=john.smith entries, it might take the server more time to retrieve and try to match the criteria before it can return the results.
  • The soft delete feature fully supports uncached attributes and uncached entries. For more information, see Uncached attributes and entries.
  • Soft-deletion is allowed for leaf nodes only. Soft-deletion of any parent entry is not allowed. Likewise, soft-deleted entries that have soft-deleted sub-entries are not allowed.
  • There are two available state options for soft-deletes:
    • Administrators can permanently delete a soft-deleted entry or undelete the entry.
    • Administrators cannot soft-delete an already soft-deleted entry, which returns an UNWILLING_TO_PERFORM result code.
  • Soft-deleted users have no privileges. Soft-deleted users do not have the ability to bind to the PingDirectory server or have authentication access. They cannot change their passwords and cannot undelete themselves. Soft-deleted entries also cannot be used as an authorization identity using the proxied authorization or immediate client control. The soft-delete process does not destroy privilege assignment. If a soft-deleted entry is undeleted, the restored entry retains the same privileges it originally had before being soft deleted. One possible exception to this are privileges assigned by virtual attributes that no longer match the newly-undeleted entry. Those entries do not retain their original privileges.
  • Soft-deleted entries might not be accessible from alternate access methods like SCIM.
  • Soft-deleted entries can be modified but not renamed. Administrators can search for all soft-deleted entries and the original source entry attributes can be updated as long as the administrator has modify privileges and access to the soft-delete-read privilege. Any attempt to rename a soft-deleted entry using a modify DN operation results in an UNWILLING_TO_PERFORM result code.
  • Replication has access to the LDAP operations with soft delete controls. These operations are transmitted, processed, and replayed as high-level requests, which are re-played on remote replicated servers. The replication conflict-resolution mechanism handles soft-deleted entries like any regular entries. For example, if a soft delete is executed independently on two servers and is then replicated, this results in a replication conflict. For maximum compatibility, all servers in a replication cluster should support soft deletes and have identical soft delete configuration.
  • Soft-deletes are supported in transactions. The processing workflow uses the transactions mechanism and maintains the context information necessary to rollback failures to soft delete or undelete.
  • There are no special configuration steps to configure soft deletes on the PingDirectoryProxy server. The soft-deleted entry is routed directly to the underlying PingDirectory server. There is one exception: in an entry-balancing deployment, the PingDirectoryProxy server is responsible for routing the soft-deleted entry to the PingDirectory server containing the originally soft-deleted item. As with standard entry-balanced deployments, it is not possible to use moddn to undelete an entry to a different PingDirectory server.
  • The default behavior includes soft-deleted entries as part of the export-ldif operation. If soft-deleted entries are to be excluded from export, administrators can use the --excludeSoftDeleteEntries option to filter out the entries.
  • The soft delete feature can be used with users who have proxied authorization privileges.
  • For customers using the PingDataSync server, soft-deleted entries are not synchronized by the server. Modifications or deletes of a soft-deleted entry are ignored by the Data Sync Server, and do not appear in the changelog by default. An actual soft delete operation appears to the changelog as a regular delete operation, and an actual undelete operation appears in the changelog as a regular add operation.
  • References to a deleted DN are not restored by the referential integrity plugin when you undelete a soft-deleted entry. For example, if you have referential integrity enabled and you soft-delete a DN that is a member of a static group, the referential integrity plugin removes this DN from the group’s list of members. When you undelete the soft-deleted entry, the plugin does not add the entry back to the group.
  • The soft delete policy configuration supports two new properties, soft-delete-retention-time and soft-delete-retain-number-of-entries, that perform the purging of soft-deleted entries. For more information, see Configuring Soft-Delete Automatic Purging.
  • The root user account, such as cn=Directory Manager, has access to all of the controls needed to run the soft delete operations by default. For non-root users, you must grant access to these soft delete controls using access control rules. An example is shown in step 1 of To Configure Soft Deletes as a Global Configuration. The following soft delete controls are available to non-root users:
    Soft delete request control
    Allows the user to perform a soft delete operation. The object identifier (OID) for the control is
    Soft delete response control
    Allows the server to hold the DN of the soft-deleted entry that results from a soft delete request. The OID for the control is
    Hard delete request control
    Allows the user to run a hard delete operation on the entry, regardless if it is a regular or soft-deleted entry. The OID for the control is
    Undelete request control
    Allows the user to undelete a soft-deleted entry using an ADD request. The OID for this control is
    Soft-deleted entry access request control
    Allows the user to search for any soft-deleted entries. The OID for this control is

    A bind DN with the stream-values privilege can perform operations that can reveal soft-deleted entries, even if that bind DN does not have permission to use the soft-deleted entry access request control. For example, if a user can successfully run dump-dns or ldap-diff, then that user can get a list of soft-deleted entry DNs or soft-deleted entry contents through the output of one of those tools.