The Question:
This morning we hired a new and wonderful guy for our Help-desk and when setting up this persons account a strange oddity occured that caused one of the other helpdesk workers to come over to me and ask, “Hey why can’t I reset this new guys account? I can reset anyone else’s account but not his”. Now, I’m not proud I’ll admit at first I was stumped on this one there shouldn’t be any reason why you can’t reset his account I said – Mildly grumpy having only had one cup of coffee so far that day – Show me what you mean!
Sure enough after walking over to his desk I watched him crack open AD Users and Computers and he couldn’t reset the guys password.
The Assumptions:
During this initial observation I made several assumptions and in order for this scenario to make sense some more information is required.
- This Organization does NOT use elevated accounts. It’s written in the standards document but the document hasn’t been ratified and implemented yet.
- The Organization DOES use delegated rights over accounts to allow certain users to be able to reset accounts that are a part of a single OU.
- The User attempting the modification is a member of a group that has been delegated those rights.
- The User who is being modified is in an OU that the other user has delegated rights over.
The Problem:
In a NORMAL use case scenario this wouldn’t have come up this particular challenge arose from a specific set of circumstances. The user we were attempting to modify (We’ll call him the User) and the user doing the modifying (We’ll call him the Admin for now) was created in a DIFFERENT OU than his final resting place, and prior to being moved there he was added to a security group that was NESTED in one of the Active Directory Protected Groups.
What you ask, is an active Directory Protected Group? Well let’s start by listing what they are from the Microsoft Technet Website:
| Windows 2000 Server RTM Windows 2000 Server with SP1 Windows 2000 Server with SP2 Windows 2000 Server with SP3 |
Windows 2000 Server with SP4 Windows Server 2003 RTM |
Windows Server 2003 with SP1 Windows Server 2003 with SP2 |
Windows Server 2008 RTM Windows Server 2008 R2 |
| Administrators | Account Operators | Account Operators | Account Operators |
| Domain Admins | Administrator | Administrator | Administrator |
| Enterprise Admins | Administrators | Administrators | Administrators |
| Schema Admins | Backup Operators | Backup Operators | Backup Operators |
| Cert Publishers | Domain Admins | Domain Admins | |
| Domain Admins | Domain Controllers | Domain Controllers | |
| Domain Controllers | Enterprise Admins | Enterprise Admins | |
| Enterprise Admins | Krbtgt | Krbtgt | |
| Krbtgt | Print Operators | Print Operators | |
| Print Operators | Replicator | Read-only Domain Controllers | |
| Replicator | Schema Admins | Replicator | |
| Schema Admins | Server Operators | Schema Admins | |
| Server Operators | Server Operators |
So, what does this actually mean? Well when a user account is added to one of the protected groups a few things happen. For starters every hour Active Directory starts this wonderful process that looks at users that are a member of these protected groups. Then upon finding those members it reaches out and sets the AD attribute “AdminCount” to the value of 1. This signifies to ActiveDirectory that this account is an “Administrative” account and to disable inheritance on the object and to enforce the security of AdminSDHolder.
The Resolution:
Fortunately in this case the simple solution to achieve the desired behavior in this environment was “acceptable”. However, it doesn’t solve the problem as a whole. The simple one off solution is using active directory users and computers from a domain administrator account enable inheritance on the user object. This will allow the appropriate inherited permissions to flow down on to the user before locking the account again from being edited by delegation on OU’s. This however, is NOT a long term solution.
The correct LONG term solution would be to create an elevated account for ANY user that NEEDS to be a member of a protected group and place them in a dedicated OU in accordance with Microsoft best practices.
Currently in development here at problem resolution is a script that will regress through a users security groups and list the protected group the user is a member of as well as the group path that provided that membership.
