Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2012-11-11) Finding All Users Within FIM That Have (Not) Registered For SSPR

Posted by Jorge on 2012-11-11


As you may know already, both FIM 2010 and FIM 2010 R2 have a feature called “Self-Service Password Reset” (SSPR). With that people that have registered for SSPR can reset their own password in AD by using the FIM SSPR portal. However, before being able to use SSPR you MUST have registered for it. Every user that is allowed to use it will be notified to register for SSPR every time they logon to a domain joined computer that also has the FIM Add-In Extensions installed locally. Unfortunately the user is not enforce to register as the user can click [Cancel] to not register. The only downside for the user is that he/she will be remembered to register for SSPR until he/she actually registers for SSPR.

So, as an IdM admin, how do YOU know which users have and have not registered for SSPR and of course how many? Within the FIM Portal this can be easily achieved through Search Scopes.

So, first things first….

By default FIM contains one authentication workflow that is used in SSPR. It is called “Password Reset AuthN Workflow”. Before using SSPR you must have configured the “Password Reset AuthN Workflow” or any other custom authentication workflow you want to use. An example can be found below of the configurations needed for FIM 2010 R2. For FIM 2010 not all configurations shown apply.

image

Figure 1a: Configuring The QA Gate Within The Password Reset AuthN Workflow

image

Figure 1b: Configuring The QA Gate Within The Password Reset AuthN Workflow

For questions to use within the QA gate have a look at the following blog post: (2010-09-24) Security Questions For The FIM QA Gate. Make sure the questions you use apply to your employees, their language of even culture.

After configuring the authentication workflow, you need to configure a SET that groups all Password Reset Authentication Workflows. Well, there is only one Password Reset Authentication Workflow, so  why is this needed? In a company that uses more than one Password Reset Authentication Workflow, it is recommended to group all of these through a SET. The reason for having more than one if you are a multinational, you most like will need to have a Password Reset Authentication Workflow for every language spoken within the company.

The grouping of multiple Password Reset Authentication Workflows can be achieved in multiple ways:

  1. Static membership by adding all specific Password Reset Authentication Workflows
  2. Criteria based membership by adding every specific resource ID of each Password Reset Authentication Workflow to the filter
  3. Criteria based membership by configuring the filter to be based on a specific part of the name

In this case I chose [3] as that gives me less management overhead. I only need to make that every Password Reset Authentication Workflow is named in a very specific way.

image

Figure 2: Creating A SET To Group All Password Reset AuthN Workflows

After creating the SET, make sure to copy the object ID of the SET somewhere as you will need it later on!

Now it is time to create the Search Scopes that will help determine the (number of) users who have or have not registered for SSPR

Let’s start with the Search Scope that will determine the users that have registered for SSPR.

image

Figure 3a: Create A Search Scope That Will Determine The Users Who Have Registered For SSPR

The objectGUID you see below is the objectID of the SET you wrote down earlier/above.

image

Figure 3b: Create A Search Scope That Will Determine The Users Who Have Registered For SSPR

image

Figure 3c: Create A Search Scope That Will Determine The Users Who Have Registered For SSPR

image

Figure 3d: Create A Search Scope That Will Determine The Users Who Have Registered For SSPR

Let’s now continue with the Search Scope that will determine the users that have NOT registered for SSPR.

image

Figure 4a: Create A Search Scope That Will Determine The Users Who Have NOT Registered For SSPR

image

Figure 4b: Create A Search Scope That Will Determine The Users Who Have NOT registered For SSPR

image

Figure 4c: Create A Search Scope That Will Determine The Users Who Have NOT Registered For SSPR

image

Figure 4d: Create A Search Scope That Will Determine The Users Who Have NOT Registered For SSPR

After having configured both Search Scopes, make sure to close Internet Explorer, or whatever other browser you are using and perform an IIS Reset through IISRESET commando.

Open up the FIM Portal again after the IIS Reset and click on the users navigation bar. Click on the “Search Within..” drop down list and select the Search Scope that returns all users that have registered for SSPR.

image

Figure 5: List Of Users That Have Registered For SSPR

SNAGHTMLc9d4ec2

Figure 6: List Of Users That Have NOT Registered For SSPR

