Introduction

Prerequisites

Configuration Steps

Windows Identity Foundation (WIF) Configuration Steps

SecureAuth IdP Web Admin Configuration Steps

OWA Integration Configuration Steps

Exchange Control Panel (ECP) Functionality Configuration Steps

URL Rewrites (optional)

Known Issues

Tips & Warnings

See Outlook Web Access (OWA) 2010 Integration Guide for integration with OWA 2010

Use this guide to enable Multi-Factor Authentication and Single Sign-on (SSO) access via claims-based authentication and WS-Federation to Microsoft Outlook Web Access (OWA) 2013 SP1 / 2016.

1. Have OWA 2013 SP1 / 2016 installed on a server

NOTE: The certificate chain for the certificate used for signing the WS-FED assertion must be trusted by the Exchange Server.

2. Create a New Realm for the OWA 2013 SP1 / 2016 integration

3. Configure the following tabs in the Web Admin before configuring the Post Authentication tab:

  • Overview – the description of the realm and SMTP connections must be defined
  • Data – an enterprise directory must be integrated with SecureAuth IdP
  • Workflow – the way in which users will access this application must be defined
  • Multi-Factor Methods – the Multi-Factor Authentication methods that will be used to access this page (if any) must be defined

Windows Identity Foundation (WIF), a Microsoft framework for building identity-aware applications, is a core component in this installation and must be installed on the SecureAuth IdP server (if it hasn't already been installed)

1. To install WIF on the SecureAuth IdP server, download WIF from Microsoft's Download Center

NOTE: On Windows 2012 and later, install WIF via Server manager > Add / Remove Roles and Features.

2. Install the update and perform an IISRESET on the appliance

 

1. In the Profile Fields section, map the userPrincipalName to a SecureAuth IdP Property (e.g. Email 2)

Click Save once the configurations have been completed and before leaving the Data page to avoid losing changes

 

2. Select WS-Federation Assertion from the Authenticated User Redirect dropdown in the Post Authentication section

3. An unalterable URL will be auto-populated in the Redirect To field, which will append to the domain name and realm number in the address bar (Authorized/WSFedProvider.aspx)

 

4. Select the SecureAuth IdP Property that corresponds to the directory field that contains the userPrincipalName (Email 2)

5. Select urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified from the Name ID Format dropdown (default)

6. Select False from the Encode to Base64 dropdown

 

7. Set the WSFed/SAML Issuer to https://SecureAuthIdPFQDN/SecureAuthIdPRealm#/ and replace the values with the actual Fully Qualified Domain Name (FQDN) of the SecureAuth IdP appliance and the OWA integration realm number, e.g. SecureAuth2

For example, https://secureauth.company.com/secureauth2

8. Set the SAML Audience to https://mail.companyname.com/owa/ and replace "mail.companyname.com" with the actual DNS value

No configuration is required for the WSFed Reply To/SAML Target URL, SAML Consumer URL, SAML Recipient, or SP Start URL fields

 

9. Leave the Signing Cert Serial Number as the default value, unless there is a third-party certificate being used for the SAML assertion

If using a third-party certificate, click Select Certificate and choose the appropriate certificate

 

10. Set the Name of Attribute 1 to UPN

11. Set the Namespace (1.1) to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

12. Select Email 2 (or the field that contains the userPrincipalName) from the Value dropdown

The Value here and the User ID Mapping selections will be the same


Click Save once the configurations have been completed and before leaving the Post Authentication page to avoid losing changes

 

13. Click View and Configure FormsAuth keys / SSO token to configure the token/cookie settings and to configure this realm for SSO

These are optional configurations


If the code from the certificate window was pasted into thumbprint="", replacing the content within the quotation marks, there may be issues. The quotation marks may also need to be deleted and retyped as those additional characters still exist within the string. In the Event Viewer, an Error 1003, MSExchange Front End HTTP Proxy - ID4175 will be present if this is the issue. To resolve, delete the entire thumbprint, including the quotation marks, and retype the quotes and thumbprint value manually. For more information, click here.

If code content was copied from a PDF or other format, be aware that line breaks may be put into the web.config, breaking functionality. Line breaks need to be removed manually on all code if not copying directly from this webpage.

In some environments, an error occurs after setting the time zone for new users. As a workaround, use a powershell script or other automated method to set the value for msExchUserCulture (e.g. en-US).

Set up SecureAuth IdP workflows as they normally would be. To utilize Windows Desktop SSO, WindowsSSO.aspx will need to be set as the default document and coded to retain the referral string. If Desktop SSO will be redirecting external users to another realm, the secureauth.aspx.vb page in that realm will need code that strips out the "?403;https://<SecureAuth-FQDN>/SAOWARealm". Refer to Windows desktop SSO configuration for more information on enabling Windows Desktop SSO for SecureAuth IdP realms.

When setting URLs in the web.config files and SecureAuth IdP, it is essential to be consistent and not forget something as simple as a trailing slash "/".