Freigeben über

Two lines that can save your AD from a crisis

  • Artikel

Editor's note: This is the first of very likely many "DS Quickies". "Quickies" are shorter technical blog posts that relate hopefully-useful information and concepts for you to use in administering your networks. We thought about doing these on Twitter or something, but sadly we're still too technical to be bound by a 140-character limit :-)

For those of you who really look forward to the larger articles to help explain different facets of Windows, Active Directory, or troubleshooting, don't worry - there will still be plenty of those too.  

 

Hi! This is Gonzalo writing to you from the support team for Latin America.

Recently we got a call from a customer, where one of the administrators accidentally executed a script that was intended to delete local users… on a domain controller. The result was that all domain users were deleted from the environment in just a couple of seconds. The good thing was that this customer had previously enabled Recycle Bin, but it still took a couple of hours to recover all users as this was a very large environment. This type of issue is something that comes up all the time, and it’s always painful for the customers who run into it. I have worked many cases where the lack of proper protection to objects caused a lot of issues for customer environments and even in some cases ended up costing administrators their jobs, all because of an accidental click. But, how can we avoid this?

If you take a look at the properties of any object in Active Directory, you will notice a checkbox named “Protect object from accidental deletion” under Object tab. When this enabled, permissions are set to deny
deletion of this object to Everyone.


 

With the exception of Organizational Units, this setting is not enabled by default on all objects in Active Directory.  When creating an object, it needs to be set manually. The challenge is how to easily enable this on thousands of objects.

ANSWER! Powershell!

Two simple PowerShell commands will enable you to set accidental deletion protection on all objects in your Active Directory. The first command will set this on any users or computers (or any object with value user on the ObjectClass attribute). The second command will set this on any Organizational Unit where the setting is not already enabled.

 

Get-ADObject -filter {(ObjectClass -eq "user")} | Set-ADObject -ProtectedFromAccidentalDeletion:$true

Get-ADOrganizationalUnit -filter * | Set-ADObject -ProtectedFromAccidentalDeletion:$true

 

Once you run these commands, your environment will be protected against accidental (or intentional) deletion of objects.

Note: As a proof of concept, I tested the script that my customer used with the accidental deletion protection enabled and none of the objects in my Active Directory environment were deleted.

 

Gonzalo “keep your job” Reyna

Comments

  • Anonymous
    June 04, 2013
    Nice blog Gonzalo, where I am I recommended that we set this for all "VIP accounts"  Are you seeing more cases where customers are turning this on for every user object?  Not a bad idea. Thanks Mike

  • Anonymous
    June 04, 2013
    is there any downside as far as turning it on for every object, particularly in large orgs?

  • Anonymous
    June 04, 2013
    Great post. I just ran it against my domain. Is there a way to make this the default setting for new objects or do you have to either manual set it going forward or occasionally run this script?

  • Anonymous
    June 05, 2013
    Nice tip. But what about Groups? Is not a good idea to protect them from being accidentally deleted? Or u jut don't mention because it don't matter at all if they're protected or not?

  • Anonymous
    June 05, 2013
    The comment has been removed

  • Anonymous
    June 05, 2013
    I would also add Groups. Get-ADObject -filter {ObjectClass -eq "user" -or ObjectClass -eq "group"} | Set-ADObject -ProtectedFromAccidentalDeletion:$true http://adfordummiez.com/?p=431

  • Anonymous
    June 05, 2013
    Nice info.

  • Anonymous
    June 06, 2013
    Hi folks, here Gonzalo. Regarding your questions about the impact on big environments that @David Bahm was asking, the great idea for VIP accounts from @Mike Kline and add groups as @Vandrey Trindade was asking and the right point from @A.Hultgren, want to mention the following: This is just the how to do it, and it can be customized to ad groups, or just certain groups modifying the filter on the first command. But, the main thing that needs to be observed is that this change needs to be aligned with the process that each of your company have, and with this, I am talking about any process that involves management of the environment or users. Most of the times when there is a problem, is caused by either lack of process or follow up the process (can be change management, update management, release management, etc) or because the person was not with the right skills.. and in a very small part, is because the technology itself failed, and this is not just about Microsoft technologies. So with this, my message is that before implement this, needs to be reviewed and modify if need it your internal process, as there will be some changes like remove the protection before modifying the object that have to be notified to the people in change of managing the accounts. I hope that this could address most of your questions... have a nice replication.

  • Anonymous
    June 06, 2013
    The comment has been removed

  • Anonymous
    June 07, 2013
    Thanks for your comment @Баф. Because of the lack on investigation and test (change management process), is why companies have adverse effects. And here is where MOF or ITIL take relevance. Most of the companies nowadays are lack of process or they don't followed properly. And again, tests and evaluations according to business needs must be determined before every change, not just this. Probably business just requires to protect "VIP accounts" as @Mike Kline was mentioning and that is fine for that specific company.

  • Anonymous
    June 07, 2013
    I think there are a few gotchas with activating this option. First, for some very strange reason it isn't enabled on built-in OU/users. Build a brand new AD, start a BPA and you'll get a warning saying every OU out there should be protected (even if you didn't create anything besides built-in stuff). This would be nice if this could be fixed in the future. Second, I have seen it jeopardize delegations. It seems it doesn't only add a everyone/deny/delete ace but also somewhat reapply some default ACL which can mess with your settings. Great feature otherwise, but be sure to test and test again before applying it to your whole AD (as usual...)

  • Anonymous
    June 08, 2013
    There is no impact for a large environment.

  • Anonymous
    June 19, 2013
    Without powershell AD module: For /f "delims=" %a in ('dsquery ou -limit 0') do dsacls %a /d everyone:SDDT rgds,

  • Anonymous
    June 19, 2013
    For all users: for /f "delims=" %a in ('dsquery * -filter "(&(ObjectClass=user)(ObjectCategory=Person))"') do dsacls %a /d everyone:SDDL If VIP users are marked in description, we can use following example: for /f "delims=" %a in ('dsquery * -filter "(&(ObjectClass=user)(ObjectCategory=Person)(Description=VIP accounts))"') do dsacls %a /d everyone:SDDL rgds,

  • Anonymous
    July 09, 2013
    The comment has been removed

  • Anonymous
    January 02, 2014
    The comment has been removed

  • Anonymous
    April 13, 2014
    阅读我们发布的一篇有关 DNS 删除审核的文章后，想向大家提供一些防范措施。实际上我要感谢 Brent Whitlow、Bryan Zink 还有博客作者 Hilde。
    我们的同事、同行及其他各界人士均提到过这一点

  • Anonymous
    November 28, 2014
    Learn three essential steps for Windows PowerShell when upgrading from Windows Server 2003.