How does the "Protect container/object from Accidental Deletion" feature work in Windows Server 2008?
Hello,
I would be obliged if someone could explain for me how exactly the Protect container/object from Accidental Deletion feature works in Windows Server 2008?
I am interested to know because we used to have scripts written to find and delete specific OU accounts, but in one of our domains running Windows Server 2008, these scripts return access denied errors.
One of my colleagues suggested that it might have to do with this feature in Windows Server 2008, so I would be interested in understanding how this feature works so we can, if needed, modify our scripts.
Thank you for obliging me with your response. It is much appreciated.
Antoine
__________________
Jugez un homme par ses questions plutôt que par ses réponses
Have you ever put in a week's work and made it look like it was a month's work?
The "Protect container/object from Accidental Deletion" feature is a perfect example of what Microsoft's seems to have done here. I mean, if you analyze what happens under the hood, it is clearly evident that most of us could have done this by ourselves.
So let me share with you exactly how this feature works. It appears that Microsoft may gotten a lot of feedback from customers saying that it is too easy to accidentally delete objects in Active Directory, especially OUs, and that it would be beneficial if they made it harder to delete objects.
So what does Microsoft do? They simply modify the default security in the Active Directory Schema on Organizational-Unit objects by adding an permission that denies Everyone the Standard Delete right on the object.
Now if you know how permissions work in Active Directory, then you know that a directly applied DENY permission takes precedence over all other permissions, and so it has the effect of by default denying everyone the ability to delete the account.
The only other thing they seemed to have done is tweaked the UI a bit to expose a little check-box which toggles the presence of this permission on the object.
So, if you want to delete the object, you go un-check the box, which has the effect of removing this permission, and then you can proceed to delete the object based on your standard permissions.
It certainly is a really smart hack to do to accomplish this capability for very little effort.
One downside of this is that if you have any automated management tools that do cleanups and or deletions, you'll encounter a hiccup each time they try to delete an OU because you'll have to fo modify these permissions.
But it does accomplish the intended objective, so towards that end, it works like a charm.
I hope this helped you get a better understanding of this feature works.
