Forefront Identity Manager - Credential Management, Part 4

  • [アーティクル]

This post talks about how client interacts with the server during the course of Self-Service Password Reset Registration and Reset. Majority of the information can be found from either client-side or server-side log. The implementation is subjected to change. If you were to develop a custom SSPR client based on the information below, please make sure what you do is supported.

Deep Dive into Self-Service Password Reset

Components and terminologies:

  • Gate Framework (GF), client side unmanaged component. It handles the UI of varies gates and the password reset screen.
  • PasswordProxy (Proxy), aka FIMPasswordReset, client side managed component. It acts as a proxy between Gate Framework and FIM Service.
  • FIM Service
  • Secure Token Service (STS), a component of FIM Service that issues tokens

Communication channels used:

  • Between Gate Framework (GF) and PasswordProxy uses secured namepipe because GF is native and PasswordProxy is managed.
  • Between PasswordProxy and FIMService/STS uses WCF with message security.
  • Between FIMService and FIMSynchronizationService uses WMI.

Registration Sequence

  1. C:\Windows\System32\MsPwdRegistration.exe auto starts when user logon.
  2. It performs some housekeeping routines and call into GF to initiate the registration sequence.
  3. GF establishes a secured name pipe to Proxy.
  4. Proxy will then
    1. Lookup the user guid: /Person[Domain='...' and Account='...']
    2. Lookup all possible AuthN WFs that can be used by the user for SSPR
      /MPR[Disabled=false && (PrincipalSet=Anonymous && ResourceCurrentSet=/Set[ComputedMember='user guid']) && ActionType='Modify' && ActionParameter='ResetPassword']/AuthenticationWorkflowDefinition
    3. For each AuthN WF, determine if the user:
      1. Has registered or not (User.AuthNWFRegistered attribute).
      2. Is locked out or not (User.AuthNWFLockedout attribute).
    4. Return to GF with one of the value:
      1. Registration required, when one or more AuthN WFs is not registered.
      2. LockedOut, when user is locked out of one or more AuthN WFs.
      3. Registration Optional otherwise.
  5. If the return value is not Registration Optional, GF will display the Registration Welcome Screen.
  6. To register, Proxy sends a Put request to add the AuthN WF Guid to User.AuthNWFRegistered.
  7. This request will trigger the AuthN WF "System Workflow Required for Registration" caused by MPR "General workflow: Registration initiation for authentication activity" and Proxy will receive an AuthNRequiredFault.
  8. The AuthN fault contains the endpoint address of STS that the client needs to talk to to obtain a token.
  9. Proxy then relays message between GF and STS. STS will send a list of challenges (e.g. Q&A) and GF will display the questions and reply back with the answers that user inputs, etc etc.
  10. At the end of the challenge-response sequence with the STS, STS will issue a token indicating the User has passed the AuthN WF.
  11. Proxy then resumes the original request with the STS token.
  12. After that, the request goes through the normal AuthZ, Commit and Action phases.

Reset Sequence

  1. User clicks on the "Reset Password" link on the logon screen.
  2. Gina/Credential Provider calls into GF to initiate the reset sequence.
  3. GF establishes a secure channel with Proxy.
  4. Proxy sends a Put request which Modify User.ResetPassword attribute.
  5. This request will trigger the AuthN WF "Password Reset AuthN Workflow" caused by MPR "Anonymous users can reset their password" and Proxy will receive an AuthNRequiredFault.
  6. Proxy then obtains a STS token and resumes the request just like during registration.
  7. The request goes through the normal AuthZ, Commit and Action phases.
  8. During Action phase, it will kick off Action WF "Password Reset Action Workflow".
  9. This workflow will listen on an endpoint awaiting user to input their new password.
  10. Once the Password Reset Action Workflow receives the new password, it will, under the FIMService service account context, make a WMI call to the FIMSynchronizationService to perform a SetPassword.
  11. FIMSynchronizationService, under the AD MA account context, will talk to the primary domain controller (PDC) to reset the user password.

That's it. Feel free to leave me a message if you need clarification.

Comments

  • Anonymous
    January 01, 2003
    No, we intentionally did not implement this feature. Image a VP is preparing a demo/presentation for the next billion-dollar contract. Forcing him to register is a no-go. If you have business justification for that, feel free to communicate that with MS Product Support Service. We take feedback seriously :)

  • Anonymous
    January 01, 2003
    Your Blog is fantastic Anthony. Awesome to see some more detail of how everything works under the hood, sure it will help everyone sort out minor quirks.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    You can use Lockout Gate described in my Part 2 http://blogs.technet.com/aho/archive/2009/10/04/forefront-identity-manager-credential-management-part-2.aspx

  • Anonymous
    January 01, 2003
    Updated to the following (notice namepipe is secured and WCF usesmessage security) Communication channels used:    Between Gate Framework (GF) and PasswordProxy uses secured namepipe because GF is native and PasswordProxy is managed.    Between PasswordProxy and FIMService/STS uses WCF with message security.

  • Anonymous
    January 01, 2003
    Hi, the registration is triggered by MsPwdRegistration.exe. One way to achieve that is for you to:

  1. disable MsPwdRegistration.exe in startup
  2. in your web, check if the user is registered or not via webservice
  3. if not, prompt the user for registration via MsPwdRegistration.exe There are some work we are doing which I can't discuss. However, I would strongly encourage you to contact PSS and tell us your need and business justification for having a custom branding in the rich client. Having more feedback from customers allow us to prioritize our work according to customer needs.

  • Anonymous
    January 01, 2003
    the reset sequence will become Reset Sequence   1. User clicks on the "Reset Password" link on the password portal   2. The portal invoke an ActiveX which instantiates GF   3. GF establishes a secure channel with Proxy. Rest is the same

  • Anonymous
    January 01, 2003
    Technically speaking, it's hashed, not encrypted. And there is no way to just backup the answers because they are tied to the workflow and the user object

  • Anonymous
    January 01, 2003
    Hi Cameron, would you like to elaborate a bit on what you are trying to achieve. It's unclear to me what you meant by "a login script entry that disables if that user has registered". What's your ultimate goal?

  • Anonymous
    January 01, 2003
    That might work but It is not currently supported. Please contact Microsoft Product Support Service (PSS) with your scenarios and business justifications. We would love to hear from you.

  • Anonymous
    April 12, 2010
    What is the capability to configure the Password reset to resist BruteForce exploit? Can teh period between attempts be extended after a given number of attempts, or can the process be locked after a number of failures?

  • Anonymous
    March 25, 2011
    Anthony, if I use the PW Reset portal for resetting the PW, what does this add to the scenario you describe?

  • Anonymous
    April 07, 2011
    Anthony, Is there a way of forcing the registration of answers - ie making the registration screen un-cancellable?

  • Anonymous
    April 18, 2011
    Hi Anthony, Is there a supported way of 'injecting' answers in to the system based on user attributes (ie employee number) rather than having to ask the users to fill out answers? I found this - but this is a custom workflow etc blog.aesthetixsoftware.com/.../how-to-bulk-register-users-for-password-reset-in-fim and perhaps not supported by Microsoft?

  • Anonymous
    May 12, 2011
    The comment has been removed

  • Anonymous
    May 15, 2011
    Hi Anthony, The FIM client asks for your password etc, and is not branded as per our organisation. AFAIK - it can't be branded differently in this release. This has caused some within our org to raise concerns that some of our users might think it is spyware etc. As such, we are going to trigger a web page to run in the login script before the SSPR registration runs that will explain the process and show screenshots etc. This only needs to run up until the user has registered - hence the question about disabling that part running based around a registry key or a returned value.

  • Anonymous
    May 26, 2011
    Hi Anthony, Thanks a lot for all in info you provided. Could you please let me know, if there any way to customize the look and feel of the Registration and password Reset screens/dialogs in the FIM password reset client? Such as having the company logo or some sort of disclaimer/warning, etc. Thanks

  • Anonymous
    September 13, 2011
    Hi Anthony, I understand the answers themselves are encrypted so aren't human readable, but is there a way to backup (and restore) just the users answers - not just the entire database? We had a scenario where a policy update triggered flushing the registration of all those who had registered. Thanks

  • Anonymous
    December 07, 2011
    Hi Anthony, I am trying to configure SSPR in a forest with multiple domains. SSPR works 100% from domain where the portal is installed, but not from any other domain.  When a users is trying to register from a client in another domain, the registration process failes at the point when the authentication is done, just before the user had to provide his / her password to proceed with the registration. I could not find any information of how to configure this and is wondering if this is at all possible.  Would appreciate it if you can shed some light on this or point me in right direction. Thanks

  • Anonymous
    December 07, 2011
    Anthony, Thanks, I managed to sort it out myself. I enable logging on the client according to another post of yours and noticed that the client is trying to connect to the portal in another domain by using just the server name eventhough I have provided the full FQDN in the config file. (obviously it could not get to it with just that) I added a domain suffix on the client for the portal's domain and everything started to work registration as well as resetting the password of a user.  I assume in cases where SSPR must be deployed in multiple domains it would be best to use an alias for the portal which is available in all domains.  Will test that when rebuilding my test environment again. Thanks

  • Anonymous
    June 10, 2012
    Hi Anthony, Thanks a lot for your blog, it is really helpful ! I have just one question concerning channel used. During the communication between GF and FIMService/STS you said it uses WCF. Could you please be more specific ? Is this communication encrypted ? Are challenges and new password encrypted or ciphered ? Thanks again for your help.

  • Anonymous
    December 02, 2015
    Hi Nice blog Post.
    While we click Reset Password. It will by default show us to Enter Mobile number field.So No I want to give email field also along with that so user can enter his email and OTP will go to his email also.
    Please shed some light.

    Thanks in Advance

  • Anonymous
    December 02, 2015
    You can configure the Authentication Activity to use either SMS OTP or Email OTP gate, but not both