Sdílet prostřednictvím


Multiple Password Reset Workflows

Have you ever needed to have multi-path workflows for SSPR when using FIM? If you have, you'll know that this can be a bit of a pain to configure. Especially if you are not familiar with the inner workings of password reset. I ran across such an issue today and wanted to share the situation and the resolution.

The challenge in my case was allowing users which are required to login using SmartCards to register for SSPR. The benefit of SSPR in this case is not really the ability to reset a password, but the ability to unlock an account that has been locked out. In addition, I also had to allow users which did not require SmartCards to register and use SSPR to reset their forgotten password.

At a quick glance you wouldn't really think of this as a problem but it is. This is because of the way that AD handles setting the Smart card is required for interactive logon flag. When the flag is set, a random password is generated (that the user doesn't know) and the password is flagged to never expire. This prevents a user who must use a smart card for interactive logon from completing the first password challenge gate during registration. While the challenge gate can be removed, it's there for a reason and that's security. As an example an end user walks away from his or her desk and leaves their computer unlocked. Without a password gate, a malicious user could easily register new challenge/answers then reset the password somewhere else. At this point they could have access to a whole trove of information they should not.

As you can see, it's a catch either way that requires a bit of customization to make both scenarios work.

So the first part of this dilemma is being able to identify the users in FIM via a set. Declarative sync rules really make this a very simple task since it can be done with a custom expression on the inbound flow from userAccountControl.

To start with, a few custom attributes and bindings are required. First create a new attribute in FIMService (SmartCardRequired) and bind it to the person object. Second a new metaverse attribute will be required to move the data from AD into fim (smartCardRequired).

Once the attributes have been created; the custom expression below will give a Boolean value that can be used for the sets. Keep in mind this also must be exported back to the FIMMA to make it available to the FIMService.

CustomExpression(IIF(Eq(BitAnd(262144,userAccountControl),262144),"true","false")) --> smartCardRequired (MV attribute).

Now that the attributes are available the next step is to build the appropriate sets. In this step we are essentially replacing the built-in "password reset users set" with our two custom sets.  The first set will define users that require SmartCards for interactive logon, and the second set will define standard users authenticating with a username and password.

As the next step I chose to define two new custom Password Reset AuthN workflows.  One that included the challenge for password gate (regular users) and another that did not include the password challenge (smart card users). However, both workflows included the same Q/A gates to provide some standardization between the two.

Since sets and workflows have now been defined the new MPR's can be created. These can be mirrored after the existing policy "anonymous users can reset passwords". The difference here is that each policy will need to have the appropriate AuthN workflow assigned (with or without password gate) and the target set must specify the appropriate set (smartcard required or not). Finally, the Password Reset Action workflow should also be attached to both policies.

The last piece that needs to happen to tie everything together is to have all of the items that were created added to the Password Reset Objects Set. This includes both new sets, both new workflows, and both new policies. After this is done, I am ready for multi-path SSPR! As a final clean up action, if the existing policy "anonymous users can reset their password" is enabled it must be disabled so FIM will know which workflow to call.

I hope this rather lengthy post might be of help to someone else out there. 

Happy FIM'ing!