Two lines that can save your AD from a crisis

Two lines that can save your AD from a crisis

  • Comments 18
  • Likes

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

  • 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.



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

  • 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?

  • 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?

  • @David:

    Off the top of my head, I'm thinking a downside is that you can no longer move objects without first un-checking that box, and then re-checking it once the object has been moved, (which could potentially turn into an administrative nightmare). On the other hand... you won't come in to work one day to find all your user or computer accounts missing. :)

  • I would also add Groups.

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

  • Nice info.

  • 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.

  • Thanks for sharing!

    I have recommended this in my blog (in Russian, sorry, but you can google translate) long ago for protection from dummies (and myself of course :)

    But I think for large enterprises there can be some issues and it need to investigate all of them before massive use.

    For example some time after I have an issue (more here ) with this error that was caused by this check box:

    Print queue LDAP://CN=TEST-PP-disp,CN=TEST-PP-OLD,OU=Servers,OU=TEST,OU=Otdel,DC=firma,DC=net could not be deleted (pruned) from the Active Directory directory service.  Error: 80070005. The spooler will periodically try to remove the entry until it is successful. Continued failures may indicate an Active Directory problem, a basic network problem, or a communication problem between the domain controller and the print server.

    So I think it must be investigated further

  • 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.

  • 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...)

  • There is no impact for a large environment.

  • Without powershell AD module:

    For /f "delims=" %a in ('dsquery ou -limit 0') do dsacls %a /d everyone:SDDT


  • 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


  • @JoeMats:

    Since applying <protect from accidential deletion> is nothing else than adding a deny Delte/DeleteChild for Everyone to the object'sDiscretionaryACL - you may just add the proper SDDL string to the defaultSecurityDescriptor attribute of the corresponding schema class.

    The SDDL would look like this:



      D -> Deny

      SDDC -> SD+DC = Delete + DeleteChild

      WD = Everyone

    The defaultSecurityDescriptor stored in the schema will be applied to new objects on object creation.

    If you want to enable the setting for all new user objects for example:

    - find the user class object in the schema - CN=User,CN=Schema,CN=Configuration,DC=x...

    - add (D;;SDDC;;;WD) to the SDDL string in the defaultSecurityDescriptor attribute to make it look like this one:


    Caution! Please to not overwrite the defaultSecurityDescriptor attribute - add the AccessControlEntry (D;;SDDC;;;WD)!