The standard implementation of an LDAP server allows for adding, renaming, modifying,
searching, comparing, and deleting one or more entries. The DELETE operation is, by
specification, a destructive operation that 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. During the DELETE operation, any associations such as references and group memberships
are severed to reflect the entry that is removed. Meta attributes like operational
attributes, which may be unique to an entry like
entryUUID, will be lost or be
different if the same entry is re-added to the Directory Server.
There are cases, however, where a company may want to preserve their deleted entries to allow for possible undeletion at a later date. For example, a company may want to retain account and subscriber entries for their users (e.g., customers, employees, or partners) who leave but later rejoin. Artifacts that a user creates such as account histories, web pages, notes, may be tracked and recovered while a user is deleted or when the user returns as an active customer.
To facilitate this use case, the Directory Server supports a feature called
soft deletes, which preserves a deleted entry’s attributes and entry uniqueness
characteristics to allow the entry to be undeleted or permanently removed at a later date. A
delete request may 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
entryUUID operational attribute
to the DN and adding an auxiliary object class,
ds-soft-delete-entry, to the
entry, which saves the entry in a hidden state. All active references and group memberships are
then removed. Once in this hidden state, soft-deleted entries are inaccessible to clients under
normal operating conditions. Only clients with the
will be allowed to interact with soft-deleted entries.
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 could
reside in the DIT without conflict: one in a soft-deleted state; the other, in an active state.
The Directory Server extends this capability further 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. However, the same uniqueness
constraints that apply when adding a new user to the Directory Server are enforced
when a soft-deleted entry is undeleted. Returning to the previous example, John Smith was soft
deleted but a different John Smith with the same
uid as the original John Smith
was added later 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 will need
to modify the DN of the soft-deleted entry to avoid such conflicts.
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. Also, note that 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, a 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, it is highly recommended that all servers in the replication cluster support Soft Deletes and have identical Soft Delete configurations.