Anthony Ho

FIM 2010 R2 - Web-Based Password Reset, Part 3

AnthonyHo — Tue, 06 Dec 2011 14:28:00 GMT

FIM lets users reset their passwords only after authenticating them against answers to commonly asked security questions that they registered with.

One major complaint about FIM 2010's QA Gate implementation is that it does not allow ITPro to specify some sort of validation or policies on the answers. It's possible that users might enter "abc" for all questions and some believe that is a security concern. (In fact, I used to use 1 for my answers during testing because the keyboard sequence "1<tab>1<tab>1<tab>" is the easiest on the keyboard.)

QA Gate Enhancement

We heard your feedback loud and clear. Thus we are making a few changes to FIM 2010 R2, namely:

Disallow duplicated answers
Apply a custom regular expression on the answers for validation for all answers per gate

Below is a screenshot of the QA Gate Configuration from the workflow designer (aka BPM Designer)

How Does It Work?

Some of you might ask, "Wait, isn't the answer hashed in the client? How is this possible?" First, Congratulations and well done on knowing password reset in depth. :)

To achieve this validation on the server side, now the answers are sent to the server in un-hashed over a WCF channel protected with message-level encryption (Nothing is changed in the channel itself. We are just changing the payload at the application layer)

Special Notes

This check is only enforced during registration phase and the answers are still stored hashed in the database.

To make sure the policies are enforced by default, registration from FIM 2010 clients are disallowed. There is an option at the bottom of the configuration to let you run FIM in hybrid mode during the transitional upgrade period. In that case, FIM 2010 clients will be able to register and bypass the policies, while registrations originating from FIM 2010 R2 clients will have the policies enforced.

FIM 2010 R2 - Web-Based Password Reset, Part 2

AnthonyHo — Tue, 29 Nov 2011 02:42:00 GMT

Web-Based Password Reset is not just about writing a web client in ASP.NET. I mentioned that a few times when talking to different people. Everyone can do that by writing their own WCF client. If reverse engineering the FIM WebService protocol is too hard, there is the open source client supported by the community. In fact, BlueVault has done exactly that. It definitely will not be too hard for us to do. However, when we think through the scenarios in depth, we realize most customers want web-based SSPR so that people not connected to the network can also reset their password. That implies exposing not only the portal, but also indirectly exposes FIMService to the extranet. This make us rethink our security model.

In this blog post and the coming few ones, I am going to talk about a few improvements related to the security aspect of web-based SSPR.

Scenario

In FIM 2010, password reset from the intranet would require user authenticates themselves using QA Gate. In R2, when ITPros exposes web-based SSPR to the extranet, they might want to have additional authentication for added security (e.g. RSA token) yet keeping intranet reset as easy as before.

What is Security Context?

We tackle this scenario by introduce something called security context which can be found in the extended attribute of the request.

namespace Microsoft.ResourceManagement.WebServices.WSResourceManagement
{
    public enum SecurityContext
    {
        Extranet,
        NoneSpecified
    }
}

A request tagged with Extranet means it comes from the SSPR portal that is serving requests coming from the extranet.

How does Security Context Work?

If you look at the new workflow designer UI, you will notice some of the gate-configuration pages have an extract section for SecurityContext. The description is self-explanatory. If set to Extranet, the activity/gate will only be run if the request comes from the extranet.

How do I Configure SecurityContext Tagged in Requests from SSPR Portals?

In setup, there is the option to specify that.

That translates to <add key="SecurityContextAssertion" value="[Extranet|NoneSpecified]" /> at "C:\Program Files\Microsoft Forefront Identity Manager\2010\Password [Registration|Reset] Portal\Web.config"

Office 365 Password Reset GA

AnthonyHo — Tue, 22 Nov 2011 01:27:00 GMT

Sooner or later, you may forget the password that you need to sign in to your account. It happens to just about everyone. If you forget your Office 365 password, and you’re not an Office 365 administrator, confess your predicament to an administrator in your organization, and the kind administrator resets your password.

