General tips on soft deletes

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:

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 Configuring a user to use soft or hard delete controls. The following soft delete controls are available to non-root users: