FIM 2010 R2 - PW Reset Client Service over Internet


  • What would be the reason for the PW Reset Client Service not working over internet? I know every doc says it's not intended to be used that way because it's not recommended to expose the FIM Service over internet ..... but what if you DO expose it?

    From what I tried, when attempting a PW reset from the login screen, the PW Reset Client Service was able to:

    1. connect to the FIM Service
    2. validate the user (Microsoft.IdentityManagement.PasswordReset.PasswordResetOperation.ValidateUser(ClientPipeContext& client))
    3. retrieve the QAGate, present the questions and submit the answers
    4. security token ("All the authentication gates were passed and a security token was issued") got issued
    5. I verified by looking at wireshark that the security token was retrieved (token is valid for 5 min, and time was in sync)
    6. after that, instead of seeing the screen to provide my new password, I saw an error code 997
    7. the Verbose logging on PW Reset Client Service showed "Resetting the password." followed by "The client connection was closed." a second after
    8. no other errors were displayed anywhere

    Is this the expected behavior? Looking at wireshark I didn't see any attempts to connect anywhere else (and I don't see any reason to either) ... so it seems like the PW Reset Client Service didn't like something about the security token ... or something else weird is going on.

    Any ideas?


    יום ראשון 17 יוני 2012 04:59


כל התגובות

  • if u want to dig down into the details, u need to enable tracing in the client to see what's going on.

    If you expose FIMService to the internet, how does the client get a kerb ticket and talk to FIMService?

    The FIM Password Reset Blog

    יום שני 18 יוני 2012 03:50
  • If you expose FIMService to the internet, how does the client get a kerb ticket and talk to FIMService?

    The FIM Password Reset Blog

    DirectAccess is one scenario that comes to mind.

    My Book - Active Directory, 4th Edition
    My Blog -

    יום שני 18 יוני 2012 06:13
    מנחה דיון
  • With DA, it will work...

    now the question is if i have forgotten the password, and stuck at the logon screen, you need to establish the DA connection before the FIM client can work

    The FIM Password Reset Blog

    יום שני 18 יוני 2012 06:27
  • Enabling tracing is the first thing I did, the above points are from the trace log.
    DA is one way to go, but what I don't understand is when and why is the kerb ticket required/used in a PW Reset scenario? The process has to be started as anonymous and it's up to FIM to verify the user ... and it looks like it's doing it just fine. It only fails to get to the last step of allowing me to provide the new password. I can't imagine what else would be required at that point?

    Edit: after rethinking it, is it maybe the local PW Reset Client Service that needs to get some kerb ticket to establish the pipe to the FIM Service ... Anyway, instead of us guessing, if you can, please tell us how exactly is it working during the PW Reset scenario through the PW Reset Client Service :)


    יום שני 18 יוני 2012 06:44
  • because all the FIMService's endpoints are secured using message security

    Send over the trace file to and i can take a look when i have a moment

    This is how it works:

    The FIM Password Reset Blog

    יום שני 18 יוני 2012 07:27
  • Piotr, 

    Look at enhancements for FIM Pwd Reset made in R2? Maybe it is a way to go for You. If You need to use password reset for Internet users working with current FIM implementation this can be done with custom application for password reset - application itself still required that machine will be domain joined.

    Ping me off-line if You need details on how password reset works for FIM from client level :)

    יום שני 18 יוני 2012 08:11
  • Tomek, yes, we're deploying R2's PW Reset Portal, so I know all about the enhancements.

    What I'm trying to clarify right now is what connectivity is a must to make the Reset work from the login screen. In the ideal world DA is working 100% of the time, and there are no firewalls anywhere... but as we all know that's never the case. I know Antony's blog by heart now, but I can't seem to identify the step where any of the client components (GF or Proxy) would talk to anything else than the FIM Service or STS (which is also a part of FIM Service) during a PW Reset scenario. To quote from the blog:

    "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."

    It seems like all the components are either local (GF/Proxy) or it's one of the FIM Service endpoints. So if FIM Service would be internet exposed, why wouldn't it work? I'm not that familiar with WCF and Message Security, so maybe I'm just missing something here.

    Edit: I just talked to Tomek over email, and he said that the PW Reset Client Service is written in a way that leverages the computer account context ... which would explain the need to have domain connectivity to make it all work.


    יום שני 18 יוני 2012 09:08
  • i have seen the rich client works over DA.

    Send me your log and i can take a look.

    The handshake has an implicit step that would go to the DC which i didn't call out explicitly

    The FIM Password Reset Blog

    יום שני 18 יוני 2012 09:12