If you’re the administrator, it’s a little more complicated. If you’re not the only administrator, you can ask another administrator to reset your password. If you are the only administrator, or if another administrator isn’t available, you can use the new automated administrator password reset process. On the Office 365 sign-in page, click Forgot your password? to start the process. We want to protect the security of your account, so you have to follow several steps. As you step through the process, you’ll receive an email containing a link. When you click that link, a text message containing a code is sent to your mobile phone, and a Web page is displayed where you enter that code. After you enter the code and click Next, then you enter a new password.

For the administrator password reset to work, you must have already provided a phone number on which you can receive a text (SMS) message and an alternate email address. The email address must not be your Office 365 email address, because if you can’t sign in to your Office 365 account, you can’t retrieve email sent to that address. You enter this information in the user management area. To get there, click Admin, and under Management, click Users. On the Settings tab, you enter the email address in the Alternate email address box. On the Properties tab, you enter the mobile phone number in the Mobile phone box.

Once you submit the reset request, you need to respond promptly to the email and to the text message. There is a 10-minute timeout period each for the email and for the text message, after which you'll have to restart the process.

If you haven’t provided alternate email address and mobile telephone information, you may see a popup window that prompts you to provide this information when you sign in to Office 365. Taking a few seconds to type the information may spare you a headache later.

For more information about how an administrator can reset his or her own password, see the Help topics:

For Office 365 for enterprises, see Reset an administrator's password
For Office 365 for professionals and small businesses, see Reset an administrator's password

Office 365 Password Reset Beta

AnthonyHo — Tue, 30 Aug 2011 05:37:13 GMT

Over the last year, I have been working on this Office 365 Password Reset project.

We are doing a closed beta. If you are interested to signup and provide feedback, click on the link which contains information on the action items.

http://community.office365.com/en-us/b/office_365_technical_blog/archive/2011/08/26/password-reset-beta.aspx

FIM 2010 R2 - Web-Based Password Reset, Part 1

AnthonyHo — Mon, 01 Aug 2011 00:59:00 GMT

I am very excited to let everyone knows that FIM 2010 R2 Beta has released featuring Web-Based Password Reset.

How to download FIM 2010 R2 Beta

Go here.
Answer the survey questions and Submit. This auto-approves you for the Beta connection.
Click the Downloads link in the left column.
Click the FIM 2010 R2 Beta download link.
Follow the instructions.

The download also includes R2 language pack and documentations. We will soon be publishing the documentations on TechNet as well.

Web-Based Password Reset - Screenshots

Registration

Welcome Screen
Password Gate. It asks for your password. You don't want someone else to register for you while you are not at your machine right?
QA Gate. Hm... What is my Employee number? Let me think...
That's it. Pretty easy huh.

Reset

I don't remember my password. Let's reset it.
I know the answers :)
What do I want for my new password?
Wow, I can't believe it is that easy and fast.

RunAs in FIM 2010

AnthonyHo — Wed, 27 Jul 2011 09:34:00 GMT

Often times, I come across the question

How can I write some code to do something as another user in FIM 2010?

Generally I see two different answers:

Impersonate the other user
Set the ActorId to the user

So which one is correct?

In fact, both can be correct, depending on what you are trying to do.

How does FIM work?

To understand which approach you should use, you have to understand how FIM works.

FIMService exposes different WebService endpoints for differetn Create / Read / Update / Delete / Enumerate / etc operations. Those endpoints have a binding that requires Kerberos. When an EXE running as DomainA\JohnDoe makes a WebService call to FIMService, FIMService will look at the WindowsIdentity of the caller and first thing it does is creating a Request Object with Requestor stamped as the calling user (JohnDoe in this case). This is pretty much a few of the only place where FIMService is looking at the WindowsIdentity. From then on, FIMService will follow the request processing pipeline based on the Request Object.

Now consider an ASP.NET application (imagine a FIMPortal clone) is running as DomainA\PortalServiceAccount which provides a front-end UX for Group Management. When JohnDoe goes to the portal, the ASP.NET app should really be making the WebService call as JohnDoe (instead of PortalServiceAccount) so the rights / permissions applies. In this case, it is not hard to imagine that ASP.NET code should impersonate JohnDoe and make the WebService call to FIMService. This is answer #1.

After the Request Object is created with proper Requestor stamped, FIMService executes the request processing pipeline under its own credential (i.e. FIMService service account). FIMService does NOT impersonate the user. That's partly because FIMService manages its own rights / permissions using Management Policy Rule (MPR). FIMService does NOT rely on Active Directory's permission infrastructure.

As part of the request processing pipeline, FIMService will run different Workflows and Activities. Since FIMService does NOT impersonate the Requestor, it is FIMService service account that is executing the code as far as .NET and OS can tell. Now, in the Activity code, if you want to do something as JohnDoe, you will set the ActorId to JohnDoe. This is answer #2.

Base line is that:

Kerberos is an Active Directory construct and it's the way to let FIMService knows who is making the WebService call. A client application running as UserA can impersonate as UserB when making the WebService call so the Requestor would become UserB. If you are writing a custom client to consume FIMService's WebService endpoints, you should impersonate.
On the other hand, ActorId is a FIMService construct in the Activity so that rights check and a few other things happens appropriately (FIMService service account is pretty much omnipotent in an Activity)
Nothing prevents you to impersonate within your custom Activity (if you know what you are doing). For example, you can impersonate to make call outside of FIMService to do something else.

FIM 2010 Self-Service Password Reset Now Supports All Domain Password Policies

AnthonyHo — Wed, 10 Nov 2010 07:01:48 GMT

I am excited to announce that FIM 2010 Self-Service Password Reset now supports all domain password policies. It was a joint effort between the Windows Active Directory and FIM development teams to provide this new functionality.

Details of this change can be found in http://support.microsoft.com/KB/2443871.

Troubleshooting FIMService / FIMPortal / Password Reset Client

AnthonyHo — Wed, 29 Sep 2010 08:09:00 GMT

FIM is a complex product. Once a while, I find myself just clueless why something does not work. I have the advantage of having access to the source code and be able to debug. Attaching a debugger isn't a 5-second task and very often the answer is actually in the log. In this blog post, I would talk about how to enable tracing.

Warning: you should always backup your config file before making any change.

Let's start with the easiest - Password Reset Client.

The following is the config file for the client at C:\Program Files\Microsoft Forefront Identity Manager\2010\Password Reset Client Service\PwdMgmtProxy.exe.config.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section
            name="resourceManagementClient"
            type="Microsoft.ResourceManagement.WebServices.Client.ResourceManagementClientSection, Microsoft.ResourceManagement"/>
    </configSections>
    <resourceManagementClient
        resourceManagementServiceBaseAddress="http://localhost:5725"
        timeoutInMilliseconds="60000" />
    <appSettings>
        <add key="NamedPipeTimeout" value="10000"/>
    </appSettings>
<!--
    <system.diagnostics>
        <sources>
            <source name="Microsoft.ResourceManagement" switchValue="Warning">
                <listeners>
                    <add type="System.Diagnostics.DefaultTraceListener" name="Default">
                        <filter type="" />
                    </add>
                    <add initializeData="C:\Logs\PwdMgmtProxy.svclog"
                        type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
                        name="ResourceManagementListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
                        <filter type="" />
                    </add>
                    <add initializeData="Application" type="System.Diagnostics.EventLogTraceListener"
                        name="myEventListener">
                        <filter type="System.Diagnostics.EventTypeFilter" initializeData="Error" />
                    </add>
                    <add type="System.Diagnostics.ConsoleTraceListener" name="myConsoleListener"
                        traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
                        <filter type="System.Diagnostics.EventTypeFilter" initializeData="Information" />
                    </add>
                </listeners>
            </source>
        </sources>
        <trace autoflush="true" indentsize="0" />
    </system.diagnostics>
-->
</configuration>

FIM uses standard .NET Tracing and Instrumenting libraries. I have highlighted a few important things in the config file:

The entire <system.diagnostics>...<system.diagnostics> is commented out. You will need to un-comment that.
The managed part of FIM (FIMService / FIMPortal / Pwd Reset Client) shares the same tracing library and all traces are written to a source Microsoft.ResourceManagement. You should not change this part.
The Warning switch means for all FIM specific traces, only traces of warning level and above will be considered. Notice nothing has been logged so far.
For those traces that are being considered, they will be passed to each of the listeners:
1. The XmlWriterTraceListener will write all the traces to the file C:\Logs\PwdMgmtProxy.svclog.
2. The EventLogTraceListener will further filter only trace with Error level and above, and write them to event log.

So to enable tracing for Password Reset Client, you will need to:

Uncomment <system.diagnostics>...<system.diagnostics>
Change Warning to Verbose
If you want everything to be written to event log as well, change Error to Verbose as well
Create C:\Logs and grant NETWORK SERVICE full access on that folder so the file can be created.
Restart FIMPasswordReset service

FIMService and FIMPortal are really the same

The FIMService config file (C:\Program Files\Microsoft Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config) already contains inline comment on how to enable tracing. You can follow those steps.

If you want to log everything, you can replace <system.diagnostics> section with the following.

Warning, the trace file gets really huge and the default EventLogTraceListener will be removed. You should revert your config after troubleshooting so that at least Error level traces are logged to the event log.

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel.MessageLogging" switchValue="Verbose,ActivityTracing">
      <listeners>
        <add type="System.Diagnostics.DefaultTraceListener" name="Default">
          <filter type="" />
        </add>
        <add name="ServiceModelMessageLoggingListener">
          <filter type="" />
        </add>
      </listeners>
    </source>
    <source name="System.ServiceModel" switchValue="Verbose,ActivityTracing"
      propagateActivity="true">
      <listeners>
        <add type="System.Diagnostics.DefaultTraceListener" name="Default">
          <filter type="" />
        </add>
        <add name="ServiceModelTraceListener">
          <filter type="" />
        </add>
      </listeners>
    </source>
    <source name="Microsoft.ResourceManagement" switchValue="Verbose,ActivityTracing">
      <listeners>
        <add type="System.Diagnostics.DefaultTraceListener" name="Default">
          <filter type="" />
        </add>
        <add name="ServiceModelTraceListener">
          <filter type="" />
        </add>
      </listeners>
    </source>
  </sources>
  <sharedListeners>
    <add initializeData="C:\Logs\Microsoft.ResourceManagement.Service_messages.svclog"
      type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
      name="ServiceModelMessageLoggingListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
      <filter type="" />
    </add>
    <add initializeData="C:\Logs\Microsoft.ResourceManagement.Service_tracelog.svclog"
      type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
      name="ServiceModelTraceListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
      <filter type="" />
    </add>
  </sharedListeners>
  <trace autoflush="true" /> 
</system.diagnostics>

<system.serviceModel>
  <diagnostics>
    <messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" />
  </diagnostics>
</system.serviceModel>

For FIMPortal, the config file is at C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config. You will need to change the highlighted filename to something else. For example, use:

ILMPortal.Client_messages.svclog
ILMPortal.Client_tracelog.svclog

The *_tracelog.svclog contains all the FIM specific traces instrumented by the FIM team (you will spend 99% of your time with this file). On the other hand, *_messages.svclog contains WCF specific traces.

How to Get Rid of the Generic FIMPortal Error Page?

When there is an error in FIMPortal, you will see the follow screen which absolutely contains no useful information at all.

Thomas Vuylsteke has blogged about how to get rid of hat to get a full stack trace which is usually enough for you to troubleshoot FIMPortal issues.

How Does Lockout Gate Work

