none
FIM Password registration is successful but password reset is fails RRS feed

  • Question

  • We have installed FIM password registration and password reset portals on different server. The Sync engine & FIM service is already installed on one server. We are getting below error while performing password reset for a user.

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

    Let me know if you require any more information.

    Thursday, April 24, 2014 9:45 PM

All replies

  • There can be multiple issues with this result - check your event log to verify more.

    Here are some articles that helps to troubleshoot Error 3000 (the most common) during password reset:

    [Troubleshooting] SSPR Error 3000 Troubleshooter

    Troubleshooting FIM 2010 R2: SSPR Error 3000 and 3004 – not authorized to register for password reset

    FIM 2010 R2 Password Reset Configuration Troubleshooting

    You have not given us any clues what could be the reason of this error, so I won't guess which scenario would work in your case.



    If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Friday, April 25, 2014 5:39 AM
  • As Dominik wrote - multiple things might be wrong. First you should check if your user is populated with account name, domain and SID in FIM service.

    Then check if you are registered for SSPR. If you have modified standard sets for SSPR users you may want to check if user is still in a scope of users assigned to SSPR workflow. 


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    Friday, April 25, 2014 8:19 AM
  • Here’s are the details of what we’ve done so far, and the issues encountered.

    1. First we clarified the proposed architecture of the lab POC.  The FIM Synchronization Service and FIM Service and Portal are running on a single server, and the Password Registration and Reset Portals are to be installed on a separate server.  Both portals will be configured (for now) to be accessible only from the Intranet.
    2. We completed the pre-requisites for the portal installation, detailed here (http:/technet.microsoft.com/en-us/library/jj134282(v=ws.10).aspx) including all of the following:
    • Enabling all specified MPRs, including one not listed in the above document, but is indicated here: http:/technet.microsoft.com/en-us/library/ee534892(v=ws.10).aspx
    • Enabling password management in the AD management agent.
    • Granting permissions in AD for the AD MA service account to change and reset passwords, and modify the userAccountControl and lockoutTime attributes.
    • Granting “Replicate Directory Changes” permissions in AD for the AD MA service account.
    • Granting permissions for the FIM Service service account to the ROOT\CIMV2 namespace in WMI.
    • Enabling DCOM for the FIM Service service account.
    • Ensuring test users are members of the set “Password Reset Users Set”.
    • Updating the “Password Reset AuthN Workflow”.  This will require further review.
    • Adding the one-time password attributes to the MPR “Administration: Administrators can read and update Users”.
    3. We skipped the firewall requirements, as Windows Firewall is disabled on both servers by policy.
    4. We installed the Password Reset and Registration Portal as detailed here: http:/technet.microsoft.com/en-us/library/jj134295(v=ws.10).aspx
    5. As indicated at the end of the previously specified document, we ran the FIM Service and Portal setup in Change mode, providing details of the new FIM Password Reset and Registration Portal service account.  Then, we ran the Password Reset and Registration Portal setup again (in Change mode).
    6. After completing the previous steps, the Password Registration Portal will load. IE displays a credential prompt before the page appears, but we believe this can be fixed by adding the Password Registration Portal web server name to the Local Intranet zone in the IE Security settings.  We were able to login to the Registration website using a test account that is configured correctly in the FIM Portal: (1) Member of “Password Reset Users Set”, (2) has the required attributes (AccountName, Domain, ObjectSID).  We were able to provide answers to the default questions and complete the registration.
    7. Next we tried using the Password Reset Portal.  The page loaded without any issues, and we proceeded through each step: entering the username, answering the questions, entering a new password.  After clicking Next, we receive the following error:  “An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)”.
    8. Found this article: http:/social.technet.microsoft.com/Forums/en-US/e9e850fc-7c84-4e60-94a3-e20c80e5116b/fim-2010-r2-password-reset-portal-error-3001?forum=ilm2 Based on this information, we looked at how the other FIM service accounts were setup in the FIM Service.  We have two other service accounts: One is the service account for the FIM Service MA, the other is used for running PowerShell scripts.  Both of these service accounts were within scope of the AD management agent at some point in the past.  Thus they were projected into the MV and subsequently provisioned into the FIM Service.  At a later point, connector filters were created in the FIM Service MA for both accounts, and the AD accounts were taken out of the scope of FIM.  So now, these accounts only exist in FIM as filtered disconnectors in the FIM Service connector space.  To get the new Password Reset and Registration Portal service account setup the same way, we moved the account into an OU that was within scope of FIM.  We ran an import on the AD MA to project this account into the MV, and provision it to the FIM Service.  Then we disconnected the FIM Service object from the MV and moved the service account in AD back out of scope.  This resulted in the FIM Service object becoming a normal disconnector.  Then we added a connector filter to the FIM Service MA for the account, which caused it to become a filtered disconnector. Despite these measures, we still received the error message above.
    9. Side note: After making changes to anything involving the FIM Service or IIS, we restarted the FIM Service as well as running “IISRESET” to ensure the changes took effect.  If the change was on the server hosting the Password Reset and Registration portals, we ran IISRESET only (there is no separate FIM service on that server).  If changes were made that affected the FIM Synchronization Service, then we restarted that service as well.
    10. We have not yet setup the Password Reset and Registration Portals to use SSL.  At first inspection it appeared that we would not be able to use the same port number (443) for both the Registration and Reset portals.  This is because the Site Bindings dialog in IIS Manager does not allow you to specify a host header name if the binding type is https (the field becomes disabled).  We found the following information that seems to provide a workaround for this using the “appcmd.exe” tool: http:/social.technet.microsoft.com/Forums/en-US/80ed7ec4-dd50-4d55-907b-246a646c74ed/change-password-reset-and-password-registration-portal?forum=ilm2  However, we were not certain if this was the correct procedure.
    11. In the configuration for the AD management agent, on the “Configure Extensions” page under “Password management”, the “Settings” button has an option labeled “Require secure connection for password synchronization operations”. Researching this option revealed that the option will only work if the MA is configured to use either SSL or LDAP signing (on the “Configure Directory Partitions” page under Domain controller connection settings, Options).  We have the option “Sign and Encrypt LDAP Traffic” enabled, so we believe it is okay to leave the “Require secure connection” option selected as well.  Regardless, we tried disabling this option and testing the portal, but it did not appear to have any effect.
    12. We tried enabling Windows Authentication in IIS as indicated here:  http:/josetheadmin.blogspot.com/2013/12/fim-2010-r2-sspr-cannot-access-password.html However, this did not appear to have any effect either way.
    13. We tried enabling the “Use preferred domain controllers” option in the Active Directory MA configuration and entering only one domain controller, the PDC, in the list of preferred DCs, as indicated here: http:/social.technet.microsoft.com/Forums/en-US/1be8a720-cbaf-4d14-84ef-50cf8c694a3e/fim-2010-r2-sspr-policy-enforcement-prevents-all-passwords?forum=ilm2  However this also had no noticeable effect.

    In summary, here are the issues to be addressed (in no particular order):
    1. Fixing the error message that appears upon submitting a password reset request (after completing the security questions).
    2. How to configure Windows Firewall.  At present, it is disabled on both servers by policy.
    3. Configuring the portals to use SSL.  We’re not certain if both portals (Registration and Reset) can be configured to use the same port (443) or if different ports are required.
    4. Suppressing the credential prompt that comes up before the Password Registration portal loads (if implemeting SSL does not resolve this, then the proposed solution is to add site to Local Intranet zone).
    5. Proper configuration of Authentication Gates.  We have attempted to follow the guidelines detailed here (http:/technet.microsoft.com/en-us/library/jj134288(v=ws.10).aspx#gate_order) but it does not seem to be working as anticipated.
    6. Opening up Internet access for the Password Reset portal.

    We would appreciate any help you can provide in completing this effort.

    Thursday, June 5, 2014 7:32 PM
  • Here’s are the details of what we’ve done so far, and the issues encountered.

    1. First we clarified the proposed architecture of the lab POC.  The FIM Synchronization Service and FIM Service and Portal are running on a single server, and the Password Registration and Reset Portals are to be installed on a separate server.  Both portals will be configured (for now) to be accessible only from the Intranet.
    2. We completed the pre-requisites for the portal installation, detailed here (http:/technet.microsoft.com/en-us/library/jj134282(v=ws.10).aspx) including all of the following:
    • Enabling all specified MPRs, including one not listed in the above document, but is indicated here: http:/technet.microsoft.com/en-us/library/ee534892(v=ws.10).aspx
    • Enabling password management in the AD management agent.
    • Granting permissions in AD for the AD MA service account to change and reset passwords, and modify the userAccountControl and lockoutTime attributes.
    • Granting “Replicate Directory Changes” permissions in AD for the AD MA service account.
    • Granting permissions for the FIM Service service account to the ROOT\CIMV2 namespace in WMI.
    • Enabling DCOM for the FIM Service service account.
    • Ensuring test users are members of the set “Password Reset Users Set”.
    • Updating the “Password Reset AuthN Workflow”.  This will require further review.
    • Adding the one-time password attributes to the MPR “Administration: Administrators can read and update Users”.
    3. We skipped the firewall requirements, as Windows Firewall is disabled on both servers by policy.
    4. We installed the Password Reset and Registration Portal as detailed here: http:/technet.microsoft.com/en-us/library/jj134295(v=ws.10).aspx
    5. As indicated at the end of the previously specified document, we ran the FIM Service and Portal setup in Change mode, providing details of the new FIM Password Reset and Registration Portal service account.  Then, we ran the Password Reset and Registration Portal setup again (in Change mode).
    6. After completing the previous steps, the Password Registration Portal will load. IE displays a credential prompt before the page appears, but we believe this can be fixed by adding the Password Registration Portal web server name to the Local Intranet zone in the IE Security settings.  We were able to login to the Registration website using a test account that is configured correctly in the FIM Portal: (1) Member of “Password Reset Users Set”, (2) has the required attributes (AccountName, Domain, ObjectSID).  We were able to provide answers to the default questions and complete the registration.
    7. Next we tried using the Password Reset Portal.  The page loaded without any issues, and we proceeded through each step: entering the username, answering the questions, entering a new password.  After clicking Next, we receive the following error:  “An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)”.
    8. Found this article: http:/social.technet.microsoft.com/Forums/en-US/e9e850fc-7c84-4e60-94a3-e20c80e5116b/fim-2010-r2-password-reset-portal-error-3001?forum=ilm2 Based on this information, we looked at how the other FIM service accounts were setup in the FIM Service.  We have two other service accounts: One is the service account for the FIM Service MA, the other is used for running PowerShell scripts.  Both of these service accounts were within scope of the AD management agent at some point in the past.  Thus they were projected into the MV and subsequently provisioned into the FIM Service.  At a later point, connector filters were created in the FIM Service MA for both accounts, and the AD accounts were taken out of the scope of FIM.  So now, these accounts only exist in FIM as filtered disconnectors in the FIM Service connector space.  To get the new Password Reset and Registration Portal service account setup the same way, we moved the account into an OU that was within scope of FIM.  We ran an import on the AD MA to project this account into the MV, and provision it to the FIM Service.  Then we disconnected the FIM Service object from the MV and moved the service account in AD back out of scope.  This resulted in the FIM Service object becoming a normal disconnector.  Then we added a connector filter to the FIM Service MA for the account, which caused it to become a filtered disconnector. Despite these measures, we still received the error message above.
    9. Side note: After making changes to anything involving the FIM Service or IIS, we restarted the FIM Service as well as running “IISRESET” to ensure the changes took effect.  If the change was on the server hosting the Password Reset and Registration portals, we ran IISRESET only (there is no separate FIM service on that server).  If changes were made that affected the FIM Synchronization Service, then we restarted that service as well.
    10. We have not yet setup the Password Reset and Registration Portals to use SSL.  At first inspection it appeared that we would not be able to use the same port number (443) for both the Registration and Reset portals.  This is because the Site Bindings dialog in IIS Manager does not allow you to specify a host header name if the binding type is https (the field becomes disabled).  We found the following information that seems to provide a workaround for this using the “appcmd.exe” tool: http:/social.technet.microsoft.com/Forums/en-US/80ed7ec4-dd50-4d55-907b-246a646c74ed/change-password-reset-and-password-registration-portal?forum=ilm2  However, we were not certain if this was the correct procedure.
    11. In the configuration for the AD management agent, on the “Configure Extensions” page under “Password management”, the “Settings” button has an option labeled “Require secure connection for password synchronization operations”. Researching this option revealed that the option will only work if the MA is configured to use either SSL or LDAP signing (on the “Configure Directory Partitions” page under Domain controller connection settings, Options).  We have the option “Sign and Encrypt LDAP Traffic” enabled, so we believe it is okay to leave the “Require secure connection” option selected as well.  Regardless, we tried disabling this option and testing the portal, but it did not appear to have any effect.
    12. We tried enabling Windows Authentication in IIS as indicated here:  http:/josetheadmin.blogspot.com/2013/12/fim-2010-r2-sspr-cannot-access-password.html However, this did not appear to have any effect either way.
    13. We tried enabling the “Use preferred domain controllers” option in the Active Directory MA configuration and entering only one domain controller, the PDC, in the list of preferred DCs, as indicated here: http:/social.technet.microsoft.com/Forums/en-US/1be8a720-cbaf-4d14-84ef-50cf8c694a3e/fim-2010-r2-sspr-policy-enforcement-prevents-all-passwords?forum=ilm2  However this also had no noticeable effect.

    In summary, here are the issues to be addressed (in no particular order):
    1. Fixing the error message that appears upon submitting a password reset request (after completing the security questions).
    2. How to configure Windows Firewall.  At present, it is disabled on both servers by policy.
    3. Configuring the portals to use SSL.  We’re not certain if both portals (Registration and Reset) can be configured to use the same port (443) or if different ports are required.
    4. Suppressing the credential prompt that comes up before the Password Registration portal loads (if implemeting SSL does not resolve this, then the proposed solution is to add site to Local Intranet zone).
    5. Proper configuration of Authentication Gates.  We have attempted to follow the guidelines detailed here (http:/technet.microsoft.com/en-us/library/jj134288(v=ws.10).aspx#gate_order) but it does not seem to be working as anticipated.
    6. Opening up Internet access for the Password Reset portal.

    We would appreciate any help you can provide in completing this effort.

    Thursday, June 5, 2014 7:33 PM