Forcing Users to Register for FIM Self Service Password Reset – SSPR

You have implemented FIM Self Service Password Reset (SSPR) to reduce the number of calls to your Help Desk. After a few months the Help Desk is reporting that users are still calling to have their passwords reset. You pull a report and find that a significant number of users have not registered for SSPR. In this blog post we will detail an option that forces users to register for SSPR thereby increasing your return on investment (ROI) for its implementation.

Out of the box, FIM doesn’t have the ability to force users to register for SSPR. Instead, a user is presented with a pop-up Internet Explorer window at logon that prompts the user to register. If the user closes the IE window, it will pop-up again at the next logon. While the nagging approach will work for some users, many will simply close the IE browser window each time it comes up and never register. This leads to undesirable registration numbers. So, what to do? Three things:

online generic-cialis click here sildenafil adverse reactions prix boite cialis 20mg en pharmacie click enter site consulting case study with solution essay about drave car or using public transportation https://ssmf.sewanee.edu/experience/research-on-workplace-bullying/250/ https://mjr.jour.umt.edu/admission/pananaliksik-tungkol-sa-pagiging-late-ng-mga-estudyante/1/ gre essay argument gcse bitesize english language paper 1 epic movie cialis grant writing classes online essay on picnic moon http://partnerwith.ben.edu/blog/should-i-take-cialis-before-sex/11/ viagra can't ejaculate go to site go to site cialis formatos how to enhance effects of cialis does prednisone cause laryngitis follow site how many viagra per week https://riversideortho.com/cialis-for-bph-and-ed/ reading math paper help happiness essay writing sildenafil dapoxetine india brands accutane lawsuit canada 2011 here best film school essays FIRST – Your organization likely has some sort of Computer Acceptable Use Policy that specifies the Do’s and Dont’s of computer use. This should be updated to specify the requirement to register for SSPR in a certain amount of time. For this scenario we’ll say 30 days. In addition, it should be specified that if the user has not registered for SSPR within the 30 day period, they will be prevented from logging onto the network.

SECOND – Communicate this policy change to all users with information about how to register for SSPR.

THIRD – Configure FIM to support the new policy. FIM will be configured so that it will disable an account in AD after thirty days. It will also be configured so that the Help Desk will be able to re-enable the account for an additional 3 days allowing the user to logon to the network and register for SSPR.

Let’s look at how we would go about implementing this forcing function mechanism in FIM. It will require a number of sets, MPRs, custom attributes, workflows, an update to the AD outbound synchronization rule, and RCDC edits. The workflows require that you have installed the MIM Workflow Activity Library (WAL) which facilitates building complex workflows in the Microsoft Identity Manager (MIM) 2016 and Forefront Identity Manager (FIM) 2010 R2 solution. For more information about the MIM WAL to include project source code, releases and documentation, and discussion forums visit http://microsoft.github.io/MIMWAL/.

So, let’s begin!

1. Create the “SSPR Grace Period Expiration Time” Attribute and Binding

We need to be able to establish a date/time for which a user must register for SSPR and therefore will establish an attribute and binding as follows:

Display Name: SSPR Grace Period Expiration Time
System Name: SSPRGracePeriodExpirationTime
Data Type: Datetime
Description: The date when the SSPR Grace Period has expired.
Multivalued: False
Binding: User

2. Create the “SSPR Grace Period Expired” Attribute and Binding

We need the ability to denote when a user has not registered for SSPR in the required time period and therefore will establish an attribute and binding as follows:

Display Name: SSPR Grace Period Expired
System Name: SSPRGracePeriodExpired
Data Type: Boolean
Description: Indicates that the Grace Period Expiration Time has been reached.
Multivalued: False
Binding: User

3. Update “Administration: Administrators can read and update Users” MPR

We must provide FIM Administrators with the ability to make changes to the two values of the new attributes. To do so, we update the “Target Resources” tab of the “Administration: Administrators can read and update Users” MPR to include the newly created attributes; “SSPR Grace Period Expired” and “SSPR Grace Period Expiration Time”. If you want your Help Desk to be able to edit these values, you will need to update the appropriate MPR defined for Help Desk personnel.

