I configured a FIM 2010 R2 for Self Service Password Reset using Email OTP. This is documented quite well on TechNet. However when my test user provided the OTP and entered a new password he got greeted with an error:

In words: An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)

In order to explain when this issue occurred:

1. I Provided the username
2. I Received the OTP in my mailbox
3. I Entered the OTP in the form
4. I Provided a password in the form
5. I Clicked Next

In order to solve this I tried/verified the following items:

• FIM Password Reset site debug logging (Paul Williams: Troubleshooting the FIM 2010 R2 Password Registration and Reset Portals )
• WMI permissions (my blog: FIM: SSPR: Verify WMI Permissions )
• Added AD MA account to Domain Admin (blunt, but just to see if there’s no permission issue)
• Added FIM Svc account to Local Admin (blunt, but just to see if there’s no permission issue)
• Reboot server/services
• Checked if password management was enabled on AD MA
• Checked if objectSID, accountName & Domain were present in MV
• Check if FIM Service account was member of FIMSyncPwdReset group

Besides the user being confronted with an error in his browser I also noticed the following events in the event log.

• Log: Forefront Identity Manager
• Source: Microsoft.ResourceManagement
• Level: Warning
• Text: System.Workflow.ComponentModel.WorkflowTerminatedException: Exception of type 'System.Workflow.ComponentModel.WorkflowTerminatedException' was thrown.

• Log: Forefront Identity Manager
• Source: Microsoft.CredentialManagement.ResetPortal
• Level: Error
• Text: The error page was displayed to the user.

  Details:

  Title: Error

  Message: An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)

  Source:

  Attributes:

  Details: System.InvalidProgramException: Error while performing the password reset operation: PWUnrecoverableError

• Log: System
• Source: Microsoft.CredentialManagement.ResetPortal
• Level: Error
• Text: Microsoft.IdentityManagement.CredentialManagement.Portal: System.Web.HttpUnhandledException: ScriptManager_AsyncPostBackError ---> System.InvalidProgramException: Error while performing the password reset operation: PWUnrecoverableError

• Log: System
• Source: Microsoft.CredentialManagement.ResetPortal
• Level: Error
• Text: The web portal received a fault error from the FIM service.

  Details:

  Microsoft.ResourceManagement.WebServices.Faults.ServiceFaultException: DataRequiredFaultReason

• Log: System
• Source: Microsoft.ResourceManagement
• Level: Error
• Text: mscorlib: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

  at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

  at System.Management.ManagementScope.InitializeGuts(Object o)

  at System.Management.ManagementScope.Initialize()

  at System.Management.ManagementObjectSearcher.Initialize()

  at System.Management.ManagementObjectSearcher.Get()

  at Microsoft.ResourceManagement.PasswordReset.ResetPassword.ResetPasswordHelper(String domainName, String userName, String newPasswordText)

Besides the above entries I also stumbled upon this one:

In words: The program svchost.exe, with the assigned process ID 684, could not authenticate locally by using the target name RPCSS/fimsyncdev.contoso.com. The target name used is not valid. A target name should refer to one of the local computer names, for example, the DNS host name.

Try a different target name.

As far as I could tell this entry did not got logged when a user attempted a reset or when the service got restarted, but it was logged a few times nevertheless.

After seeing this one it finally came clear: I like to use a DNS alias to target the FIM Synchronization Server when installing the FIM Service bits. This makes it easier when I have to activate my cold standby FIM Synchronization server. Typically you got two options for creating an “alias”:

1. An A record
2. A CNAME record

Scenario 1 is very much the preferred scenario when working with web applications. It makes registering your SPN’s way more logic as you just add them to the service account (the application pool identity). However here we have a special version of this scenario. The password reset relies on WMI/DCOM and it should be authenticated to those in order to successfully execute a set password. The WMI/DCOM stuff doesn’t run as a service account, it’s a service which runs under the local system account. Even if I would add my alias as an SPN on the computer account of the active FIM Sync server I would have to modify this SPN when activating my cold standy server.

So long story short: if you feel like using an alias for your FIM Synchronization Server is interesting, use a CNAME. Normally I do in this scenario, but for this specific customer it slipped through and caused me some hours to figure it out.  On the other hand I learned something about DCOM and it’s authentication stuff.