I recently assisted a customer with missing OU’s in Active Directory. We found that the OU’s were not deleted (thanks to the AD Recycle Bin), but were actually moved to another OU instead. These occurrences can easily be prevented by using a feature that was introduced with Active Directory on Windows Server 2008.
Now this is nothing new, but since we are still finding occurrences of this at our customers, I decided to publish this post as a reminder to review all OU’s in your Active Directory forest, and ensure they are protected from accidental deletion.
Protect object from accidental deletion
This feature was introduced with Active Directory on Windows Server 2008, as I have mentioned already. The one contributing factor seems to be that we never reviewed our OU’s at the time. We may not have been aware of how the new feature affected Active Directory.
When Active Directory is running on Server 2008 or later, any new OU’s that you create should be protected from accidental deletion by default. In most instances, the Active Directory Forest has been running for years and have gone through a few upgrades from older Operating Systems such as Server 2000 or Server 2003.
Considering that these OU’s existed before Active Directory was upgraded to Windows Server 2008 or later, we need to be aware that the existing OU’s were not protected by default. They need to be updated manually. Upon reviewing this at my customer, we found that hundreds of OU’s weren’t protected from accidental deletion.
The image below shows the creation of a new OU. Notice the “Protect container from accidental deletion” option. This is how new OU’s are protected from accidental deletion by default.
Finding unprotected Organizational Units (OU’s)
Firstly, you can use the following PowerShell command to review the list of OU’s that are not protected. You would need to run this from a computer that has the Active Directory PowerShell module installed.
Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | FT Name,DistinguishedNameI’ve unprotected a few OU’s to demonstrate the PowerShell command used above. There are 3 OU’s that are not protected from accidental deletion as shown in the image below:
Identify a protected Organizational Unit (OU)
Let’s review how to identify an OU that is protected from accidental deletion, in the Active Directory Users and Computers console. Advanced Features should be enabled. Verify this on the view menu if you are unsure.
Right click on an OU, select Properties and then select the Object tab. You should see the “Protect object from accidental deletion” option. Selecting or deselecting the option with will either turn accidental deletion protection on or off. Protection is enabled in the image below.
Select the Security tab. With accidental deletion protection enabled, you should find that the deny permission for “Delete all child objects” is set for the Everyone group, as shown in the image below.
I have now removed the accidental deletion protection object in the image below. Notice the option is not selected and also the deny permission for the Everyone group is no longer set.
The deny permission will still be visible in the security permissions if you have any child OU’ within this OU, although “Protect object from accidental deletion” will no longer be set. Deleting the parent OU will require delete permissions on all the child OU’s. You would need to remove accidental deletion protection from all the child OU’s before attempting to delete the parent OU.
You can also protect individual objects such as users, groups and computers in the same way. Below is an example of a user account that is protected from accidental deletion.
Protecting all OU’s
We’ve now already seen how to easily protect a single OU. Protecting multiple OU’s is easier when using Windows PowerShell. I’ll be using a variation of the command used to list the OU’s that are not protected from accidental deletion, by adding a Set-ADOrganizationalUnit command. This will find all the OU’s that are not protected, and set the accidental deletion protection option.
Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $trueNo additional output will be presented on the screen. No errors are good.
I can now verify that all OU’s are protected using the same command we used to list the unprotected OU’s. No items are listed thus all my OU’s are now protected.
How does this protect against moving an OU
You may wonder how accidental deletion protection prevents anyone from accidentally moving and OU, since you are merely moving the OU and not deleting it. I’ll demonstrate first and then explain.
I will try to move the ADMIN OU, which is protected from accidental deletion, to the LABX OU as shown in the image below:
Selecting OK to move the OU will result in an access denied error message as per the example below:
Removing accidental deletion protection will result in the OU being moved successfully. Take note that is a single OU without any child OU’s. Remove accidental deletion protection from all child OU’s before attempting to move the parent OU.
The reason for the access denied message when attempting to move a protected OU, is that moving an OU is effectively a delete action on the source location and a create action in the new location. The same applies for moving of users, computers and groups. To successfully move the OU, you need delete permissions on the source and create permissions on the target. Accidental deletion protection prevents you from deleting the OU and thus the move operation will fail.
Summary
Accidental deletion protection has been available since the release of Windows Server 2008. Review and protect all your OU’s using the PowerShell commands provided and save yourself some trouble by preventing your OU’s from being accidentally deleted or moved.
You can also apply this to any sensitive accounts or groups to prevent them from being accidentally deleted or moved.
You must log in to post a comment.