Find and fix broken inheritance

Broken permissions inheritance can be a source of multiple issues – with PowerShell you can get such issues located and fixed with an easy oneliner.

Getting security inheritance blocked is easy – locating and setting it back can be hard. One big customer of ours once had most of their mail transport paralyzed with a branch administrator clearing the inherit permissions checkbox he thought should not have been there. Nicolas is reporting similar issues with Exchange 2007 deployments.

Seeing whether an AD object has permissions inheritance blocked is as easy as checking the object’s DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected property.

So for example, to get a list of all users in the domain who has inheritance off you just need to run:

Get-QADUser -SizeLimit 0 | where {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected}

I am using -SizeLimit 0 so I retrieve all users and not just the default 1000.

Fixing inheritance is even easier with the new Set-QADObjectSecurity cmdlet introduced in AD cmdlets 1.1.

So if you want to fix inheritance for all AD users (caution: you might want to just get the list of the accounts first using the command above to make sure you do not “fix” legitimate exceptions) you just need to pipe the collection into Set-QADObjectSecurity -UnlockInheritance:

Get-QADUser -SizeLimit 0 | where {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected} | Set-QADObjectSecurity -UnlockInheritance


Tags: , , , , , , , , , ,


16 Responses to “Find and fix broken inheritance”

  1. 1 Rob June 4, 2008 at 12:13 pm


    Any chance of getting the get-qaduser cmdlet to include a property for AdminSDHolder, so you can use it to find and fix the ones that are going to be broken again tomorrow?

  2. 2 dmitrysotnikov June 4, 2008 at 1:32 pm


    I am not sure I understood what you mean.

    You want to know which accounts AdminSDHolder affects? As far as I understand these are:

    Windows 2000 SP3:
    Enterprise Admins
    Schema Admins
    Domain Admins

    Windows 2000 SP4 oder Windows Server 2003 additional:
    Account Operators
    Server Operators
    Print Operators
    Backup Operators
    Cert Publishers

    Additional the accounts Administrator and krbtgt are protected.

    If you want to know which permissions are set on AdminSDHolder, you can find this by executing:

    Get-QADPermission “cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com”

    If there’s anything else you would like to be implemented in AD cmdlets I encourage you to post your suggestions at:


  3. 3 Rob June 4, 2008 at 3:03 pm

    The AdminSDHolder attribute determines if an account is subject to having it’s permissions reset by AD according to the AdminSD settings of the domain. The default is to disable inheritance on the accounts.

    It’s explained pretty well at

    If an account is placed in a “protected” group it gets it’s AdminSDHolder attribute incremented. Any account that has a value > 0 for that attribute will get it’s permissions reset based on the AdminSD settings automatically. This includes removing inheritance.

    Removing the account from the protected group does not decrement this value. An account that has had this attribute incremented will continue to have it’s inheritance automatically reset by AD every 24 hours until that attribute is manually reset to 0.

    Groups also have an AdminSDHolder attribute, and a group placed into a protected group will get the attribute incremented, and it will then increment the attribute for all members of the group. Even after the group is removed from the protected group, it will still have the attrute set, and will continue this behaviour until it is manually reset to 0.

    Examining and resetting the AdminSDHolder attribute of an object is the only way to find and correct the automatic resetting of the permission inheritance by AD for objects that have been added to, and then removed from a protected group.

  4. 4 dmitrysotnikov June 4, 2008 at 3:48 pm


    If what you want is manipulate the adminCount attribute – you can do that already.

    To get all users with the attribute set do:

    get-qaduser -sizeLimit 0 -IncludedProperties adminCount | where { $_.adminCount -gt 0 } | ft Name, adminCount

    To change you can try (have not trued in my lab yet) :

    Set-QADObject identity -ObjectAttributes { adminValue=0 }


    • 5 tradosh July 12, 2012 at 9:38 am

      the command to apply the change have to be updated to: Set-QADObject identity -ObjectAttributes @{ adminCount=0 } and it than work, you can apply that command as the AD task that run hourly will than crawl through those accounts again and increase the count back to 1.

      • 6 Dmitry Sotnikov July 12, 2012 at 1:03 pm

        Thanks for posting the update!

      • 7 tradosh July 13, 2012 at 10:56 am

        The only problem that I noticed, after running that command it sets value to 0 but it haven’t updated for accounts that should be updated back to 1. It did when I run that on single account but I had over 3000 accounts that had it set to 1, after I run command it dropped back to 0 but never increased so I had manually go through them to update it back

      • 8 Sargay July 18, 2012 at 9:55 am

        If you find any issues with the Quest cmdlets, please try to ask experts on Quest Comminity (

        Next, I tried to run the following commands against domain having over one thousand user accounts

        $users = Get-QADUser -Sizelimit 0 -IncludedProperties adminCount
        $users | ft Name,adminCount

        $users | Set-QADUser -ObjectAttributes @{adminCount=1}

        $users | Set-QADUser -ObjectAttributes @{adminCount=0}

        Did not found any issues with that.

  5. 9 Rob June 4, 2008 at 3:54 pm

    Thanks. I apologize for the mistaken object attribute name. It is indeed “AdminCount” on the object.

    This is admittedly a rather obscure issue, but can be frustratingly tenacious when dealing with mysterious loss of inheritance of AD object permissions.

  6. 10 Raghavan July 6, 2008 at 8:43 pm


    Thanks for the post.

    I have a windows and Exchange 2003 running 2K native mode. Need an user to have read and write permissions for 9 user attributes for all the users in the forest. When I gave that permission through delegate control, all users had it inherited except protected group members.

    I changed the permissions for adminsd object per MS. Added the user id to adminsd and provided permissions for reading and writing those 9 attributes. while I am able to see taht the permissions are given, the user id is not able to change the values of those attributes. It is greyed and LDIFDE provides Insufficient rights.

    Any idea if I have to do anything else?


    Raghavan R

  7. 11 dmitrysotnikov July 7, 2008 at 9:45 am

    Raghavan, as far as I understood your message this is not PowerShell-related since you were making all the changes in other tools. If this is correct, I would post the question to Active Directory newsgroups such as

    If you feel this is PowerShell-related, is a good forum to ask your questions.


  8. 12 Andrey Vakhitov October 5, 2009 at 4:33 am

    In my enviroment script don’t work. Correct script I find here.

  9. 13 Dmitry Sotnikov October 5, 2009 at 6:52 am

    Thanks Andrey! I will update the post.

  10. 14 Jim December 28, 2009 at 2:09 pm

    I cannot get your cmdlets to install on Windows 7 x64. Error 1033. Downloaded files multiple times, but will not work.

    Is Windows 7 supported?

    • 15 Dmitry Sotnikov December 28, 2009 at 2:21 pm

      Jim, yes, Windows 7 is fully supported, and there is a version specifically for x64.

      Looks like the file itself got corrupt during the download process and this version got cached by your proxy. Try downloading from another network – e.g. home.

  1. 1 What is adminSDholder ? | Jacques DALBERA's IT world Trackback on July 1, 2013 at 9:54 pm

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

June 2008
« May   Jul »

%d bloggers like this: