Wednesday, February 1, 2012

OWA SP2 and ADFS

I was recently tasked to configure OWA SP2 with ADFS 2.0, a quick scouring of good old web quickly made me realize that I am pretty much on my own. There is a very nice article by Ken at http://www.theidentityguy.com/articles/2010/10/15/access-owa-with-adfs.html which  works beautifully with exchange 2010 RTM and exchange 2007 but FedUtil complains when it is tried on SP2 OWA web.config file. The technet article at  http://technet.microsoft.com/en-us/library/bb691348.aspx also covers less than half of the story. After exhausting all other options I got in touch with Microsoft support and after working with them for couple of weeks got some pointer and was finally able to complete this configuration and thought to share this with the community. 

Disclaimer: This isn't tested in production nor it is officially endorsed by Microsoft but you are welcome to use it at your own risk. Comments and feedback are more than welcome. 

Purpose

This procedure provides a step by step guide to enable Single Sign On for OWA 2010 SP2 using ADFS 2.0. It is a side by side configuration of a new instance of OWA with ADFS with the default instance continue supporting non-federated authentication. Although not tested , it should be possible with little modification to apply the procedure directly on the default instance. Procedure is for CAS on Windows 2008 R2 server with IIS7.x

Pre-Requisite

  • New IP address assigned to the machine
  • Domain name mapped to the new IP and corresponding SSL certificate
  • Installation account with local administrative rights and Exchange admin rights.
  • Test account with mail box to test the configuration

Step 1: Create New OWA 

  • Using IIS mmc create a new web site in IIS on the Client Access Server and bind it to the new IP address and the SSL certificate
  • Change the Application Pool Identify to LocalSystem and Load User Profile to true
  • Launch Exchange Management Shell and run the cmdlets to create a new OWA and ECP site. Provide the name of the website created in above step for the –WebSiteName parameter
    • New-OWAVirtualDirectory –WebSiteName OWASSO
    • New-ECPVirtualDirectory  –WebSiteName OWASSO
Navigate to the owa Website URL. It should prompt you for username and password and on providing valid credentials you should be logged in

Step 2: Configure OWA and ECP Security Settings

  • Launch Exchange Management Console and select Client Access under Server Configuration , pull up the properties of the newly created OWA and on the Authentication tab of the property dialogbox select Use one or more standard authentication methods option. Make sure that no checkbox is selected under this option
  • Do the same for corresponding ECP 

  • Exchange will warn about missing authentication, ignore this warning and reset IIS using iisreset /noforce
  • From IIS mmc enable Anonymous authentication for owa. Note that for ecp Anonymous authentication should be already enabled. Reset IIS again.


Step 3: Install WIF and C2TWS

Step 4: Enable OWA and ECP for Federation
  • Create a web.config file in the folder mapped to the root of the web site created in earlier step. Contents of the web.config can be empty <configuration> tag
  • Start FedUtil.exe and on the first screen provide the location of the web.config created above and in Application URI field specify the complete URI to the new OWA application created above. Click Next.


  • On the next page Select Use an existing STS and type in the URL of ADFS in the STS WS-Federation meta document location. Click Next. 
  • Accept the default value on the rest of the screens.
  • Open the Web.Config file of the new WebSite and make following changes
    • Comment out <httpmodules> section 
    • Add runAllManagedModulesForAllRequests="true" attribute to <modules> tag; the new tag should read 
      • <modules runallmanagedmodulesforallrequests="true">
    • Add following tags right before <audienceuris>
      • <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>
    • Uncomment following line and change the optional attribute to true 
      • <claimtype optional="true" type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn">
    • Add a path attribute to <cookiehandler requiressl="true"/>. Revised node should read.
         <cookieHandler requireSsl="true" path="/"/>
      This allow ecp to use the SSO cookie generated for owa.
  • Run the FedUtil again on the web.config file. This will update the Federation metadata of new SSO enabled website with the additional UPN claim information. Browse the federation meta data at https://SSO OWA FQDN/FederationMetadata/2007-06/FederationMetadata.xml and make sure UPN appears as a mandatory claim type. Where  SSO OWA FQDN in the URL above is the  domain name of new OWA.
  • Configure ‘Claim To Windows Token Service’ and allow Exchange to use it by un-commenting following line in the C2TWS configuration file. 
    • <add value="NT AUTHORITY\SYSTEM" />
  • Change the startup type of C2WTS to automatic and also make it dependent on on CryptSrv service as per this http://support.microsoft.com/kb/2512597. Restart the service.


