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 PingDirectory 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 PingDirectory 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
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 PingDirectory server extends this capability by allowing multiple
users with the same DN, who would normally conflict if active, to reside in the
Soft-deleted entries can be restored with an
undelete operation. The same
uniqueness constraints that apply when adding a new user to the PingDirectory 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 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. 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 PingDirectory 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 PingDirectory 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.