Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am failing on delegating a user to reset passwords. I made all the minimum permissions of

Reset password Read pwnlastset Write pwnlastset

The user inherits from Account Operators group.

I'm reviving an Access is Denied when i try to reset the password.

Any ideas?

share|improve this question
1  
What do you mean by "The user inherits from Account Operators group." Do you mean that the user that is having issues is an Account Operator? Or that the account that you are trying to reset is an Account Operator? –  MDMarra Nov 11 '11 at 20:10
add comment

3 Answers

This can be caused by a number of things. The the three most obvious are:

1) The delegation is not inheriting correctly down the OU structure. Inspect the permissions of an actual user account object or sub-OU in AD and make sure that the group that you are delegating to is listed correctly.

2) You did not delegate the correct permissions. For simple operations like Reset Password, there are pre-defined ACEs in the delegation wizard. Run the delegation wizard on the appropriate OU and check the "Reset user password" option. This will simplify your direct interaction with the AD permissions to rule this out.

3) The user account that you are trying to reset might be protected from permission inheritance. This happens if they are a member of certain built-in AD groups. Inspect the user account in question and make sure that the admincount attribute is 0. If it is 1, then it means that it is or was a member of a protected group, such as Account Operators or Backup Operators. Active Directory does not allow permissions to inherit to these accounts.

share|improve this answer
add comment

The only other attribute that I can think of that might matter for a reset is userAccountControl - it'll be used if, for instance, you check the "Password never expires" box.

If that doesn't work, enable security logging for AD changes, then watch for which attribute is failing in the audit log - but before doing that, start with the basics; make sure the user making the change has allows (and no denys) for the right items in the effective permissions tab.

share|improve this answer
add comment

First you should use the delegation wizard rather than manually setting passwords. This ensures that the proper permissions have been set. In this case these are the correct permissions. Second make sure the user is a member of the correct group you have delegated rights on. Lastly ensure that you are trying this against a DC that has had the changes replicated to. You can force replication to the DC that the user has authenticated against (which will be the one that the snapin connects to by default) or connect the snapin to the DC that you have made the changes on.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.