AnthonyHo — Thu, 29 Apr 2010 00:34:00 GMT

I am back! I haven't forgotten you all. I was just busying with RTM Update 1 which is now live on Microsoft Update.

In Forefront Identity Manager - Credential Management, Part 2, i talked about what Lockout Gate is capable of doing and in the Password Reset Deployment Guide, it mentions if you put the Lockout Gate as the first gate, there is the possibility of DoS attack and the mitigation is to put a QA gate in front of the Lockout Gate.

I have received a couple inquiries regarding that point and I realize the documentation never explains how Lockout Gate works and why the ordering/position of the Lockout Gate relative to other gates matters. This post is trying to address them.

How it works

Each gate can be interactive (requires user interaction) or non-interactive; and regardless of which type of gate it is, gates are executed in sequential order one after each other. Lockout Gate is an non-interactive gate and it does the followings:

It checks if the user is temporarily locked out. If yes, the authentication will fail and the user would receive an error message. Notice if the user is permanently locked out, the request processor will kick the user out in earlier stages and will never hit the Lockout Gate.
Increments the lockout counter for the specific user.
Temporarily or permanently lockout the user if necessary based on the updated counter.

It also registers itself to the workflow's Completed event, when signaled, will unlock the user.

Why ordering matters

Consider if you have Lockout -> QA in the AuthN WF, a malicious user can initiate SSPR for EmployeeA and intentionally fail the QA gate to permanently lockout EmployeeA. By changing the AuthN WF to QA -> Lockout -> QA, the Lockout Gate will not be hit unless the malicious use passes the first QA Gate. Please note that in this case, the first QA Gate is not protected by the Lockout Gate and is subjected to brute force attack. That is the price you have to pay to prevent DoS using Lockout Gate. You should work with your security compliance team in your organization to decide what is right for your company.

Common mistakes

Once a while, I get feedback saying "I have failed the QA Gate many many times but the lockout logic does not kick in".

Usually that is because the Lockout Gate is sequenced at the end of the AuthN WF. Now since you know how Lockout Gate works, it is obvious that by putting it at the end of the AuthN WF, the internal counter of the lockout gate will be incremented but reset back to zero immediately after that.

FAQ: Why would canceling out from the QA Gate increment the lockout count

While it is true that you never fail the QA Gate, the lockout count is not kept in the QA gate. Thus, when you see the QA Gate, the lockout count has already been incremented (and in fact, the user is temp/perm locked out already). So it is not failing or canceling the QA Gate (or any gate) that increments the count, it is the fact that executing the non-interactive Lockout Gate increments the count.

Call for Topics

AnthonyHo — Thu, 18 Mar 2010 07:37:00 GMT

Is there anything in particular that you want to know more? Leave me a message :P

Self-Service Password Reset to Non-Active Directory System

AnthonyHo — Fri, 29 Jan 2010 21:20:00 GMT

Background:
I often come across two types of questions in both internal and external channels

How can I leverage SSPR and reset a password for a non-AD account (e.g. MSSQL, HR or .NET Passport)?
How can I implement password filters but do so in FIM instead of AD?

For #1, PCNS together with FIM Synchronization Service and your custom MA might do the magic. The side effect is that both your AD and external system's password will be reset. So if you want to keep the passwords different or find it too much trouble to write your custom MA, then this option is out.

The official answer is NO because the SSPR client is closely tied together with the Active Directory Password Reset Activity and using the SSPR client to interact with any other Password Reset activity is not supported.

However, if you are an enthusiast and want to explore the unsupported territory by writing a custom External Password Reset Activity, you can reuse the ReadResourceActivity and XmlInteractiveActivity shipped with FIM to achieve that. High level implementation consists of the following steps:

Add an XmlInteractiveActivity. This activity knows how to commuticate with this activity.

