The Active Directory Recycle Bin: enabling it, object lifetime and limits versus a real backup

What happens without the Recycle Bin

When an object is deleted in a domain without the Recycle Bin, Active Directory does not erase it immediately: it turns it into a "tombstone". Most of its attributes are stripped away, including group memberships. The object survives in this stripped-down state for a period called the tombstone lifetime. Restoring an object in this state is possible but painful: you then have to rebuild the lost attributes manually and add the object back to its groups.

What the Recycle Bin changes

Once the Recycle Bin is enabled, a deleted object is no longer stripped immediately. It moves into a "logically deleted" state where it keeps all of its attributes, including links such as group memberships. Throughout this period, it can be restored as it was, with its attributes and relationships, in a single operation. Only when this period expires does it become a tombstone, and then it is permanently removed.

Two settings govern these durations: msDS-deletedObjectLifetime, which sets the length of the logically deleted state, and the tombstone lifetime. By default, the former takes the value of the latter, which is 180 days in recently created forests. In practice, you therefore have six months to restore an object in full, provided the Recycle Bin was enabled before the deletion.

Enabling and restoring

Enabling is done once, at the forest level, and replicates to all domain controllers. It slightly increases the size of the database, since deleted objects keep all of their attributes for longer: something to plan for, but not a difficulty in most environments.

Restoration is done from the Active Directory Administrative Center, which presents a container of deleted objects, or from the command line. The operation restores the object to its original location, or to a chosen location if the original organisational unit no longer exists. When restoring a set of linked objects, for example an organisational unit and its contents, order matters: you must restore the container before the objects it held, otherwise their restoration fails.

The limits to keep in mind

The Recycle Bin answers one specific need: the deletion of objects. It does not cover other situations:

• A change without deletion: if an attribute is overwritten, a group emptied of its members without the objects themselves being deleted, or a GPO altered, the Recycle Bin can do nothing. These cases call for an authoritative restore from a backup.
• Corruption or a forest disaster: the Recycle Bin lives in the directory; if the directory is destroyed or corrupted, it disappears with it. Only a system state backup, kept offline, enables a forest recovery.
• An object deleted longer ago than the configured lifetime: past that point, the object can no longer be restored.
• The account password: a restored user object regains its attributes, but depending on the case, its secret may need to be reset before it can sign in again.

The Recycle Bin and backups are not in opposition: they cover different risks. The first deals with the everyday deletion mistake, the second with restoring changes and rebuilding the forest. Both must coexist, and the ability to rebuild the forest must be tested, not merely assumed.

What an audit checks

• Whether the Active Directory Recycle Bin is enabled, and when it was enabled.
• The value of msDS-deletedObjectLifetime and of the tombstone lifetime.
• Whether teams know the restoration procedure and the order for restoring linked objects.
• The existence of system state backups of domain controllers, kept offline.
• A clear distinction, in the procedures, between Recycle Bin restore, authoritative restore and forest recovery.