Password reset delegation not working

Whenever you’re working in an Active Directory domain you didn’t setup yourself, there’s a good chance someone has made changes that won’t be obvious. Therefore implementing further changes may not always have the expected results even if you’ve tested them thoroughly in a test environment. Active Directory is a complex system with many dependencies and there are lots of ways to modify it. I found this out the hard way when trying to configure a few users to be password reset delegates at a client. Even though everything was configured properly, the delegate users were getting the error “Windows cannot complete the password change for <user> because: Access is denied.” Here is how I determined the cause of the issue and resolved the problem:

Fist a bit of background. I am a big believer of testing before implementation…but since production environments are not test environments, there are often things that can catch you by surprise during implementation. Production environments can be a smorgasbord administrative tweaks and changes made by all kinds of folks and not necessarily according to best practices. Adding protected groups to other protected groups can be an example of this (think domain users in print operators, etc.). So when something that should work just doesn’t, that’s when you get to put on your detective cap and start burning up billable consulting/engineering hours.

In this case what should have been a quick 30 minute job turned into a several hour deal. Here’s what happened:

[step 1] I created a security group named S – Delegated Users and added three users (which the client had previously deemed to be trusted to reset user passwords) to it.

[step 2] I followed the standard Microsoft practice for password reset delegation on a specific Organizational Unit (OU) in Active Directory by right-clicking the OU and launching the Delegation of Control Wizard by clicking Delegation Control…

[step 3] In the wizard I added the group S – Delegated Users and selected the Reset user passwords and force password change at next logon common task.

[step 4] I downloaded and installed Remote Server Administration Tools on the client workstation (Windows 7 Professional x64).

[download] the Remote Server Administration Tools for Windows 7

[step 5] I added the Active Directory Role Administration features on the client workstation.

[step 6] (optional) Created a custom MMC with the Active Directory Users and Computers (ADUC) snap-in that easily lets the delegate admins reset user passwords. See the video below on how to do this:

[step 7] Test to make sure the user can actually reset the password by logging in on the delegate admin’s workstation, launching the MMC and performing a reset on a user account he has permissions to. This is where I ran into the aforementioned issue. Basically my delegated password admin got an access denied error attempting to reset passwords for user accounts he had just been grated to reset passwords for. So what gives?

[troubleshooting] After about an hour of poking around and checking properties, removing, re-applying delegate permissions on the OU, etc. I finally found the culprit. It was that most user accounts in the OU I had chosen to delegate control for were set to not inherit permissions from the parent object. I found this by clicking on an account and checking the advanced permissions. Basically, if the include inheritable permissions from this object’s parent box isn’t checked, then you can delegate control at the OU level all day long, the objects in that OU won’t inherit the changes. So make sure that your accounts are set to include inheritable permissions from this object’s parent.