Set EnableDefaultOperationValidation and ValidateSamlToken to true.
Set EndpointAccessUserList to be the Guid of Anonymous User
Set DocumentType to typeof(PWResetRequestData)
Add a handler to XmlDocumentValidation in which you will implement your password reset logic. The user password can be obtained by ((PWResetRequestData)e.XmlDocument).NewPassword

At this point, you don't have access to the Domain\Username of the user. To do so, add an ReadResourceActivity before the XmlInteractiveActivity.

Set ActorId and ResourceId to the current user.
Set EndpointAccessUserList to be Domain and AccountName

Now your activity would have access to Domain\Username as well as the new password. Do whatever you want with them. Resulting activity will look like:

This sample is a mock activity that does not reset password to any system. It merely returns success/failure of your choice and you have to implement your password reset logic. It does not have any error handling or retry logic (You probably want to use the WhileActivity). However, it demonstrates how one might to go about addressing the two problems mention above.

Feel free to download the source code and play with it.

P.S. You have to click into this post to see the attachment.

WARNING: THIS CUSTOM CREDENTIAL PROVIDER IS NOT SUPPORTED AND IS PROVIDED AS IS WITHOUT ANY WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED.

Custom Credential Provider for Password Reset

AnthonyHo — Sun, 15 Nov 2009 07:32:00 GMT

The credential provider for Password Reset is fairly simply and straight forward. Since I have joined the team, there is very little code change in that area. Recently, we decided to fix some minor known bug in the credential provider (CP) and I realized I don't know too much about how CP works.

So I downloaded the samples in Windows SDK and played with it. After some time, I came up with the following.

Notice the extra tile at logon screen

... and after you click on the tile.

Feel free to download the source code and play with it. The zip file contains x86 and x64 release builds.

P.S. You have to click into this post to see the attachment.

WARNING: THIS CUSTOM CREDENTIAL PROVIDER IS NOT SUPPORTED AND IS PROVIDED AS IS WITHOUT ANY WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED.

Forefront Identity Manager - Credential Management, Part 4

AnthonyHo — Mon, 09 Nov 2009 06:27:00 GMT

This post talks about how client interacts with the server during the course of Self-Service Password Reset Registration and Reset. Majority of the information can be found from either client-side or server-side log. The implementation is subjected to change. If you were to develop a custom SSPR client based on the information below, please make sure what you do is supported.

Deep Dive into Self-Service Password Reset

Components and terminologies:

Gate Framework (GF), client side unmanaged component. It handles the UI of varies gates and the password reset screen.
PasswordProxy (Proxy), aka FIMPasswordReset, client side managed component. It acts as a proxy between Gate Framework and FIM Service.
FIM Service
Secure Token Service (STS), a component of FIM Service that issues tokens

Communication channels used:

Between Gate Framework (GF) and PasswordProxy uses namepipe because GF is native and PasswordProxy is managed.
Between PasswordProxy and FIMService/STS uses WCF.
Between FIMService and FIMSynchronizationService uses WMI.

Registration Sequence

C:\Windows\System32\MsPwdRegistration.exe auto starts when user logon.
It performs some housekeeping routines and call into GF to initiate the registration sequence.
GF establishes a secured name pipe to Proxy.
Proxy will then
1. Lookup the user guid: /Person[Domain='...' and Account='...']
2. Lookup all possible AuthN WFs that can be used by the user for SSPR
  /MPR[Disabled=false && (PrincipalSet=Anonymous && ResourceCurrentSet=/Set[ComputedMember='user guid']) && ActionType='Modify' && ActionParameter='ResetPassword']/AuthenticationWorkflowDefinition
3. For each AuthN WF, determine if the user:
  1. Has registered or not (User.AuthNWFRegistered attribute).
  2. Is locked out or not (User.AuthNWFLockedout attribute).
4. Return to GF with one of the value:
  1. Registration required, when one or more AuthN WFs is not registered.
  2. LockedOut, when user is locked out of one or more AuthN WFs.
  3. Registration Optional otherwise.
