A user attempts to reset their password using Forefront Identity Manager 2010 self-service password reset (SSPR). The user successfully authenticates via the question and answer (Q&A) gate, provides the new password and receives the error:
An error occurred when trying to reset your password, please contact the helpdesk for assistance.
Here’s a screenshot:
If you look at the request log you’ll see that the action WF failed (screenshot below).
If you inspect the action WF that failed with a PostProcessingError you’ll see a request status detail of:
Exception of type 'System.Workflow.ComponentModel.WorkflowTerminatedException' was thrown.
To get at the real error you need to look in either the event log or the trace file. Identify the PostProcessingError in the FIM Service event log or the service trace (in the event log it’ll be a warning event) and then scroll down and you’ll see an error. Here’s one such example:
PWReset Activity's MIIS Password Set call failed with call-failure:0x80004005
That hexadecimal value is an access denied error.
Which account needs permissions to reset the password? The AD DS MA account. The Password Reset Action WF makes a call into the FIM Synchronization Service WMI interface to perform the password reset. That interface is told the target by way of the CS Object returned from this WQL query:
WQL:SELECT * FROM MIIS_CSObject WHERE (Domain='CORP' AND Account='paulw-admin') or (FullyQualifiedDomain='CORP' AND Account='paulw-admin') or (Domain='CORP' AND UserPrincipalName='paulw-admin') or (FullyQualifiedDomain='CORP' AND UserPrincipalName='paulw-admin')
Note that if that WQL query fails the password reset will actually fail with this error:
Password Reset Activity could not find Mv record for user.
An aside that might be helpful, that means that FIM can’t find the target. I occasionally hit this in the lab when I script the creation of users via PowerShell and forget to put them within the scope of Synchronization. J
Grant the AD DS MA account the Reset Password Control Access Extended Right as well as write property (WP) on userAccountControl and lockoutTime.
Ignoring all other permissions for now, for SSPR you need to be able to Set a password (not change) and modify userAccountControl and lockoutTime (the latter unlocks locked out users).
Note. You don’t have to unlock users (see the bottom-most checkbox below). But why wouldn’t you do that?
The above figure is the Password Management Settings dialog (accessed by clicking Settings… in the screenshot below).
You’ll need to define these permissions within the scope of management of FIM. Here’s one approach. Assuming all users are located within child OUs of departments within a departments OU, e.g. CN=Bischoff\, Jimmy, OU=Users, OU=Human Resources, OU=Departments & Functions, DC=corp, DC=tailspin-toys, DC=com.
You can grant the necessary permissions to an SG called “Create and update user objects” to which the AD DS MA account belongs with three DSACLS commands. I’ve wrapped the commands into a CMD script. Save the following with a CMD or BAT extension and run under an account with permissions to change permissions in AD DS.
set targetDN=OU=Departments ^& Functions,DC=corp,DC=tailspin-toys,DC=com
set trustee=CORP\Create and update user objects
echo "Reset Password" Control Access Right (CAS)
dsacls "%targetDN%" /I:S /G "%trustee%":CA;"Reset Password";user 1>NUL
echo Write Property lockoutTime on descendant user objects
dsacls "%targetDN%" /I:S /G "%trustee%":WP;lockoutTime;user 1>NUL
echo Write Property userAccountControl on descendant user objects
dsacls "%targetDN%" /I:S /G "%trustee%":WP;userAccountControl;user 1>NUL
echo All done.
I made it difficult for myself with the ampersand character in the example above so that you can see how to escape characters. Note that I use the top-most OU to define the permissions. I make use of permissions inheritance to flow these permissions down to the OUs in which the users really reside.