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
Easy!
Tags: AD, AD cmdlets, Active Directory, Examples, Exchange, Exchange 2007, PowerShell, Security, cmdlets, one-liner, oneliner
Subscribe by email
Dmitry's Blog: Cloud, PowerShell and beyond 
Nice.
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?
Rob,
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
Administrators
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: http://powergui.org/forum.jspa?forumID=173
Dmitry
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 http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/05/29/49659.aspx
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.
Rob,
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 }
Dmitry
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.
Thanks for posting the update!
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
If you find any issues with the Quest cmdlets, please try to ask experts on Quest Comminity (http://communities.quest.com/community/activeroles?view=discussions)
Next, I tried to run the following commands against domain having over one thousand user accounts
1)
$users = Get-QADUser -Sizelimit 0 -IncludedProperties adminCount
$users | ft Name,adminCount
2)
$users | Set-QADUser -ObjectAttributes @{adminCount=1}
3)
$users | Set-QADUser -ObjectAttributes @{adminCount=0}
Did not found any issues with that.
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.
Hi,
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?
Thanks
Raghavan R
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 http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.windows.activedirectory.dsml
If you feel this is PowerShell-related, http://powergui.org/forum.jspa?forumID=173 is a good forum to ask your questions.
Dmitry
In my enviroment script don’t work. Correct script I find here.
http://powergui.org/thread.jspa?threadID=9994
Thanks Andrey! I will update the post.
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?
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.