If the return value is not Registration Optional, GF will display the Registration Welcome Screen.
To register, Proxy sends a Put request to add the AuthN WF Guid to User.AuthNWFRegistered.
This request will trigger the AuthN WF "System Workflow Required for Registration" caused by MPR "General workflow: Registration initiation for authentication activity" and Proxy will receive an AuthNRequiredFault.
The AuthN fault contains the endpoint address of STS that the client needs to talk to to obtain a token.
Proxy then relays message between GF and STS. STS will send a list of challenges (e.g. Q&A) and GF will display the questions and reply back with the answers that user inputs, etc etc.
At the end of the challenge-response sequence with the STS, STS will issue a token indicating the User has passed the AuthN WF.
Proxy then resumes the original request with the STS token.
After that, the request goes through the normal AuthZ, Commit and Action phases.

Reset Sequence

User clicks on the "Reset Password" link on the logon screen.
Gina/Credential Provider calls into GF to initiate the reset sequence.
GF establishes a secure channel with Proxy.
Proxy sends a Put request which Modify User.ResetPassword attribute.
This request will trigger the AuthN WF "Password Reset AuthN Workflow" caused by MPR "Anonymous users can reset their password" and Proxy will receive an AuthNRequiredFault.
Proxy then obtains a STS token and resumes the request just like during registration.
The request goes through the normal AuthZ, Commit and Action phases.
During Action phase, it will kick off Action WF "Password Reset Action Workflow".
This workflow will listen on an endpoint awaiting user to input their new password.
Once the Password Reset Action Workflow receives the new password, it will, under the FIMService service account context, make a WMI call to the FIMSynchronizationService to perform a SetPassword.
FIMSynchronizationService, under the AD MA account context, will talk to the primary domain controller (PDC) to reset the user password.

That's it. Feel free to leave me a message if you need clarification.

Forefront Identity Manager - Credential Management, Part 3

AnthonyHo — Tue, 20 Oct 2009 10:42:00 GMT

In RC0, setting up Password Reset is a painful process for many of you (including myself). In RC1, we ship FIM with all the MPRs, along with the supporting sets and workflows, you will need for SSPR.

Today I am going to talk about why we need each one of them.

General: Users can read non-administrative configuration resources
User management: Users can read attributes of their own

These two MPRs are not Password Reset specific. They are needed to allow normal user to navigate the portal.
The first MPR grants users permission to read non-admin configuration objects which includes but not limited to NavBar Configuration (left side of the portal), Homepage Configuration (middle and right side of the portal) and Search Scopes (the search box on top of the homepage).
The second MPR grants users permission to read their own info such as DisplayName. This is needed because we want to display a nice warm welcoming message to the user (i.e. Welcome, John Doe).

There are 4 Password Reset specific MPRs

