Soft deletes preserve a deleted entry's attribute and uniqueness characteristics so it can be undeleted or permanently removed at a later date.
The standard implementation of an LDAP server allows adding, renaming, modifying,
searching, comparing, and deleting one or more entries. By specification, the
delete operation permanently removes an entry and its attributes in a
Directory Information Tree (DIT) but records the changes in access, and optionally, audit
and change logs. The
delete operation severs any associations such as
references and group memberships. Meta attributes, such as operational attributes, which
can be unique to an entry like
entryUUID, are lost or different if the
same entry is re-added to the Directory Server.
There are cases where a company might want to preserve their deleted entries to allow for possible undeletion at a later date. For example, a company might want to retain account and subscriber entries for their users who leave but later rejoin. Artifacts that a user creates such as account histories, web pages, notes, can be tracked and recovered while a user is deleted or when the user returns as an active customer. Soft deletes facilitate this use-case.
A delete request can result in a soft delete either by the client explicitly requesting a
soft delete or by the request matching criteria defined in an active soft delete policy.
The soft-deleted entries are renamed by prefixing an
attribute to the DN and adding an auxiliary object class to the entry,
ds-soft-delete-entry, which saves the entry in a hidden state. All
active references and group memberships are then removed. While in this hidden state,
clients cannot access soft-deleted entries under normal operating conditions. Only clients
soft-delete-read privilege can interact with soft-deleted
To allow soft deletes, the Directory Server’s attribute uniqueness function
has been relaxed to allow for the co-existence of a soft-deleted entry and an active entry
with identical naming attributes, such as
uid. For example, if a user John
Smith was soft deleted, but a different John Smith was added to the user accounts system,
both entries can reside in the DIT without conflict. One entry would exist in a
soft-deleted state and the other in an active state. The Directory Server
extends this capability by allowing multiple users with the same DN, who would normally
conflict if active, to reside in the soft-deleted state.
Soft-deleted entries can be restored with an
undelete operation. The same
uniqueness constraints that apply when adding a new user to the Directory Server are enforced when a soft-deleted entry is undeleted. In the previous example, John Smith
was soft-deleted, but a different John Smith with the same
uid as the
original John Smith was later added to the system. If the original John Smith was undeleted
from its soft-deleted state, it would result in a conflict with the active John Smith
entry. Administrators must modify the DN of the soft-deleted entry to avoid such
Administrators can permanently remove a soft-deleted entry by performing a regular
delete operation on it. This operation, called a hard delete,
permanently removes a soft-deleted entry from the server. You can also permanently remove a
regular non-soft-deleted entry using a hard delete. This is useful when the server is
configured with a soft-delete policy that would otherwise turn a regular delete request
into a soft delete.
The Directory Server provides tool arguments that can use the soft delete request control, the hard delete request control, and other controls necessary to process these operations. Procedures to show how to use these options are presented later in this section.
For replicated topologies, when a participating directory server soft deletes an entry, it notifies the other replicas in the topology to soft delete the same entry on its respective machine. The changelog backend also records these entries by annotating them using an attribute that indicates its soft-deleted state. Modification and hard deletes of soft-deleted entries are not recorded by default in the changelog but can be enabled in the server. For maximum compatibility, make sure all servers in the replication cluster support soft deletes and have identical soft delete configurations.