Forefront Identity Manager 2010 Self Service Password Reset Error: System.Workflow.ComponentModel.WorkflowTerminatedException


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:

More information

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.

@echo off 

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 

set targetDN= 
set trustee= 

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.


About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM, FIM 2010, Self Service Password Reset, Troubleshooting and tagged , , , , , , , , , . Bookmark the permalink.

4 Responses to Forefront Identity Manager 2010 Self Service Password Reset Error: System.Workflow.ComponentModel.WorkflowTerminatedException

  1. Pingback: Delegating the minimum set of permissions for user provisioning | Yet another identity management blog

  2. Pingback: PWReset Activitiy’s MIIS Password Set call failed with ma-access-denied | Yet another identity management blog

  3. Hi Paul,

    We currently have an ASP.NET application running for organization. We also put Forefront TMG 2010 to authenticate users who will access to the ASP.NET application. Because my employees often forget password and they ask my System team to help them reset password. So thus I really want a Self-Service Password Reset in the Forefront TMG 2010 Login page, in order to my employees have the ability to reset their own password themselves. After they reset password, email system will send to them a confirmation email or an email which include their passwords they have changed.

    Do you know if Forefront TMG could have the capability? I have heard FIM 2010 has such a capability, but still can’t find any documentation covering this capability. I also get understanding of how FIM 2010 helps reset password via this video: , but my case is different from this video.

    Your ideas are always greatly appreciated.

    Many thanks and Best regards,


    • Hi T.S.

      TMG, IIRC, has password change (as well as expiry notification) capabilities when using Forms Based Authentication (FBA). It doesn’t have password reset capabilities.

      UAG has the same capabilities.

      For password RESET you need FIM. SSPR allows registered users to reset forgotten passwords in a secure manner. In FIM R2 we have Internet/extranet SSPR which means we support clients outside of the domain on all sorts of devices like iPads, Android phones, etc.

      For your scenario the best you can do is publish FIM R2 SSPR portal via TMG and have a URL to the SSPR page on your ASP.NET logon page. Bug users to register when they logon and you have a solution.

      Here’s some more info.:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s