I work in a university environment and I'm working on getting FIM 2010 R2 SSPR set up to allow students and employees to register for and reset their own passwords, replacing an existing 10+ year old system.  I've more or less identified how to pre-register accounts with PowerShell using the same data we currently use for first-time use of accounts.  Currently, first time users are asked for ID # (which they are provided ahead of time), last 4 digits of SSN and date of birth.  My challenge is that I'd like subsequent password resets to use a different set of questions (or at least potentially questions from a larger set than we pre-populated answers for).  Does anybody have thoughts on how this might be accomplished?  I'm open to reasonably secure alternative suggestions as well.

You essentially need two sets of Q&A workflows, MPRs, etc. I'd set a flag at the end of the AuthN workflow with the bootstrap questions that drops them in to a set with normal Q&A questions.

Sorry for the delayed response.  Setting the flag seems reasonable enough (Function Evaluator activity?) ... but I'm not seeing any way to trigger the password reset registration other than asking the account holder to visit the password registration site at the completion of resetting their password.  Is that my only option?  My *ideal* workflow would be as follows ...

for new accounts:

answer default QA challenges -> set new QA challenges -> set password -> done

for existing accounts needing new password:

answer QA gates -> optionally set new QA challenges -> set password -> done

I could see maybe directing people to the registration site from the beginning, but I don't know if there's any way to use existing QA gates to authenticate people for that site?

-Robert

A custom web application wrapping the password reset (WMI) and registration (PoSh / NET) modules would be one way to achieve this.  

I can't think of any way to use the standard SSPR flows to validate one set of Q&As, collect answers for a second set of questions, store those in the FIM Service, then allow a password reset, while flagging the user for access to only the second set of SSPR workflow objects at some point--it's a pretty big divergence.