There are some general tips about soft deletes that administrators should be aware of:
  • LDAP SDK and Server SDK. The LDAP SDK and Server SDK both fully supports soft-deletes.
  • Possible Performance Impact for Searching Regular Entries and Soft-Deleted Entries. There is little performance difference between retrieving a regular entry and a soft-deleted entry, respectively. However, there may 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 may take the server a little more time to retrieve and try to match the criteria before it can return the results.
  • Soft Delete for Uncached Attributes and Entries. The soft delete feature fully supports uncached attributes and uncached entries. See the section on Uncached Attributes and Entries for more information about the feature.
  • Soft Delete 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.
  • Attempting to Soft-Delete a Soft-Deleted Entry Fails. There are two available state options for soft-deletes: administrators can permanently delete a soft-deleted entry or undelete the entry. An administrator 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 Directory Server or have authentication access. They cannot change their passwords and cannot undelete themselves. Also, soft-deleted entries cannot be used as an authorization identity using the proxied authorization or immediate client control. It is important to note that the soft-delete process does not destroy privilege assignment. If a soft-deleted entry is undeleted, the restored entry will retain the same privileges it originally had before being soft deleted. (One possible exception to this are those privileges assigned by virtual attributes that no longer match the newly-undeleted entry; those entries do not retain their original privileges.)
  • Soft-Deleted Entries Not Accessible by Other Means. Soft-deleted entries may 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 administrators has modify privileges and access to the soft-delete-read privilege. Any attempt to rename a soft-deleted entry using a MODIFY DN operation will result in an UNWILLING_TO_PERFORM result code.
  • Replication. Replication will have 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 then replicated, this results in a replication conflict. For maximum compatibility, it is highly recommended that all servers in a replication cluster support Soft Deletes and have identical Soft Delete configuration.
  • Transactions. 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.
  • Soft-Deletes Through the Directory Proxy Server . There is no special configuration steps to configure Soft Deletes on the Directory Proxy Server. The soft-deleted entry is routed directly to the underlying Directory Server. There is one exception: in an entry-balancing deployment, the Directory Proxy Server is responsible for routing the soft-deleted entry to the Directory Server containing the originally soft-deleted item. Also, as with standard entry-balanced deployments, it is not possible to undelete (using MODDN) an entry to a different Directory Server.
  • Export-LDIF. The default behavior is to include 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.
  • Proxied Authorization. The Soft Delete feature can be used with users who have proxied authorization privileges.
  • Ignored by Data Sync Server Sync Pipes. 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, and an actual undelete operation appears in the changelog as a regular ADD.
  • Referential Integrity Plugin Does Not Restore Membership. References to a deleted DN are not restored by the referential integrity plugin upon undeletion of 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 will remove this DN from the group’s list of members. When you undelete the soft-deleted entry, the plugin will not add the entry back to the group.
  • Criteria-Selected or Explicitly-Requested Purging of Soft Deletes. The Soft Delete Policy configuration supports two new properties, soft-delete-retention-time and soft-delete-retain-number-of-entries that performs purging of soft deleted entries. See the section on Configuring Soft-Delete Automatic Purging.
  • Assigning Access to Controls to Non-Root Users Administrators. By default, the root user account (e.g., cn=Directory Manager) has access to all of the controls needed to run the Soft Delete operations. 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 the section, 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 OID for the control is 1.3.6.1.4.1.30221.2.5.20.
    • 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 1.3.6.1.4.1.30221.2.5.21.
    • 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 1.3.6.1.4.1.30221.2.5.22.
    • Undelete Request Control. Allows the user to undelete a soft-deleted entry using an ADD request. The OID for this control is 1.3.6.1.4.1.30221.2.5.23.
    • Soft-Deleted Entry Access Request Control. Allows the user to search for any soft-deleted entries. The OID for this control is 1.3.6.1.4.1.30221.2.5.24. Note that 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 via the output of one of those tools.