none
SSPR Client with multiple workflows RRS feed

  • Question

  • Hello,

    I have a requirement to have two separate authentication workflows for SSPR. One set of users are required to use the SMS authentication and the other set are not.

    I have created the second workflow, MPR etc and it all works perfectly when accessed through the browser.

    However, users who are in the new custom set for SSPR are not being prompted to register using the SSPR client.

    Is it possible to use the client with a custom authentication workflow?

    Wednesday, January 6, 2016 5:22 PM

Answers

  • Hi Varun,

    I have this working correctly now.

    The issue was that I had not added the user to the required sets.

    I needed to have a set for each workflow as well as the default password reset users set. Then the user needs to be in the default set as well as the relevant workflow set.

    Thanks for all the help in pointing me in the right direction here.

    Richie

    • Marked as answer by Richard Eyres Wednesday, January 20, 2016 4:40 PM
    Wednesday, January 20, 2016 4:39 PM

All replies

  • Richard-

    It's definitely possible to do this. I am guessing that somewhere along the way either an MPR or a Set got misconfigured (or missed all together).


    Thanks,
    Brian

    Consulting | Blog | AD Book

    Thursday, January 7, 2016 12:45 AM
    Moderator
  • Richard this is definitely possible. The best way is to use the OOB setup and then duplicate the configuration , and then scope the Sets used based on what users you want with OTP or not , I can give more details if needed
    Sunday, January 10, 2016 10:37 PM
    Moderator
  • Hi David and Brian, 

    Thanks for the responses, knowing that I'm not chasing my tail on this is a help in itself.

    I think what I did wrong was that I was still using the OOB "Password Reset Users" Set for one of the workflows.

    Am I right in saying that this is the set which the client uses to check for users who need to register?

    Monday, January 11, 2016 10:05 AM
  • Am I right in saying that this is the set which the client uses to check for users who need to register?

    Partly related. The process is quite complicated. 

    The query used is

    /MPR[Disabled=false && (PrincipalSet=Anonymous && ResourceCurrentSet=/Set[ComputedMember='user guid']) && ActionType='Modify' && ActionParameter='ResetPassword']/AuthenticationWorkflowDefinition

    See http://blogs.technet.com/b/aho/archive/2009/11/09/forefront-identity-manager-credential-management-part-4.aspx

    P.S. if you are deploying SSPR, my other blog entries might be useful to you as well

    Wednesday, January 13, 2016 11:18 AM
  • Are the users in the 2nd set for which SSPR client is not prompting are able to register for SSPR using browser? If not then try this, there is one manual set 'Password Reset Object Set' where your 2nd SSPR gate Set, MPR and Workflow needs to be added in order to allow users in the custom set to be able to register for password reset.

    Regards,
    Varun

    Wednesday, January 13, 2016 7:23 PM
  • Hi Varun,

    It all works perfectly in the browser.

    When I add the test user to the Password Reset Users set they are prompted to register by the client but are asked to register for both of the workflows, both the 3 questions and a mobile number (workflow 1) and 6 questions but no mobile phone (workflow 2). 

    Regards,

    Richard

    Thursday, January 14, 2016 12:44 PM
  • Strange. Verify the user you added is not falling under both the SSPR sets. Ideally the user must be part of one of your SSPR sets.

    Regards,
    Varun

    Thursday, January 14, 2016 5:15 PM
  • Hi Varun,

    I have this working correctly now.

    The issue was that I had not added the user to the required sets.

    I needed to have a set for each workflow as well as the default password reset users set. Then the user needs to be in the default set as well as the relevant workflow set.

    Thanks for all the help in pointing me in the right direction here.

    Richie

    • Marked as answer by Richard Eyres Wednesday, January 20, 2016 4:40 PM
    Wednesday, January 20, 2016 4:39 PM