I was asked recently whether it was possible to use Outlook Web App with AD FS 2.0 for authentication.  I’d toyed with this in the past with Exchange 2010 SP1, but things had changed in the Exchange mechanics (.NET) since then and this had caused problems for me when using the old configuration with later service packs.  I was curious to see how it would work with Exchange 2010 SP3. Fortunately, it’s always nice to find someone who has dug before you and the following article provided a good guide :

http://allmsft.blogspot.be/2012/02/owa-sp2-and-adfs.html

Courtesy of a few adjustments to the author’s notes, which I’ll describe here, it shouldn’t be too long before, it’s possible to have OWA up and running using AD FS and claims on a test rig.

Let’s assume the initial steps as described in the article have been followed:

• a new IIS web site has been created
• OWA virtual directories have been created in Powerscript
• FedUtil has been run

We will need to tweak the web.config of the OWA application and you need to watch for case sensitivity issues with the configuration. Equally, the nuances of  FedUtil and how it processes the web.config file can also be a problem. Changes are required in different portions of the file. In the <modules> section of the OWA web.config, the following needs to be add to the header (follow the case exactly):

<modules runAllManagedModulesForAllRequests=”true”>

I also found during the FedUtil processing that the above line would often be rejected, with a complaint about System.WebServer tags.  Should you experience the same issue, try setting the remaining configuration changes without setting the module change above, get FedUtil to accept them and then change the web.config once more, in order for FedUtil to reprocess and accept the value.

Note that you’ll need to add the securityTokenHandlers after the AudienceURI section.

<securityTokenHandlers>
        <add type=”Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″>
          <samlSecurityTokenRequirement mapToWindows=”true” useWindowsTokenService=”true” />
        </add>
      </securityTokenHandlers>

When creating the Relying Party in AD FS and pointing to the metadata path in the browser, you might it failing. In my case, testing the federation metadata would redirect the browser to AD FS, because the published metadata fell under the /owa virtual path and the control of the federation service handler. Creating a virtual directory that pointed directly to the owa\FederationMetadata folder under the web site rectified this.

You’ll need to specify the /owa path in the browser when accessing the OWA claims website, otherwise you’ll get an error within OWA, something along the lines of:

An unexpected error occurred and your request couldn’t be handled.

Copy error details to clipboard

Show details

I suspect this is down to the requested URL not matching the Relying Party Identifier.

Normally when I finish this posts, there’s always a warning about testing…. in this case, this is particularly so. It looks like this is not an extensively tested solution with the Exchange team and that aspects such as Claims to Windows Token Service (C2WTS), while acceptable in the SharePoint world, have not translated to real-world acceptance with the Exchange platform.

So… TEST, TEST,TEST and Caveat Emptor.