Tombstone entries in a directory server

Edit online

Before entries are permanently deleted from the RDBM database, a subtree is created to hold the entries to be deleted with operation attributes. This feature is available in IBM® Security Verify Directory, Version 6.2 and later versions.

The to-be-deleted entries are moved to the tombstone subtree, cn=Deleted Objects, and the attribute table is updated for the entry to mark the entry as deleted by adding attribute such as isDeleted. This feature is supported only on the primary RDBM back-end of the directory server. Tombstones are not supported in configuration, schema, or change log back-end.

There might be situations where data inconsistency gets introduced by entry deletions when this feature is enabled, which requires the intervention of the directory administrator. For performance reasons, there is no check that is provided, which can possibly prevent tombstones entries with the attribute isDeleted set to TRUE from being accidentally created or modified under any subtrees.

You can identify these entries in an RDBM back-end database by comparing the searches. Compare the search results that are returned by a normal search with a search base to that returned by a null base search.

For example, consider an RDBM back-end database with two subtrees: o=sample and cn=Deleted Objects. where, o=sample, contains three entries: cn=A, cn=B, and cn=C (with isDeleted=TRUE). The subtree cn=Deleted Objects containing entries, cn=X, cn=Y, and cn=Z (without isDeleted=TRUE).

When searches that use a search base and null base are requested without including the return deleted object control, the following results are displayed.

In a search with a search base o=sample and search filter, objectclass=*, all entries under the search base, including entries with isDeleted=TRUE, are displayed.
In a null base search with search filter, objectclass=*, all entries except for those entries with isDeleted=TRUE are displayed.

Table 1. The results of different search base with search filter, `objectclass=*`
Subtree search base	Search filter	With control	Search results	Remarks
`o=sample`	`objectclass=*`	No	`cn=A cn=B cn=C`	`cn=C` is a normal entry with `isDeleted=TRUE`
`null`	`objectclass=*`	No	`cn=A cn=B cn=Z`	List LDAP_ENTRY table with `isDeleted!=TRUE`. `cn=C` is not qualified.

It is possible that the isDeleted attribute is accidentally deleted or is set to FALSE for entries under the tombstone subtree. When searches that use a search base and null base are requested with the return deleted object control, the following results are displayed.

In a search with a search base, cn=Deleted Objects, and search filter, objectclass=*, all entries under search base are returned. However, when a search with a search base, cn=Deleted Objects, and search filter, isDeleted=TRUE, is requested, entries with isDeleted=FALSE are not returned.
In a null base search with search filter, objectclass=*, all entries in the database are displayed. However, when a null base search with search filter, isDeleted=TRUE, is requested, only the entries with attribute isDeleted=TRUE in the database are displayed.

Table 2. The results of different search base with different search filters
Subtree search base	Search filter	With control	Search results	Remarks
`cn=Deleted Objects`	`objectclass=*`	Yes	`cn=X cn=Y cn=Z`	`cn=Z` is a tombstone without `isDeleted=TRUE`
`cn=Deleted Objects`	`isDeleted=TRUE`	Yes	`cn=X cn=Y`
`null`	`objectclass=*`	Yes	`cn=A cn=B cn=C cn=X cn=Y cn=Z`	List the `LDAP_ENTRY` table, including entries with `isDeleted=TRUE`.
`null`	`isDeleted=TRUE`	Yes	`cn=C cn=X cn=Y`

Note: Deletion of schema attributes might fail because some of tombstone entries still reference them. A delete, rename, or restore of a tombstone entry is not replicated. It might result in data inconsistencies on replicas such as rename and restore cases.