4. Update “Administrator Filter Permissions”

We need to be able to filter on the new attributes which allows us to create sets based on criteria that includes these attributes. Therefore, we must update the “Administrator Filter Permission” Filter Permission by adding “SSPR Grace Period Expired” and “SSPR Grace Period Expiration Time” to “Allowed Attributes” on the “Permitted Filter Attributes” tab.

5. Create “_Standard Users” Set

SSPR usually is only used for standard user accounts and not used for service accounts, shared mailbox accounts, or administrator accounts. To ensure that policy only applies to these standard accounts, you need a Set in FIM:

Display Name: _Standard Users
Criteria-based Members: Use some criteria that defines standard users in your organization as you do not want SSPR to apply to things like service accounts.
Description: Standard user accounts

6. Create “_SSPR Not Enrolled” Set

We need to be able to distinguish standard users who have not enrolled in SSPR with this set:

Display Name: _SSPR Not Enrolled
Description: All Standard Users not enrolled in SSPR
Criteria-based Members: A User that matches all of the following conditions:

  1. The “AuthN Workflow Registered” attribute does not contain “Password Reset AuthNWorkflow”
  2. Resource ID is in “_Standard Users” set

7. Create “_SSPR Grace Period Expired Users” Set

We need to be able to distinguish standard users who have not registered for SSPR in the allowable time period with this set:

Display Name: _SSPR Grace Period Expired Users
Description: Users have not registered for SSPR in the allowed time period.
Criteria-based Members: A User that matches all of the following conditions:

  1. “SSPR Grace Period Expiration Time” prior to <today>
  2. Resource ID in “_Standard Users”
  3. Resource ID in “Users Not Enrolled in SSPR”

8. Create “_SSPR Grace Period Expired Box Checked” Set

We need to distinguish users who’s account has the “SSPR Grace Period Expired” attribute checked with this set:

Display Name: _SSPR Grace Period Expired Box Checked
Description: The “SSPR Grace Period Expired” box on the user account is checked.
Criteria-based Members: A User account where the “SSPR Grace Period Expired” is true

9. Create “_SSPR Grace Period Expired Box Unchecked” Set

We need to distinguish users who’s account does not have the “SSPR Grace Period Expired” attribute checked with this set:

Display Name: SSPR Grace Period Expired Box Unchecked
Description: The “SSPR Grace Period Expired” box on the user account is not checked.
Criteria-based Members: A User account where the “SSPR Grace Period Expired” is not true

 10. Create “_SSPR Grace Period Expired” Workflow

We need a workflow that will set the “SSPR Grace Period Expired” attribute of the user account to “True” allowing us to expire the account in Active Directory:

Workflow Name: _SSPR Grace Period Expired
Description: Sets the “SSPR Grace Period Expired” attribute of the user account to “True”.
Workflow Type: Action
Run On Policy Update: False
Activity: Configure the Update Resources (requires the MIMWAL) workflow activity as in screenshot below:

SSPR Forcing Function Screenshot: Workflow Activity Updates SSPRGracePeriodExpired Attribute to True
Workflow Activity Updates SSPRGracePeriodExpired Attribute to True

11. Create “_SSPR Grace Period Add 30 Days” Workflow

We need a workflow that will add thirty days from <todays date> to the “SSPR Grace Period Expiration Time” attribute establishing our initial registration deadline for new users:

Workflow Name: _SSPR Grace Period Add 30 Days
Description: Adds thirty days from <todays date> to the “SSPR Grace Period Expiration Time” attribute.
Workflow Type: Action
Run On Policy Update: False
Activity: Configure the Update Resources (requires the MIMWAL) workflow activity as in screenshot below:

SSPR Forcing Function Screenshot: Add 30 Days WF
Workflow Activity Adds 30 Days to SSPRGracePeriodExpirationTime Attribute

