Guarding Against Accidental Bulk Deletions in Active Directory

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

Although bulk deletions are rare, they are disruptive events that you can guard against by removing the Delete and the Delete Subtree permissions in Active Directory. To guard against accidental deletions, you should remove the Delete and Delete Subtree permissions on organizational units (OUs) that contain user accounts, computer accounts, and security groups in Active Directory. You should also remove the Delete All Child Objects permission on the parent container of an OU that you want to protect.

Types of deletions

IT administrators have used Active Directory Users and Computers (dsa.msc) and other Active Directory management tools to accidentally delete objects from Active Directory. Two types of deletions are most common:

  • Leaf-node deletions, which occur when an administrator or delegated user selects and deletes one or more leaf objects. A leaf object is an object that does not have subordinate objects. User and group objects are examples of leaf objects.

  • OU deletion, which occurs when an administrator or delegated user selects and deletes a container that has subordinate objects.

Note

Although the remainder of this task refers to using dsa.msc, the explanations and guidelines apply to any tool that you use to perform the deletion, including the Active Directory Sites and Services snap-in (dssite.msc) if you use it to perform bulk deletions of configuration partition data.

A leaf-node deletion has the following characteristics:

  • The domain controller that is targeted for the operation checks whether the user has delete permissions on each selected object as dsa.msc tries to delete it.

  • Dsa.msc displays a progress bar that is updated as each object is deleted.

  • Because of the round-trip communication that takes place between the client and server, you can cancel or close dsa.msc from the workstation session that initiated the operation to stop the deletion while it is still in progress.

An OU deletion has the following characteristics:

  • When you delete an OU, dsa.msc checks for subordinate objects and whether the subtree contains any critical objects. A critical object is an object for which the isSystemCriticalObject attribute is set to True. If critical objects are in the subtree, dsa.msc stops the operation. If there are no critical objects, dsa.msc displays a warning about deleting an object. You must click Yes to continue. Dsa.msc then displays a second warning about deleting child objects and containers. You must click Yes again to continue.

  • The domain controller that is targeted for the operation performs a single-access check on the top-most OU that you are deleting. If the user has the Delete Subtree advanced permission (the symbolic name for this permission is RIGHT_DS_DELETE_TREE), the top OU and all subordinate containers are deleted, regardless of what access control lists (ACLs) are defined on subordinate containers. Administrators are implicitly granted the Delete and Delete Subtree advanced permissions if they have Full Control on a container. You can also explicitly grant the Delete and Delete Subtree advanced permissions to any user.

  • The domain controller continues its server-side deletion and does not communicate with dsa.msc again until it reaches the maximum threshold of object deletions, which is 16,384 objects. The deletions are not performed in a particular order.

    When dsa.msc reaches the maximum threshold of object deletions, it reissues the delete tree operation request until the operation succeeds or some other error is returned. When you cancel dsa.msc or stop it, either by logging off the session or by rebooting the administrative workstation, the deletion ends after the current batch of 16,384 objects is deleted on the server.

    You can stop the server-side deletion only by restarting the domain controller that is targeted for the operation or by removing network connectivity from that domain controller if additional domain controllers exist in the domain.

  • Dsa.msc does not display a progress bar during OU deletions.

  • Because no round-trip communication occurs between the client and server, the OU deletion operation completes more quickly than leaf-node deletion.

For any OU that you want to protect from accidental deletion, you can add explicit Deny Delete and Deny Delete Subtree advanced permissions to the Everyone group on that container object. To further protect the OU, you can add the explicit Deny Delete All Child Objects permission on the parent container of the OU that you want to protect. The explicit Deny access control entries (ACEs) take precedence over any Allow permissions that the user might have on the container, including inherited permissions.

Note

To prevent accidental deletion in Windows Server 2008, you can select the Protect object against accidental deletion check box when you create a new object or you can select this check box on the Object tab of the Properties property sheet for an existing object. This feature is available for all objects that appear either in Active Directory Users and Computers or Active Directory Sites and Services.

Task requirements

The following tool is required if you want to perform the procedures for this task by using the Windows interface. For more information about performing this task by using Dsacls.exe at the command line or by using a script, see Script to Protect Organizational Units (OUs) from Accidental Deletion (https://go.microsoft.com/fwlink/?LinkId=162623).

  • Active Directory Users and Computers (dsa.msc).

To complete this task by using the Windows interface, perform the following procedures as needed: