Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2007-04-22) Windows Server Longhorn – Protecting Objects

Posted by Jorge on 2007-04-22


Protecting AD objects from accidental deletions or moves

One of the common issues, when managing objects within AD, are accidental deletions or moves. Although the system asks for confirmation (depends on the OS of the DC if I’m not mistaken) it still occurs. Because of that people may either need to reanimate objects or restore them authoritatively. If we are talking about one or two objects it is not that terrible when comparing it with the deletion of an OU with thousands of objects. Also taking the restore of backlinks (e.g. group memberships) it can be a pain and the impact is very high. Information about restoring objects can be found in MS-KBQ840001.

When managing objects using the Windows Server Longhorn version of "Active Directory Users and Computers" a new option is available that mitigates the risk of accidental deletions and moves (see pictures below).

image

image

When creating an OU (left picture) you have the possibility to check the option called "Protect container from accidental deletion" (automatically selected!). It is also possible to use that option after the creation of the OU (or whatever object) by first enabling "Advanced Features" from the pull-down menu and then asking the properties of the object in question and looking at the "Object" tab.

With that, the OU and its leaf objects are protected from deletions or moves when the deletion targets the OU. If the deletion targets a leaf object within that OU, that leaf-object is still deleted. Of course you can also protect a leaf object from being deleted, but the idea here is to configure that option for OUs with leaf objects. Important to know is that the new option does not use something like an attribute. That option just instructs the "Active Directory Users and Computers" MMC to configure additional permissions on the object being protected. The permissions that are configured when that option is that are a DENY "Delete" and a DENY "Delete subtree" for EVERYONE on "This object only". As you can see leaf objects do not inherit those permissions. The strange part here is setting that option on a certain OU does not make the first level of leaf objects (and also lower) to inherit the same option. However when the option is removed from an OU at a certain level it will remove the same option from the first level of leaf objects (and not lower).

When trying to delete an OU that has that option configured you will see something similar like the picture below. If you really want to delete or move an OU that has been configured with that option, you need to remove that option (or the permissions mentioned) first.

image

And now it is time for the fun part. As I mentioned before it is not a new AD feature, but it is a new Windows Server Longhorn "Active Directory Users and Computers" MMC feature. What I’m trying to say here is that within current W2K and W2K3 AD environments this can also be used by just configuring the permissions mentioned above. This is no high-tech feature, but it is one MMC feature just making things easier for people when creating OUs.

If you scripts or tools to create OUs, you might need to consider to add those permissions into the process of creating OUs.

Although it is possible to use configurations like these mentioned here, the most important thing here is to have a correct delegation of control model where someone only gets those permissions or rights that are really needed!

NOTE: this information is based upon a beta release of Windows Server Longhorn and thus subject to change in the final RTM release. Do not use Windows Server Longhorn in a production environment without the explicit commitment from Microsoft for help and support.

Updated Information:

To prevent the accidental deletion or movement of objects (especially organizational units), two Deny access control entries (ACEs) can be added to the security descriptor of each object (DENY "DELETE" & "DELETE TREE") and one Deny access control entries (ACEs) can be added to the security descriptor of the PARENT of each object (DENY "DELETE CHILD"). To do this in Windows 2000 Server and in Windows Server 2003, use Active Directory Users and Computers, ADSIEdit, LDP, or the DSACLS command-line tool. You can also change the default permissions in the AD schema for organizational units so that these ACEs are included by default.

For example, to protect the organization unit that is called Users in the AD domain that is called CONTOSO.COM from accidentally being moved or deleted out of its parent organizational unit that is called MyCompany, make the following configuration:

For the MyCompany organizational unit, add DENY ACE for Everyone to DELETE CHILD with the This object only scope:

·         DSACLS "OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:DC"

 

For the Users organizational unit, add DENY ACE for Everyone to DELETE and DELETE TREE with the This object only scope:

·         DSACLS "OU=Users,OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:SDDT"

 

The Active Directory Users and Computers snap-in in Windows Server 2008 includes a Protect object from accidental deletion check box on the Object tab. Note The Advanced Features check box must be enabled to view that tab. When you create an organizational unit by using Active Directory Users and Computers in Windows Server 2008, the Protect container from accidental deletion check box appears. By default, the check box is selected and can be deselected. Although you can configure every object in Active Directory by using these ACEs, this is best suited for organizational units. Deletion or movements of all leaf objects can have a major effect. This configuration prevents such deletions or movements. To really delete or move an object by using such a configuration, the Deny ACEs must be removed first.

Additional interesting links:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

4 Responses to “(2007-04-22) Windows Server Longhorn – Protecting Objects”

  1. Finally Microsoft is considering this, thanks for the info Jorge

  2. Jorge, just something I noticed in testing the above and stuff in the the Q article

    http://support.microsoft.com/kb/840001

    which you had mentioned at TEC. I ran a test to see how it works for WS03. It worked great and did block the ability to delete the users container. However, it did not block the ability to delete the mycompany OU. I was able to delete the mycompany OU without any access denied errors, which of course deleted the my users OU. To prevent this I ran the same command on the mycompany OU that I ran on the users OU. This prevented the deletion of both the parent and child. Are there any gotcha’s I might be overlooking here that you can see by running both commands on one OU?

  3. Jorge said

    that’s because EACH OU requires a DENY ACE on the OU itself and the parent of that same OU. So, in your case, to protect the MYCOMPANY OU you should also configure the required ACE on the parent of the MYCOMPANY OU, which may be the domain head itself.

  4. […] by Jorge on 2012-03-28 In this post I explain the “Protect From Accidental Deletion” feature that is made accessible through both […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: