none
Password Reset Client - Calling Web Service behind NLB RRS feed

  • Question

  • I have a strange issue where the password reset client is not working when called by the network load balance address.

    I have the web service address defined as "http://fimservice:5725". Where "fimservice" is 2 different servers hosting the web services. These web services seem to work just fine when called by other clients (portal, powershell, etc..) under the NLB.

    When I attempt to register I can get as far as submitting my questions then getting this error on submit:

    mscorlib: System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: An error occurred when processing the security tokens in the message.
       --- End of inner exception stack trace ---

    If I go into my "hosts" file and manually define that address to a direct IP (outside the NLB), then registering my questions work.

    I've tested each web service by hitting it directly and I can register my questions, but as soon as I use the NLB it breaks. Why is that? What is the NLB doing that breaks this communication [NLB should be sticky connection]?

    Friday, August 31, 2012 8:38 PM

Answers

  • Hello,

    The FIM Service on Server2 would not know session details of Server1 therefore  use "sticky" configuration in NLB.

    Best,

    Jeff Ingalls

    • Proposed as answer by nTony Ho Monday, September 3, 2012 12:53 AM
    • Marked as answer by The Unique Paul Smith Wednesday, September 5, 2012 10:38 PM
    Saturday, September 1, 2012 7:07 AM
  • The way this flows is..

      • If the user successfully confirms his or her identity by responding to all of the STS's challenges, then the STS will yield a response to a request for a security token that incorporates a security token.
      • The client can now attach the security token it obtained from the STS to a (new) request to the Password Reset endpoint to reset the user's password..
      • If the request is found to be in order, then the service will try to update the user's password in Microsoft Active Directory by way of the FIM Password Change Notification Service.

    If you obtain a token from the STS on one service endpoint and try to provide it to another service's password reset endpoint, it will likely reject that token (my best guess of course) That would seem to match with the general theme of the error you're reporting, so I'm going to propose that your load balancer may need to recognize that both requests need to land on the same server.

    Error-wise, i would assume that the server receiving the unknown token will throw some exception indicating that case.

    Not having actually seen this - it's pretty much a best guess.. but makes sense


    Frank C. Drewes III - Architect - Oxford Computer Group

    Tuesday, September 4, 2012 9:36 PM

All replies

  • Hello,

    The FIM Service on Server2 would not know session details of Server1 therefore  use "sticky" configuration in NLB.

    Best,

    Jeff Ingalls

    • Proposed as answer by nTony Ho Monday, September 3, 2012 12:53 AM
    • Marked as answer by The Unique Paul Smith Wednesday, September 5, 2012 10:38 PM
    Saturday, September 1, 2012 7:07 AM
  • I checked the load-balancer configuration and we do have a sticky bit set for specific period of time. Seems to only occur on committing the password registration / reset and not when going through the gate. All other types of queries work just fine when communicating to the load balancer (get/update/delete) requests. Issue seems to be just the Password Client during the final register/reset.

    Tuesday, September 4, 2012 3:59 PM
  • Just a thought - a lot of the initial desktop traffic during reset goes to :5726, with just the reset request going to :5725.  Would the change in port be enough to throw off stickyness?
    Tuesday, September 4, 2012 4:26 PM
  • That would make sense. I'll check to see how the NLB is configured regarding stickyness on different ports.

    Another question I had is what type of verbose logging error would you think we would recieve on the client (or server) if all of the sudden the secondary server starting recieving session data from the initial server. Would it be similar to the above post "An unsecured or incorrectly secured fault was received from the other party"?

    Tuesday, September 4, 2012 4:44 PM
  • The way this flows is..

      • If the user successfully confirms his or her identity by responding to all of the STS's challenges, then the STS will yield a response to a request for a security token that incorporates a security token.
      • The client can now attach the security token it obtained from the STS to a (new) request to the Password Reset endpoint to reset the user's password..
      • If the request is found to be in order, then the service will try to update the user's password in Microsoft Active Directory by way of the FIM Password Change Notification Service.

    If you obtain a token from the STS on one service endpoint and try to provide it to another service's password reset endpoint, it will likely reject that token (my best guess of course) That would seem to match with the general theme of the error you're reporting, so I'm going to propose that your load balancer may need to recognize that both requests need to land on the same server.

    Error-wise, i would assume that the server receiving the unknown token will throw some exception indicating that case.

    Not having actually seen this - it's pretty much a best guess.. but makes sense


    Frank C. Drewes III - Architect - Oxford Computer Group

    Tuesday, September 4, 2012 9:36 PM
  • One minor clarification:  Portal-initiated password reset does not use the PCNS, but rather just the WMI methods exposed by the FIM Synchronization Service.  PCNS would come into play for capturing a password change happening normally on a DC and replaying it back into FIM for sync to other systems.

    Anyhow, a MessageSecurityException seems like the right thing to happen here, when submitting a token from Server A's STS to Server B's ResourceManagementService.

    Tuesday, September 4, 2012 9:41 PM
  • Question,

    Is the web-service session hosted from the service level, or database level? I am assuming service-level which is why the reset client isn't working. I know that the web-services use the same database. Can the web services be configured to be aware of each other and share session data from the database, or is it not designed like that?

    Monday, September 10, 2012 10:04 PM
  • this is 100% pure guess, but I wonder if it has to do with the FIM service using a self-signed cert.  If you had both service instances signing with the same cert, I wonder if it would work..

    I have seen some discussions on here about updates or hotfixes failing because of the non self-signed cert - so I probably wouldn't try it - but just thinking out loud.

    Steve, You're right about the error. I found that verbage in the "FIM Web Service developers guide".. I think they should have said "Via WMI to the AD MA and then (optionally) to other targets via PCNS."


    Frank C. Drewes III - Architect - Oxford Computer Group

    Monday, September 10, 2012 10:17 PM
  • I ended up doing some testing and wrote a small powershell script that listens on port 5725 and port 5726 and delivers the packet data  to 2 different web services (one for each port). Turns out the behavior is the same as the load balancer, it was configured so that both ports can be load balanced to different servers which is causing the problem. The solution is to have the NLB sticky to a server for both ports and not host the ports uniqely.

    I figured I would post my findings here for anyone that was interested.

    serverA (5725, 5726)

    serverB (5725, 5726)

    Scenario 1: Password Register Client pointing directly to serverA

    As expected the client works fine, can register/reset password & questions

    Scenario 2: Password Register Client pointing to powershell script (script relays 5725 to serverA and 5726 to serverB)

    1. Client is initialized on port 5725

    2. When clicking next on welcome screen talks to both port 5725 and 5726

    3. After entering user account password talks to port 5726

    4. After entering new password answers talks to port 5726 and then 5725 then errors out submitting the answers.

    Tuesday, September 11, 2012 10:01 PM
  • After running into the same issue - setting up stickiness across services on my F5 (to make sure the client hits the same server each time) did the trick for me.  Thanks!

    Matt

    Thursday, October 11, 2012 5:32 PM