Interestingly enough when you select the search scope it will not return al users right away. Instead you can see the number of users at the bottom of the Internet Explorer. If you want you can search for specific users or use a wildcard in the name.

Would it be possible to create a navigation bar link instead? YES, that is possible, but be aware of the following. The major downside of that is that it returns all the results immediately. That will impact performance negatively and more specifically when you have lots of users within the FIM Portal.

However, if you still want to go the navigation bar way make sure to read the following blog posts:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

10 Responses to “(2012-11-11) Finding All Users Within FIM That Have (Not) Registered For SSPR”

  1. Harold said

    Good info, but, the SSPR function in FIM is minimally useful. Users cannot register with a temp password or an expired password, and it is highly questionable for publishing externally (public) due to security concerns. Plus, the old-school “question / answer” approach is not effective and presents an attack vector. IMO, use FIM for its core features and choose a dedicated, secure enterprise class self service password reset solution such as “Password Reset PRO” from http://www.sysoptools.com. Something like this deploys nicely alongside FIM, is secure for extranet publishing, is very easy for admins to set up, and is actually much more effective at reducing help desk calls for resets or unlocks. Plus it already has reporting to show which users have not enrolled, is AD based (no SQL databases needed), works with mobile browsers, and it is possible to use logon scripting to enforce enrollments. Easy peasy = less work for admins and happier users. I love FIM but it should be used for it’s primary feature set and not for some of its peripheral functions, which are not well thought through. It’s all about using the right tool for the job.

    • Jorge said

      Hi,

      Thank you for your comment/feedback

      Registering for SSPR means that you will provide/register your answers to the presented questions during registration
      Performing self-service reset means that you will provide the sAMAccountName or the UPN so that FIM can identify the requestor performing SSPR and based on that you need to answer the questions correctly with the answers that you registered during registration. In addition, for additional security measures and only possible in FIM 2010 R2 you can have FIM send a one-time password to a already known e-mail address and/or mobile phone number. When all that has been done correctly you are allowed to provide a new password. The definition of “new password” can mean 2 different things in both FIM 2010 and FIM 2010 R2. The default behavior of FIM when using SSPR is to accept any password that fulfills the password policy, except for the password policy. Normally a password reset does not enforce password history, a password change does! The behavior of FIM can be changed to still enforce password history even when doing a reset. The fun part of this is that it is not the behavior of FIM that you are changing, but rather the behavior of AD.
      With FIM 2010 R2 you can differentiate between performing SSPR internally or from an extranet environment.
      If your account is LOCKED in AD, you can also unlock it yourself by just performing SSPR through FIM.

      To be honest I have not used any other tool for this than FIM, and until now it has worked for me nicely

      Regards,
      Jorge

  2. […] [A] Here you can specify your custom XPATH query (/Person, /Person[AccountName=’ADM.ROOT’]) (also have a look at this post and this post) […]

  3. jmanley501 said

    How do make this work for Non-Administrative users for example a helpdesk person who needs some but not all administrator rights in the FIM Portal

    • Jorge said

      you need to create the correct MPRs/SETs that give the requestors (in your case the non-admins) to view/see/query the required information

  4. Cathryn said

    can you then export the results?

  5. FIM_TLK said

    Good job Jorge. Couple of Add-ons to this.
    1/ BasicUI exposes it to everyone. Can restrict to a select few by creating your own Useage Keyword. See Carol’s http://www.wapshere.com/missmiis/search-scopes. I created a Useage Keyword and then created a set for Helpdesk and some Admins. Then created an MPR and gave that set read access to the Keyword.
    2/ Be careful with the attributes to search in the search scope, its case sensitve. i was seeing the scope in the drop down until I corrected that
    3/ If you want Helpdesk to also see it then A/Create a Helpdesk set B/ Create an MPR and give that set read access to the “Computed Member” attribute of target resource “All sets”.

  6. […] the blog post (2012-11-11) Finding All Users Within FIM That Have (Not) Registered For SSPR I demonstrate how to query the FIM service using the FIM Portal for users that have registered for […]

  7. […] https://jorgequestforknowledge.wordpress.com/2012/11/11/finding-all-users-within-fim-that-have-not-r… […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: