Really? Delegating Help Desk Accounts to unlock user accounts in the environment will not work?
One afternoon while working at one of my customer sites, I noticed a user calling a Help Desk Associate to unlock their user account. The Help Desk Associate used Active Directory Administrative Center (ADAC) to unlock the users account, but received an error message indicating that he does not have sufficient rights to perform the operation.
We started investigating the rights delegated for the Help Desk Associate and found that the Associate indeed has all the required rights to unlock user accounts as specified in the KB article
Just delegating the user with appropriate permission should help here correct? Well, it did not in this case. Our research led us to the following KB article that explains the issue and the need for a Hotfix to resolve the issue.
Unlocking a user account fails when using ADAC or the Unlock-AD Account cmdlet in Windows 7 or Windows Server 2008 R2 even if sufficient permissions are granted
As indicated in the KB Article, the issue is due to fact that ADAC and Unlock-AD Account cmdlet require permissions to the UserAccountControl but thedelegated rights were assigned to the lockout Time attribute.
Prior to Windows Server 2008 R2, Active Directory Users & Computers (ADUC) is used to unlock an account In the Account Properties window as shown below:
You will notice from the screenshots below of the attributes using PowerShell, that when using ADUC, the attribute lockout Time is changed, but the UserAccountControl isleft unchanged.
The KB article also provides the workarounds to either use ADUC or grant additional permissions to the user account to use ADAC or Unlock-AD Account. If you considering the later, it is important to understand that it provides extra permissions in addition to unlock Account. The KB 305144 provides details on how UserAccountControl attribute can be used to manipulate other user account properties.