Delegated AD permissions not inheriting on User object

Domain: DFM is Windows 2008 and DCs run Windows 2008 SP2. Changes are made with either Server 2008 ADUC or Windows 7 ADUC.

I have several administrator accounts that are not inheriting delegated permission because the system is removing the "Include inheritable permissions from this object's parent" option. This usually occurs when the user account is a member of a critical group such as Backup Operators. As I understand it, if they are part of a critical group adminCount is set to 1 on the account. Then when the task Security Description Propagator (SDProp) runs it actually enforces the protection mechanism to remove the setting. I have checked the accounts with ADSIedit and AdminCount is set to 1. Changing it to 0 did not worked as the value changed back on its own.

With all that said, I cannot find a "critical group" these user are a member of. They had previously belonged to Domain Admins but were removed  several months ago. I attempted to copy the account, as well as build a brand new one and add the same groups from scratch. In both cases they behaved the same; the check mark is removed and permissions do not inherent.

So I am thinking either one of these group has become critical and I am unaware of it or the accounts are "tattooed" from being in a critical group in the past. Any idea how to determine which it is and resolve it? Thanks!
dumamoAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

footechCommented:
Sounds like your understanding of the issue is correct.  Just for reference, here is a list of accounts and groups that protected groups.
Administrator
Administrators
Backup Operators
Domain Admins
Domain Controllers
Enterprise Admins
Krbtgt
Print Operators
Read-only Domain Controllers
Replicator
Schema Admins
Server Operators
Here's a good blog entry that covers a lot of detail.
http://policelli.com/blog/archive/tag/privileged-groups/

Since the adminCount attribute is being reset, I would say that the accounts in question are member of one of these groups, either directly or through nesting.  It's true that if they were members of Domain Admins, that the adminCount attribute would be set to 1, and this wouldn't be reset to 0 when they were removed from the group.  Also, ACL inheritance wouldn't be reset.

Try running the .VBS script found at http://support.microsoft.com/kb/817433
This will set the adminCount attribute to 0 and reset the inheritance.  However, if the accounts are still members of a protected group they will get reset the next time the SDProp task runs.  If the users do get reset, then it's pretty much down to tracking down group membership, especially looking at nested groups to make sure nothing is missed.  There are a couple of Powershell commands mentioned in the blog linked to above for you to list user accounts and groups that are protected, but neither of these will tell you if a user account is protected because it is a member of a nested group.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
dumamoAuthor Commented:
For clarification: you are saying if the user account is in a group called IT-Support and that group is nest in a protected group, then the account is considered part of the protected group? I believe in AD2003 they had to be direct member, but I did not realize nesting could be the culprit.  

All of the groups I see are admin created, so this would be the only explanation if true. Thanks!
0
footechCommented:
That is correct.  Also note that both security and distribution groups are considered.  You might try using the whoami command to view group membership.

This may not be important, but I don't understand your statement about the groups being admin created and how this would be a factor.
0
dumamoAuthor Commented:
What I meant by admin created was we have groups we created as admins and groups the system created. The system groups are the usually the protected groups and I did not realize nesting played a role here. Therefore when I only saw groups we created in the users Member of tab, I assumed there were no protected groups on the account. Thanks!
0
footechCommented:
Gotcha.

You're welcome.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.