12. Create “_SSPR Grace Period Add 3 Days” Workflow

We need a workflow that will add three days from <todays date> to the “SSPR Grace Period Expiration Time” attribute allowing someone from the HelpDesk to extend the registration deadline. In addition, the workflow will immediately unlock the user’s account in AD so that they do not have to wait for the next sync cycle to run.

Workflow Name: _SSPR Grace Period Add 3 Days
Description: Adds three days from <todays date> to the “SSPR Grace Period Expiration Time” attribute and unlocks the account in AD.
Workflow Type: Action
Run On Policy Update: False
Activity 1: Configure the Update Resources (requires the MIMWAL) workflow activity as in screenshot below:

SSPR Forcing Function Screenshot: Workflow Activity Adds 3 Days to SSPRGracePeriodExpirationTime Attribute
Workflow Activity Adds 3 Days to SSPRGracePeriodExpirationTime Attribute

Activity 2: Configure the Run PowerShell Script workflow activity as in screenshot below:

SSPR Forcing Function Screenshot: Workflow Activity Enables account in AD
Workflow Activity Enables account in AD

Here is the complete code from the PS script:

Param($AN)
 $root = [ADSI]''
 $searcher = New-Object System.DirectoryServices.DirectorySearcher($root)
 $searcher.Filter = "(&(objectClass=user)(sAMAccountName=$AN))"
 $user = $searcher.FindOne()
 $userPath = $user.Path
 $accountToEnable = [ADSI]$userPath
 $accountToEnable.psbase.invokeset("AccountDisabled", "False")
 $accountToEnable.setinfo()

Important Note: You will need to delegate the FIM Service Account with the rights to enable the user accounts in AD. The specific permission required is Read and Write on the userAccountControl” attribute of User objects.

13. Create “_SSPR Grace Period: Initialize Expiration Time” MPR

This MPR kicks of the workflow that sets the expiration time on the “SSPR Grace Period Expiration Time” attribute:

MPR Name: _SSPR Grace Period: Initialize Expiration Time
Description:  Fires the “_SSPR Grace Period Add 30 Days” workflow on transition into the “_SSPR Not Enrolled” set.
Type: Set Transition
Transition Set: _SSPR Not Enrolled
Transition Type: Transition In
Policy Workflows: _SSPR Grace Period Add 30 Days

14. Create “_SSPR Grace Period: Process Newly Expired Users” MPR

This MPR kicks off the workflow that sets the “SSPR Grace Period Expired” attribute of the user account to “True”.

MPR Name: _SSPR Grace Period: Process Newly Expired Users
Description: Fires the “SSPR Grace Period Expired” workflow on transition into the “_SSPR Grace Period Expired Users” set.
Type: Set Transition
Transition Set: _SSPR Grace Period Expired Users
Transition Type: Transition In
Policy Workflows: _SSPR Grace Period Expired

15. Create “_SSPR Grace Period: Extend Expiration Time” MPR

This Request MPR kicks off the workflow that extends the “SSPR Grace Period Expiration Time” by three days when someone unchecks the “_SSPR Grace Period Expired” box on the user account:

MPR Name: _SSPR Grace Period Add 3 Days
Description: Fires the “_SSPR Grace Period Add 3 Days” Action Workflow when the Target’s set membership changes from “_SSPR Grace Period Box Checked” to “_SSPR Grace Period Expired Unchecked”.
Type: Request
Requesters: Specify a set that includes people that will have permissions to perform the action.
Operation: Modify a single-valued attribute
Permissions: Checked
Target Resource Definition Before Request: _SSPR Grace Period Expired Box Unchecked
Target Resource Definition After Request: _SSPR Grace Period Expired Box Unchecked
Resource Attributes: SSPR Grace Period Expired
Policy Workflows: _SSPR Grace Add 3 Days

16. Add New “SSPR Grace Period Expired” Attribute to Metaverse

