SYNERGY
Chapters

7.4Restoring an object

Last updated

To restore an object:

  1. Find the object in the table, using the search or the type chips if needed.
  2. Select Restore at the end of its row. The restore dialog opens, headed Restore followed by the object's name, with its type, account name, deletion date and time left underneath.
  3. Read the identity note at the top of the dialog and any warnings shown under it (see the table of warnings below).
  4. Check Restore into. It is prefilled with the container the object was deleted from. Leave it as it is to restore in place, or type the distinguished name of another container, for example OU=Staff,DC=example,DC=com.
  5. Check Name. It is prefilled with the object's original name. Change it only if something else now has that name in the destination.
  6. Wait for the checks under each field, then review Will be restored as, which shows the exact distinguished name the object will have.
  7. Select Restore object.

The Restore object dialog When the restore succeeds, a confirmation message names the object and where it was restored to. The object disappears from the listing and the counts and type chips are updated. A banner stays at the top of the page reading "“name” has been restored." with these actions:

  • Browse the restored object: opens the Directory Browser on the restored object (shown when you hold ad:directory:read). See Chapter 6, Directory Browser.
  • Review what can be put back: shown only when the object came back without its attributes and you hold ad:deleted-objects:reapply-attributes. See the next sections.
  • Dismiss: removes the banner.
Banner after a successful restore
Figure 07-04: Banner after a successful restore

The checks in the restore dialog

The dialog checks your choices against the directory as you type, a moment after you stop typing, so that the common reasons for failure are visible before you submit rather than afterwards. It uses the same logic as the restore itself, so what it reports is what the restore will do.

FieldMessageMeaning
Restore intoContainer exists — the object inherits its permissions and policiesThe destination is there; the object will inherit the permissions and Group Policy of that container
Restore intoThat container does not exist, or has itself been deletedChoose another destination. The container an object came from is often deleted together with it
Restore intoChoose a container — the directory recorded none for this objectNo original location was recorded; type a destination
NameNo conflict in the destinationThe name is free in the chosen container
NameSomething already has this name in the destination — choose anotherType a different name
NameAnother object already holds the account name …Another live object uses the same account name. The restore will be refused until you resolve that in Active Directory

The account-name warning never disables the button, because account names must be unique across the whole domain and there is no field in this dialog that can fix that; you resolve it by renaming or removing the other object in Active Directory.

The Restore object button stays disabled when a destination is required but empty, when the destination is not a distinguished name, when the check says the restore cannot succeed, or when the object is privileged and you do not hold the privileged-restore permission.

Note: The checks need both ad:deleted-objects:restore and ad:objects:read, because checking whether a container exists is a directory read. If you hold only the restore permission, the dialog still works but shows no check lines; the restore itself gives the definitive answer.

Restoring into a different container The destination changed to an existing container

Warnings in the restore dialog

WarningWhen it appears
Attributes will not be recoveredThe Active Directory Recycle Bin feature is off. The object returns disabled and without its attributes or group memberships
This restores administrative privilegeThe object is privileged and you may restore it. Read the warning before confirming
You cannot restore this objectThe object is privileged and you do not hold the privileged-restore permission
"Active Directory did not record where this object was deleted from…"No original location is known; you must enter a destination

If the restore fails, the error is shown inside the dialog, so you can adjust the destination or name and try again without starting over.

Restoring privileged objects

Some objects are a privilege decision rather than a simple recovery. With the Active Directory Recycle Bin feature enabled, a restored account comes back with its original password, SID and group memberships, so restoring a deleted domain administrator hands back a working administrative credential.

The console treats an object as privileged when it would rejoin one of the domain's administrative groups, or when it is the built-in Administrator or krbtgt account. The groups recognised are Domain Admins, Domain Controllers, Cert Publishers, Schema Admins, Enterprise Admins, Group Policy Creator Owners, Read-only Domain Controllers, Administrators, Account Operators, Server Operators, Print Operators, Backup Operators and Cryptographic Operators. They are recognised by their fixed relative identifier, not by name, so a renamed or translated group (for example on a non-English domain) is still caught.

  • If you hold ad:deleted-objects:restore-privileged, the dialog shows This restores administrative privilege, names the groups the object rejoins, and lets you continue.
  • If you hold only ad:deleted-objects:restore, the dialog shows You cannot restore this object and the Restore object button stays disabled. Ask an administrator to restore it, or to grant you the permission. Over the REST API the same request is refused with HTTP 403.
Restoring a privileged account
Figure 07-06: Restoring a privileged account
Important: Grant ad:deleted-objects:restore-privileged sparingly. It is deliberately not included in the Recycle Bin Operator template.

Restores are audited and may need approval

Every restore is recorded in the operations log like any other directory operation, as the dialog's footer says ("Audited like any other operation."). If a restore is made through the REST API with an API key, it is subject to agent supervision and may be queued for a person's approval; a restore made by a person in the console runs or is refused on permissions alone. See Chapter 9, Operations log, approvals and waiting operations, and Chapter 10, Operation policies, attribute policies and agent supervision.

Last updated

Did this page help you?