One of the ways of limiting the unnecessary use of "Domain Admin" privileges is to use Delegation of Control to create Security Groups with rights to reset passwords and adjust group membership. If you are interested in a step by step guide to create a password reset group using "Delegation of Control," please refer to the following article here:
[How to delegate password permissions for your staff]
In our case, we established two groups with separate level of access:
- Account Management (full control over all student and faculty user objects, no access to service accounts)
- Reset Student Passwords (password reset only on student user objects)
Unfortunately, our IT personnel reported that were denied access to reset certain user objects that are considered "Administration" personnel. However, when we look at the "Delegation of Control" settings for the "Administration" personnel container, the Account Management group permissions are being applied as intended.
So, what gives?
The objects inside the container did not have Permissions Inheritance enabled, and subsequently were not receiving the permissions that were applied from their container. My current theory is that because we "copy" a user from the same container when we create a new user in Active Directory, we have been copying off of a user that existed prior to our Server 2008 migration (when Permissions Inheritance was first implemented.)
Enabling permission inheritance via PowerShell is (relatively) painless as long as you aren't allergic to command line interface! An interesting article here provides documentation on how to programmatically solve this problem: Function: Set-AdminUser – Clear AdminCount and Enable Security Inheritance
Good luck, and happy scripting!