Portal Synchronization rules are evaluated in the Metaverse. Therefore, it is necessary to add the SSPRGracePeriodExpired attribute with the following steps:

  1. Open Sync Manager and select Metaverse Designer tab
  2. Highlight Person Object Type
  3. From bottom right Actions menu, select Add Attribute
  4. From Add Attribute to Object Type window, select New Attribute button
  5. In the New Attribute window, enter “SSPRGracePeriodExpired” for the Attribute name, change Attribute type to Boolean, and leave defaults for the other options and select OK
  6. Select the Management Agents tab
  7. Select the MA for the MIM Service and click Refresh Schema from the Actions menu
  8. Enter the service account password, click OK and you should receive a message “The new schema has been committed to the server”

17. Configure Attribute Flow on FIM Service MA

Portal Synchronization rules are evaluated in the Metaverse. Therefore, it is necessary to flow the SSPRGracePeriodExpired attribute with the following steps:

  1. Open Sync Manager and open the Properties of the FIM Service MA
  2. Click on Select Attributes from the left window pane
  3. Select the Show All check box
  4. Find and check the SSPRGracePeriodExpired attribute and select OK
  5. Re-open the Properties of the FIM Service MA
  6. Select the Configure Attribute Flow from the left window pane
  7. Add a new import flow for Object Type Person: SSPRGracePeriodExpired (Data source)  –> SSPRGracePeriodExpired (Metaverse)

18. Update AD Outbound Portal Synchronization Rule

You will need to add two new Portal Synchronization Flows in your AD outbound Synchronization Rule.

This flow (below) will write to the description attribute in AD. If the SSPRGracePeriodExpired attribute is changed to “True”, AD administrators will know why the account was disabled in AD as the description on the user account in AD will state it was disabled by FIM for not registering for SSPR. If the SSPRGracePeriodExpired attribute is changed from “True” to “False”, it will write the last name , first name of the user in the description field.

Source: “IIF(SSPRGracePeriodExpired,”FIM Disabled – User not registered for SSPR”,lastName+”, “+firstName)”
Destination: Description

This flow (below) will disable the account in AD if the the SSPRGracePeriodExpired attribute is “True” and enable the account if it is “False”

Source: “IIF(SSPRGracePeriodExpired,514,512)”
Destination: userAccountControl

19. Synchronize

The following FIM Sync MA runs will complete the configuration:

  1. Export on FIM Service MA
  2. Full Import on FIM Service MA
  3. Full Sync on FIM Service MA

20. Update User Edit RCDC

You will want to update the Edit User RCDC exposing the “SSPR Grace Period Expired” and “SSPR Grace Period Expiration Time”. This is a very good article which describes the process for editing RCDCs: https://blogs.msdn.microsoft.com/connector_space/2014/12/01/rcdc-session-2-adding-a-new-attribute-to-an-existing-tab/

Here is a screenshot of the User Edit RCDC. The code highlighted in the first box is for the SSPRGracePeriodExpired attribute and the second box is for the SSPRGracePeriodExpirationTime attribute. So that you do not have to try and recreate the XML, you may download the UserEdit RCDC xml file (saved as .txt) here.

SSPR Forcing Function Screenshot: RCDC User Edit XML Code
RCDC User Edit XML Code

And this is how the User Edit form looks after making the changes to the RCDC:

SSPR Forcing Function Screenshot: New User Edit Form
New User Edit Form

That concludes this blog posting. I hope that you find it useful and please let us know if you have any questions or just post a comment. Thanks!

About Matthew Brooks

Over 15 years experience in the IdAM field.

2 Replies to “Forcing Users to Register for FIM Self Service Password Reset – SSPR”

  1. Enjoy reading your blog. Wish TechNet articles were as easy to read/follow.

    I’ve been looking for information on adding custom authorization gates to MIM’s SSPR and I haven’t yet to find anything. Do you know if this is possible to do and whether or not it’s a supported scenario in MIM?

    I can email you the details of what we are trying to do if you need more information.

    Thank you in Advance!

    • Hi Paul,

      I’ll send you an email requesting the details. We may be able to help. I really appreciate the compliment!

      Matt