Tight Active Directory Control
Long story short, I have a guy working on setting up a security group with rights to be able to manipulate user accounts.
I've backed up a bit off of my initial model of restricting their functionality.
They're users who want to be able to unlock user accounts and reset passwords but only on accounts that don't have domain admin level rights....ie regular user accounts.
I don't want them creating accounts, moving accounts into groups, etc. Just unlock...I'm even willing to sacrifice the reset password.
Something is behaving oddly and its not working quite right. The guy working on it is spinning his wheels and is about to call in reinforcements. He's a consultant.
This shouldn't be hard to do. He even had an issue with an account that was in the Account Operators group unlocking a locked account. Odd.
Thoughts?
I've backed up a bit off of my initial model of restricting their functionality.
They're users who want to be able to unlock user accounts and reset passwords but only on accounts that don't have domain admin level rights....ie regular user accounts.
I don't want them creating accounts, moving accounts into groups, etc. Just unlock...I'm even willing to sacrifice the reset password.
Something is behaving oddly and its not working quite right. The guy working on it is spinning his wheels and is about to call in reinforcements. He's a consultant.
This shouldn't be hard to do. He even had an issue with an account that was in the Account Operators group unlocking a locked account. Odd.
Thoughts?
peakpeak
What's the question?
ASKER
I only want users to have the ability to unlock accounts. No other access. This would be setup for helpdesk techs. I do not want them to be able to do anything else except unlock accounts.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Akhater, yes, they would only be able to unlock accounts in OU's of regular users, nothing the same or above them.
Thank you.
Thank you.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
yea so just create an OU for regular users and delegate as showed in the link above to a group called, say, allow account unlock,
add your helpdesk to this group
add your helpdesk to this group
Thank you Chris for shedding the light on this!
just to add to what Chris said (and correct myself ) even if you force inheritance and a user member of the AD protected groups AD will reset it periodically
ASKER
Thanks, I will definitely keep this in mind.
This can be done rather easily, but first a little back ground.
In AD, there are Protected Groups. These include Enterprise Admins, Schema Admins, Domain Admins, Account Operators,Sever Operators, Backup Operators and Print Operators. When you get added to anyone of these groups, an attribute called "ADMINCOUNT" in your user account gets set to "1", marking you as a Protected User. The idea behind this is to prevent non-Administrators with some delegated permissions from being able to manage the user accounts of those with higher privileges.
Protected User Accounts (those accounts with the ADMINCOUNT = 1) dont inherit permissions from the OU they are in, like most accounts do. Instead, their AD Permissions are copied from the AdminSDHolder object, which can be seen in ADUC under the SYSTEM node with Advanced Features turned on. Adjust Security on this object, and it will adjust every Protected Account to match. This is why some accounts can not be managed by users who have been delegated permissions. Check the permission on AdminSDHolder to make sure the Help Desk staff doesn't have permissions.
Note: Removing someone from all Protected Groups does NOT reset the ADMINCOUNT attribute. This must be done manually or via script.
You need to grant permissions manually by going to the Properties of the OU, Security Tab, Advanced Button. Click ADD, and select the group you want to grant permissions to. In the "Apply onto" drop-down, select User Objects. Then scroll down and find "Reset Password" and click Allow. Next, click the "Properties" tab and find the Read LockoutTime / Write LockoutTime properties and click Allow on those and click Ok. That should do it.
Keep in mind, these permission will not be inherited by accounts who are a member of any of the Protected Groups listed above.
In AD, there are Protected Groups. These include Enterprise Admins, Schema Admins, Domain Admins, Account Operators,Sever Operators, Backup Operators and Print Operators. When you get added to anyone of these groups, an attribute called "ADMINCOUNT" in your user account gets set to "1", marking you as a Protected User. The idea behind this is to prevent non-Administrators with some delegated permissions from being able to manage the user accounts of those with higher privileges.
Protected User Accounts (those accounts with the ADMINCOUNT = 1) dont inherit permissions from the OU they are in, like most accounts do. Instead, their AD Permissions are copied from the AdminSDHolder object, which can be seen in ADUC under the SYSTEM node with Advanced Features turned on. Adjust Security on this object, and it will adjust every Protected Account to match. This is why some accounts can not be managed by users who have been delegated permissions. Check the permission on AdminSDHolder to make sure the Help Desk staff doesn't have permissions.
Note: Removing someone from all Protected Groups does NOT reset the ADMINCOUNT attribute. This must be done manually or via script.
You need to grant permissions manually by going to the Properties of the OU, Security Tab, Advanced Button. Click ADD, and select the group you want to grant permissions to. In the "Apply onto" drop-down, select User Objects. Then scroll down and find "Reset Password" and click Allow. Next, click the "Properties" tab and find the Read LockoutTime / Write LockoutTime properties and click Allow on those and click Ok. That should do it.
Keep in mind, these permission will not be inherited by accounts who are a member of any of the Protected Groups listed above.