Anonymous users can reset their password
This MPR grants users permission to initiate a SSPR request. This also specify which Authentication Workflow(s) should be used.
Password reset users can read password reset objects
In order for the system to prompt you register for Password Reset, it needs to know if an user is eligible for that. It is done by:
1. Loop through all MPRs
2. Find the enabled ones that grants Anonymous Users modify permission on the Reset Password attribute
3. Further filter the results to make sure the user is a member of the target resources set
4. Get the Authentication Workflows from the MPRs
Then the client will prompt users to register for those AuthN WFs.
Obviously, users need permission to read lots of attributes in order to perform the steps above. This MPR allows that to happen.
Password Reset Users can update the lockout attributes of themselves
Lockout gate adds a few references to the User object. For example, if the user is locked out, the Workflow guid is added to User.AuthNWFLockedOut. Also the lockout gate registration object's guid is also added to User.AuthNLockoutRegistrationID to facilitate finding the object. This MPR grants the permission needed for that specific reason. The principal set is relative to resource object's ResourceID so that one can modify their own attribute.
Users can create registration objects for themselves
For obvious reason, FIM needs to store the QA registration data (for QA gate), number of failed attempts (for lockout gate). All those data are stored as Gate Registration objects. (4) grants users permission to create and modify gate registration objects. (Though the name only mention create, it's also granting modify permission). The principal set is relative to the resource object's UserID because we don't want UserA to be able to create gate registration for UserB (i.e. UserA registers for UserB).

Forefront Identity Manager - Credential Management, Part 2

AnthonyHo — Sun, 04 Oct 2009 09:21:00 GMT

FIM ships with three Authentication Activities (a.k.a. Authentication Gates) that are used primarily in Self-Service Password Reset (SSPR).

Question and Answer Gate
This is the most obviously one in SSPR. During registration mode, it prompts the user with a list of pre-defined questions (e.g. What's your first pet's name?) The user is required to answer a subset of the questions. The answers are hashed and stored in the FIM database. During authentication mode, it display the questions that the user has registered for and the user is required to answer them correctly to pass this gate.

Configurable settings includes

Total number of questions: n
System admin can pre-defined n questions in this gate.
Number of questions displayed during registration: p
Only p out of n questions are displayed randomly to users during registration.
Number of questions required for registration: q
Users must register at least q out of p questions during registration.
Number of questions randomly presented to the user: r
Please bare with me unclear wording. It means r out of the q questions that the user registered with will be presented during authentication.
Number of questions that must be answered correctly: s
Users must answer s out of r questions correctly to pass this gate.

And obviously, n > p > q > r > s

Password Gate
The most common question I have been asked is that, "I try to reset my password because I have forgotten it. Now you are going to ask for my password?" This is not how the password gate works. Password Gate asks for your password during registration only. For example, if you go to bathroom and forget to lock your computer, you probably don't want someone else to register on your behave and reset your password immediately. It allows FIM to make sure it is you that are registering for password reset.

Lockout Gate
The lockout gate is used to prevent malicious hackers from doing a brute force attack. This gate does not display anything to the user during registration or authentication.

It is best using the example below to explain how it works

Lockout duration after Lockout Threshold is reached (minutes): 15
Lockout Threshold - number of times the user can fail to complete the workflow: 3
Number of times the user can reach the Lockout Threshold before permanently lockout: 2

The net effect will be as follow:

Failed attempt 1
Failed attempt 2
Failed attempt 3
Now the user is temporarily locked out and can only try again after 15 minutes
Failed attempt 4
Failed attempt 5
Failed attempt 6
Now the user is permanently locked out.

At any point of time, if the user successfully passes the entire authentication workflow or re-register, the counters are reset to 0 and unlocked automatically.

Please note that lockout mechanism is FIM specific. It has nothing to do with the "User Lockout" in Active Directory.

Forefront Identity Manager - Credential Management, Part 1

AnthonyHo — Thu, 01 Oct 2009 02:59:00 GMT

Background
Nowadays, for most companies, if an employee forgets his password, very likely he would need to call help desk to reset the password for him. FIM helps enterprise reduce help desk cost by providing "Self-Service Password Reset" (SSPR).

Scenario

After deployment, employee will be prompted to answer a list of questions (e.g. "What's the name of your first pet") defined by system admin upon logging on to the machine.
After a nice long Christmas, he goes back to work and has forgotten his password.
He will be stuck at the logon screen and notice there is a new "Reset Password" link.
Upon clicking on the link, he will be prompted for a list of questions he previously registered with in step (1).
If he answers the questions correctly, he will be prompted to input his new password.
He submits his new password (which has to be complied with the corporate policy).
He can then logon to his machine with the new password and continue to work.

Screenshots

Registration

Welcome Screen
Password Gate. It asks for your password. You don't want someone else to register for you while you are not at your machine right?
QA Gate. Hm... Who is my favorite author? Let me think...
That's it. Pretty easy huh.

Reset

I don't remember my password. Let's click on the Reset Password link in logon screen.
I don't remember my first pet's name. Luckily, I do remember the others.
What do I want for my new password?
Wow, I can't believe it is that easy and fast.