One way to make sure you have a secure OWA login is to use two-factor authentication. The video below demonstrates how two-factor authentication can be integrated with OWA.
This article is a continuation of steps for federating OWA for Exchange 2010 with SP1 or SP2. It is an optional section that deals with SSL-enabling the OWA SSO website. While not required for a proof-of-concept, it should definitely be done for any pilot or production instance. The previous parts are:
Obtain New SSL Certificate
1) The first thing you need is an SSL certificate for the new website name. There are a few ways to skin this cat:
- Purchase it from a 3rd party Certificate Authority (CA) like Verisign or Thwate. This would typically only be required if the website was going to be publicly accessible.
- Use an internal CA that’s already established (e.g. Microsoft’s CA). This is a good option if only employees using corporate workstations will be accessing it as the CA is implicitly trusted by domain workstations.
- Create a new self-signed CA and certificate using OpenSSL. This is the good for extended testing, but because the CA is self-signed, any certificates issued by it will not be trusted until the CA public certificate is trusted. This is the approach detailed in the following steps below.
NOTE: Regardless of how you get the SSL certificate, the steps to modify IIS and the web.config are identical.
2) Download a pre-built version of openssl.exe (link)
3) Unzip/extract openssl.exe and openssl.cnf to a folder on any workstation.
4) Open a DOS prompt and change directory to the folder containing openssl.exe. Run the following command. It will create a new certificate good for 10 years. Specify the new server alias when prompted for the “Common Name” attribute:
|openssl req -x509 -days 3650 -newkey rsa:2048 -keyout mycert.pem -out mycert.pem -config ./openssl.cnf|
5) The PEM file contains the public private key pair as well as the self-signed certificate. Once it is created, it must be converted to PFX format so it can be imported easily into the Windows certificate store. Run the command below from the same DOS prompt. You will be prompted to enter the same password you entered when creating the PEM file and the password that should be placed on the new PFX file. These passwords can be the same as long as you remember what they are – the PFX password must be provided when importing it on the OWA server!
|openssl.exe pkcs12 -export -in mycert.pem -out owasso.pfx|
Import PFX on OWA Server
6) Copy the new PFX file to the OWA server if necessary, then launch the Microsoft Management Console (mmc.exe) as an administrator and add the Certificates snap-in for the Local Computer. Then import the PFX into the Personal container.
7) The new certificate show now appear in the list:
Enable SSL Binding on OWASSO WebSite
8) Open the IIS Manager, go to the new OWASSO website and click the “Bindings…” link on the right.
9) Click the Add… button to add a new binding (only HTTP over port 80 was enabled previously)
10) Configure it as follows:
- Type: https
- IP address: <new IP previously created>
- Port: 443
- SSL certificate: <new SSL cert
Update web.config File to Require HTTPS
11) Open the C:\inetpub\OWASSO\web.config file in your favorite text editor. Four different places must be updated to ensure SSL is used:
- The value attribute in the <audienceUris> child element should be changed to “https://”:
- The “realm” attribute in the <wsFederation> element needs to be changed to “https”
- The “RequireHttps” attribute in the <wsFederation> element must be set to “true”
- The “requireSsl” attribute in the <cookieHandler> element must be set to “true”
Here is an image showing all four changes after updating:
12) The “realm” value is also sent to the IdP as the site’s identifier, so changing it here in the web.config, then you’ll also need to change it on the Identity Provider’s configuration.
You should now be able to access the OWA site using the HTTPS/SSL port. The rest of the workflow proceeds as before where users will be redirected to the Identity Provider where they will login and receive a SAML assertion that is automatically sent back to OWA to prove the user was successfully authenticated by the IdP.
This article is a continuation of steps for federating OWA for Exchange 2010 with SP1 or SP2. The previous parts are:
Identity Provider Signing Certificate
1) Get a copy of the IdP’s signing certificate. This can be achieved by getting the IdP’s metadata which can be done in various ways based on the IdP. For ADFS, the metadata can be retrieved from the URL below:
For PortalGuard’s IdP, the metadata can be retrieved from:
2) From the metadata, search for the < X509Certificate> element. There can be multiple instances of this element so ensure it is contained within the KeyDescriptor element that has the attribute use=”signing”.
3) Copy the complete value contained in the <X509Certificate> element (it will typically be over 1000 characters) and paste it into a new text file. Rename the text file to “IdP_signing.cer” and it can then be opened as a certificate on Microsoft Windows.
4) Double click the IdP_signing.cer file, click the “Details” tab and scroll down to the “Thumbprint” field:
5) The length of the thumbprint will vary based on the algorithm, but SHA-1 is typically used which will be 40 characters. Copy the thumbprint from the details window and paste it into a new temporary text file. Remove all spaces and ensure the number of characters is still correct (e.g. 40).
6) Lastly, convert the value to all uppercase characters. This can be done manually, but to ensure no errors occur it is advisable to use http://www.convertcase.net or any built in case changing function in your text editor. You will use this thumbprint value in a later step so set it aside for now.
7) Launch the Microsoft Management Console (mmc.exe) as an administrator and add the Certificates snap-in for the Local Computer. Then import the IdP signing certificate into the Trusted People container.
OWA web.config Changes
8) Using your favorite text editor, create a new file named “web.config” in the root folder of the new IIS website (C:\inetpub\OWASSO).
9) Copy the following text into the new web.config file:
<section name=”microsoft.identityModel” type=”Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />
<deny users=”?” />
<authentication mode=”None” />
<add assembly=”Microsoft.IdentityModel, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ />
<add name=”WSFederationAuthenticationModule” type=”Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ preCondition=”managedHandler” />
<add name=”SessionAuthenticationModule” type=”Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ preCondition=”managedHandler” />
<add type=”Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler, Microsoft.IdentityModel, Version=188.8.131.52, Culture=neutral, PublicKeyToken=31bf3856ad364e35″>
<samlSecurityTokenRequirement mapToWindows=”true” useWindowsTokenService=”true” />
<add value=”http:// [YOUR.OWA.SERVER]/owa/” />
<wsFederation passiveRedirectEnabled=”true” issuer=”[IDP.SSO.URL]” realm=”http:// [YOUR.OWA.SERVER]/owa/” requireHttps=”false” />
<cookieHandler requireSsl=”false” path=”/” />
<issuerNameRegistry type=”Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35″>
<add thumbprint=”[IDP.CERT.THUMBPRINT]” name=”IdP_Signing_Cert” />
NOTE: There are two (2) instances of [YOUR.OWA.SERVER] that must be replaced by the server name used to access your OWA server.
NOTE: There is one (1) instance of [IDP.SSO.URL] that must be replaced by the URL where users should be redirected to authenticate. This value will differ from IdP to IdP. For ADFS, the SSO URL is:
For PortalGuard’s IdP the SSO URL is:
NOTE: Replace the one (1) instance of [IDP.CERT.THUMBPRINT] with the thumbprint value you created in step 23.
10) Restart IIS with the “iisreset” command from an administrative DOS prompt
Identity Provider Configuration
11) The final step is to create the service provider or relying party trust on the IdP. This is again different based on the vendor, but the common requirement for OWA is that the user’s userPrincipalName (aka “UPN”) is sent as an attribute value with the following claim type:
When accessing the OWA site, you should automatically be redirected to the IdP’s login page. After successfully authenticating to it, your browser will automatically be redirected back to OWA and you should be logged in as the appropriate user.
Note that the access to the new SSO-based OWA website only supports unencrypted HTTP after following all these steps. It is highly recommended that you enable HTTPS on the site for any endeavors beyond a proof of concept. The last article will deal with how to do that.
This article is a continuation of steps for federating OWA for Exchange 2010 with SP1 or SP2. Please click here for the 1st part.
Create New OWA Website
1) On the OWA Front-End server, add an additional static IP address to the NIC. On Windows 2008 and later:
- Go to Network and Sharing Center
- Click the Change adapter settings link on the left hand side
- Right-click the LAN interface and choose Properties
- Highlight Internet Protocol Version 4 (TCP/IPv4) and click the Properties button
- Click the Advanced button, then click the Add… button in the “IP addresses” section:
- Enter the new IP and corresponding subnet mask, then click Add. The new IP should appear in the listing:
- “OK” your way out of all the dialogs
2) Decide on a new server name for the new IP address and update DNS as necessary. Adding the new IP in Windows will create a new Host (A) record in DNS for the server host name by default. Adding a new CNAME record in the Forward Lookup Zone for your Active Directory domain is a good way to make the new name publicly accessible. For test purposes, you can just as easily add the new server name and IP address to the HOSTS file on the workstations used for testing. This must be done as an administrator in newer versions of Windows. The HOSTS file can be found at the following location:
The format of entries is <IP Address> <server name> as shown below:
3) In IIS Manager, add a new website as show below. Create a new root folder for its Physical path and choose the new IP address (e.g. 220.127.116.11) from the dropdown list in the Binding section:
4) Still in IIS Manager, click the Application Pools item in the left-hand navigator, highlight the app pool for the new website and click the “Advanced Setting…” link on the right.
5) In the Advanced Settings dialog, change the “Identity” to LocalSystem and the “Load User Profile” setting to True. Click OK to save the changes:
6) From the Exchange Management Shell (under the Start -> Microsoft Exchange Server 2010 program group), run the two cmdlets:
New-OWAVirtualDirectory -WebSiteName OWASSO
New-ECPVirtualDirectory -WebSiteName OWASSO
In the commands above, be sure to replace “OWASSO” with whatever you used as the name of the new IIS website in step 8.
7) At this point, you should be able to open a browser and point it to the “/owa” folder of the new website and be prompted to login to OWA (although it’s probably using the Basic authentication popup-up dialog instead of an HTML form).
8) Open the Exchange Management Console under the Server Configuration -> Client Access navigator item. In the lower-middle frame, choose the Outlook Web App tab, and then right-click the new “OWASSO” instance and chose Properties:
9) Choose the Authentication tab, click the “Use one or more standard authentication methods” radio button and uncheck all the boxes. Click OK to save the change and OK on the warning dialog that follows it.
10) Click the “Exchange Control Panel” tab in the middle frame, open the Properties for the new OWASSO ecp instance and disable all the authentication methods for it as well. OK the changes and the warning dialog that follows.
11) Launch IIS Manager and expand the Default Web Site to see the “owa” application item. Double-click the “Authentication” feature in the middle frame.
12) Enable the Anonymous Authentication type – all other authentication types should remain marked as “Disabled”:
The steps will continue in the next article, part 3 of 4.
Please see this previous article for reasons why you should federate OWA authentication and the high level technologies that are stitched together to accomplish it. This article four-part article is different from OWA 2010 RTM federation because the default “owa” folder on the IIS website cannot be changed to allow anonymous access beginning with Service Pack 1 of Exchange 2010. As such, this article discusses a method that will allow you to establish a “side-by-side” instance of OWA that allows SSO and/or two-factor authentication. It can be used without disrupting access to the standard/base instance of OWA.
Before continuing, I’d like to thank Arshad Masood for his original article on this topic which can be found here. As he states, this method is not officially sanctioned by Microsoft, but it has been proven to work in numerous sites.
Detailed Federation Steps
NOTE: The steps that follow are to be used on an OWA on Exchange 2010 with Service Pack 1 or Service Pack 2. A previous article covers the steps you can use to federate OWA login for 2010 RTM version.
- New static IP for new SSO-enabled OWA website
- Administrative access to Exchange Management Console and OWA front-end server
Windows Identity Foundation
1) Download WIF from here and install it on the OWA Front-End server. The “Instructions” section at the bottom of the download page will help you determine the proper download for your server.
Claims to Windows Token Service
2) Open the following file in a text editor:
C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config
3) Uncomment the line <add value=”NT AUTHORITY\System” /> by removing the brackets around it. This ensures the identity under which OWA runs is allowed to call the service.
4) From an administrator command prompt, run the following command per this Microsoft KB article to add a service dependency:
sc config c2wts depend= CryptSvc
5) In the Services management applet, open “Claims to Windows Token Service”, set the Startup type to “Automatic” and start the service:
The steps will continue in the next article, part 2 of 4.
So the first question to pop into your mind might be: Why should I bother federating OWA? Fair enough. The simple answer is that identity federation brings with it the possibility of goodness like Single Sign-On (SSO) and two factor authentication (2FA). So if you have a project where either of these is on the table for OWA, then federation is your best bet to do it quickly without custom coding. Federation also allows you to enforce authentication actions from a common point which reduces attack surface and standardizes user login procedure which eliminates user training and Help Desk calls. If it’s in scope, providing self-service actions to users also becomes easier when it’s from a single, consistent interface.
Before continuing, I’d like to thank Ken St. Cyr for his original article on this topic which could originally be found here. Unfortunately that site hasn’t been accessible for some time, so hopefully this article will help fill the void left by its absence.
Next Part: How to Federate OWA
Problem: Allow users that are logged into the Corporate LAN access to OWA while disallowing any users that are not on the LAN.
Solution: Configure a client/server installation where the client can present information about itself that will allow the server to decide whether or not to grant access.
Contextual Based Authentication (CBA) is an authentication method that puts more leverage in the server’s hands on how to present a user with authentication. Depending on information that the server gets from the user during the initial access to the protected resource, the server can choose one of a number of authentication methods to present to the user, including but not limited to: Two Factor, Challenge Questions or simple Password authentication. Depending on what information is provided by the client, the server may even prevent access all together.
This article is a revisit of CBA for OWA and will discuss the access scenarios in more detail as well as introducing additional scenarios.
1. Restricted by IP Address
Users that are logged into the corporate LAN will be issued an IP address upon login that will be from a pre-determined range of IP addresses. This means that an intruder trying to access the LAN will not have an IP address in that range. The IP address of the client trying to gain access is always delivered with the request. If the IP address falls within the pre-determined range, the user is considered to be internal and is allowed to authenticate to OWA. If the IP address is not within the range the user is not allowed to authenticate and access is denied completely.
2. Restricted by GPS Coordinates
Maybe the IP address method does not suit your environment and the only way a person can log into the LAN is to be on site within the Corporate campus. No VPN access is permitted. Users have to be physically located within the campus. Any user’s located outside of the campus are considered intruders and are denied access. More specifically, the GPS coordinates of the center of campus can be determined and recorded. All client devices are programmed to deliver their own GPS coordinates with the request to the server. A user will only be granted access if they present GPS coordinates and they are within a mile of the recorded coordinates locating the center of the campus. Anyone that does not supply GPS coordinates is probably not an employee and anyone that does supply GPS coordinates but are located outside of the defined radius are probably an employee but not accessing the LAN through a qualified channel. In both cases, access is denied.
3. Restricted by Company Issued Device
Opposed to the GPS location scenario would be allowing users to access your server from anywhere in the world. The stipulation would be that they must be connecting through a company issued device. All company devices would be issued with software that delivers the MAC address of the machine. Of course, before the device is issued to the employee, the MAC address is recorded. Now whenever access is attempted, unless you have a machine that can deliver a known MAC address with the request, you will be denied access.
4. Restricted by Group Membership
Now, let’s say that the C-Level employees of Belts-R-Us need special privileges and want access to their OWA mail no matter where or how they are coming into the server. One item that all Belts-R-Us CEOs have in common is that they are a member of the “CLevel” AD group. Before allowing authentication for anyone, the CBA process makes a number of checks on the user’s “context” to decide how and if they should be authenticated. One of the checks is to enumerate all of the AD groups for the would-be user. If one of the groups is the “CLevel” group, then the employee is presented with whatever authentication method has been specified for them and is allowed to login and receive their email. If they do not have membership in the “CLevel” group, access is denied.
5. Restricted by WiFi Security Settings
Some of your users want the ability to access the corporate LAN while traveling, but you are concerned about them coming in over an unsecure WiFi network. You would like to give them this flexibility, but only if the WiFi Network they are using has the proper security configured. With CBA, this is possible. Information about the WiFi network being used is delivered with the “context” information and is used by the protected server to determine whether or not the user will be granted access from that WiFi hot spot. For example, unless the WiFi is not using a form of WEP, TKIP, AES or WPA encryption, the user will be denied access. With this method in place, traveling users will be able to remotely connect from reputable WiFi hot spots.
To learn more about this topic and solutions…
Google Keywords: contextual authentication