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:

1. Disallow duplicated answers
2. 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.

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"

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

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.

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

How to download FIM 2010 R2 Beta

1. Go here.
2. Answer the survey questions and Submit. This auto-approves you for the Beta connection.
3. Click the Downloads link in the left column.
4. Click the FIM 2010 R2 Beta download link.
5. 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

1. Registration
1. Welcome Screen
   
2. 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?
   
3. QA Gate. Hm... What is my Employee number? Let me think...
   
4. That's it. Pretty easy huh.
   
2. Reset
1. I don't remember my password. Let's reset it.
   
2. I know the answers :)
   
3. What do I want for my new password?
   
4. Wow, I can't believe it is that easy and fast.
   

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

Generally I see two different answers:

1. Impersonate the other user
2. 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.

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="https://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:

1. The entire <system.diagnostics>...<system.diagnostics> is commented out. You will need to un-comment that.
2. 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.
3. 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.
4. 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:

1. Uncomment <system.diagnostics>...<system.diagnostics>
2. Change Warning to Verbose
3. If you want everything to be written to event log as well, change Error to Verbose as well
4. Create C:\Logs and grant NETWORK SERVICE full access on that folder so the file can be created.
5. 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.