URL Rewrites (optional)
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:
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 "/".