Step 5: Add OWA as Relying Party in ADFS
Step Assumes that ADFS is installed and configured with AD
  • Add Relying Party Trust in ADFS by using the Add Relying Party Trust wizard in ADFS and using OWA’s Federation Metadata file. In the RP trust wizard on the Select Data Source step, enter the Federation Meta Data URL. Click Next

  • Type in the Display name on the Specify Display Name page and select the default values on rest of the screen. Click Close on the last step. This will open up the Edit Claim Rules dialog box. Click Add Rule and Select Pass Through or Filter an Incoming Claim option in the Claim rule template. Click Next

  • Type in the Claim rule name, and choose UPN as the Incoming claim type. Click Finish and OK to complete the Relying Party Trust configuration


This should complete the configuration. If you now navigate to new OWA URL it should redirect you to ADFS and upon successful authentication you should see your email box. The default OWA should still support the its original authentication setting.

31 comments:

  1. Hi Arshad,

    Very nice write up on how to get this working! I have been trying to get this working for several weeks without much luck.

    Thanks,
    Jamie

    ReplyDelete
  2. Hello Arshad,
    Thank you for your work on this. Using your clear instructions, I was able to get this working - finally!
    I had to make 2 adjustments
    - in section 4: (termination)
    - in section 5: The pass-through claim rule did not work for me, so I changed in Send LDAP Attributes as Claims, and configured a claim transform from AD User-Principal-Name to UPN.

    By the way we are on Exchange 2010 SP1.

    Thanks again
    Chris

    ReplyDelete
  3. Hello,
    Thank you work your Work,
    i just have a small question, where do you copy .
    just before "<add name="WSFederationAuthenticationModule"
    or after : <add name="SessionAuthenticationModule"
    thank you for your help

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. Hello, Arshad

    I used your guide to configure OWA SP1 with ADFS 2.0, but nothing work's. OWA redirect to ADFS server but when it ping back to OWA i see error - Outlook Web App didn't initialize. If the problem continues, please contact your helpdesk. In event log i see Event with ID 29 from MSExchange OWA

    There's an error in your configuration.

    The authentication type specified in the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\web.config file is incorrect. The correct authentication type is "Windows".

    But in web.config authentication type is set to windows.

    Can you help with that ?

    ReplyDelete
  6. Error dissapear after reboot Exchange server and ADFS server.

    ReplyDelete
  7. Is this possible with self signed certificates?

    You mention - Domain name mapped to the new IP and corresponding SSL certificate

    In a lab environment, I've done the following:

    Created a second website 'owasso' on Exchange CA
    Created an A record 'owasso' to map to second ip address of Exchange server
    Set the owasso bindings to listen to second IP and use a self signed SSL cert

    The problem I have is when browsing to https://owasso.fqdn/owa I receive a security warning

    "The security certificate presented by this website was issued for a different website's address."

    At step 5, I then receive an error, creating the relying party trust:

    "An error occured during an attempt to read the federation Metadata. Verify that the specified URL or host name is a valid federation metadata endpoint...."

    Browsing to the federation URL works (see below - this requires continue):
    http://i45.tinypic.com/30vyzgx.jpg

    Is this because I'm using a self signed cert on a server called exchange1 and then applying it to a website using a different name? If so, is there a way around this with self signed certs?

    Thanks


    ReplyDelete
    Replies
    1. Hi

      I think this is because of self signed certificate. As a work around you may try using "Import data about relying party from a file" option in step 5 after you have browsed to the file and saved it locally. I haven't tried it myself but this may just do the trick

      AM

      Delete
  8. Sergey,

    I have the same problem as you, "Outlook Web App didn't initialize" with error 29 in the event log.

    The authentication type is Windows in the web.config owa site (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\web.config), with the owasso site have an authentication type of "None".

    Unfortunately a reboot of ADFS and Exchange doesn't clear the message. Is there anything else you did other than reboot to get this working?

    Not sure if it's causing an issue, but at the end of step 4 it says check to make sure upn is mandatory, but preceding shows the web.config file with an optional upn.

    ReplyDelete
  9. Hello,

    Thanks for this great article, without it I would never have figured this out. I was wondering if you or anyone has successfully managed to federate with another domain. I provide multi-tenanted exchange services and a lot of customers would really love to authenticate against their own domains.

    ReplyDelete
  10. Guys,

    Don't do this. Microsoft has changed their stance from "not supported" to advised against. Exchange is not designed for OWA to work with ADFS. Attempting this will result in a less secure, unsupported system which is more than likely to break with updates.

    ReplyDelete
    Replies
    1. It's not that big a deal if you know how to manage it. Microsoft can't simply restrict functionality in order to get everyone into Office365, as much as they'd like to.

      Delete
  11. This comment has been removed by the author.

    ReplyDelete
  12. Changes to this instruction (thanks soybased for clues):
    1. Section below not above
    2. Capital letters in section names:
    - samlSecurityTokenRequirement
    - securityTokenHandlers
    - mapToWindows and useWindowsTokenService
    3. Send claims (UPN) as LDAP attributes (thanks to Sergey).

    ReplyDelete
    Replies
    1. EPC is not loading properly after upgrading to rollup1 in SP3 i tried till rollup 4 on SP3 all same issue. BUt until SP3 it is fine. It breaks from Rollup 1. Any idea what is going on from rollup 1.

      Delete
  13. I just got this working on Exchange 2010 SP3 running on Windows Server 2012!! I am supper happy about it!. I am now running the process through additional testing and tweaking the setup a bit. A big thanks to; Ashad Masood for providing the basis of this setup and to Chris Houthuijs for the additional details of the Relying Party trust.

    ReplyDelete
  14. I'm getting a loop. I get directed to ADFS, enter credentials and then I see the inbox but then it keeps trying to loop almost endlessly. It must be something in the web.config

    ReplyDelete
  15. Hi,

    Nice document. I followed this document and created the federation . Now i can access OWA but ecp does not work. It always says Access Denied. I am in Exchange 2010 rollup 4. Appreciate some suggestions.

    ReplyDelete
    Replies
    1. Hello Krrish, were you able to get past the EMC issue? I have been hitting this hard and I just cant seem to nail it. Any help... from anyone would be greatly appreciated.

      Delete
    2. Hi Krish, did you fix your access denied from ECP app? I am getting the same issue. thanks

      Delete
    3. Hi, we overcame this issue by Federating the ECP app as well. Now, we get into ECP but the page is not styled and the links do not work. I think it's a permissions issue to the folders in the app or something. Investigating now.

      Delete
  16. Hi Guys,

    I did the SP3 rollup 4. I see the ECP getting accessed, but i get a ecp page without images. And all the links i click on does not work. Any idea on this?

    ReplyDelete
  17. I have also done the SP3 rollup 4 and I am getting the ecp page without the images too. I managed to make the links clickable, but I am a little stuck on some of the other processes.

    James | adfs

    ReplyDelete
    Replies
    1. Hello,

      How did you managed to get the links clickable? I have the same issue.

      Delete
  18. Hello everyone, any updates on this? I had been troubleshooting this for sometime but now realize that I am not alone. I am getting the ecp page without images or formatting. None of the links seem to work either.

    ReplyDelete
    Replies
    1. William, I managed to federate ECP app and now I am in the same place as you. Did you fix the ECP web app displaying content issue?

      Delete
  19. This comment has been removed by the author.

    ReplyDelete
  20. This comment has been removed by the author.

    ReplyDelete
  21. I have everything working thanks to this guide and the Identity guides blog, except for the final home run stretch. Like Moss180 and Sergey I am getting error 29 from the 'MSExchange OWA' source in the Application event log.

    'The correct authentication type is "Windows".' I am confident that my web.config is correct after referencing https://msdn.microsoft.com/en-us/library/aa291347(v=vs.71).aspx but Exchange seems to be running a test on it, and I can't figure out how to bypass it. And unlike Sergey rebooting it did not help me in this case sadly.

    ReplyDelete
  22. I know this is years later but I had to implement this while we migrate to a newer version of Exchange.

    This guide works.

    If you are getting error 29, please make sure you capitalize the correct letters in section names as explained in this comment: https://www.blogger.com/profile/15427149254827108827

    To get fully working ECP, you must modify web.config under ecp/{version}/Themes and ecp/{version}/Scripts.

    Add








    before



    to both web.config files.

    The only thing that will not work is logging into ECP directly; you must log into OWA first, then navigate to Options > See all options. After ECP loads change manage myself to my organization.

    ReplyDelete
    Replies
    1. fixing what was stripped above.

      Add
      < system.web>
      < authorization>
      < allow users="*"/>
      < allow users="?"/>
      < /authorization>
      < /system.web>
      Before
      < system.webServer>

      Remove the space after the <.

      Delete