Introduction

Recently, I got to a customer that wanted to protect access to Outlook Web App (OWA) with more than just the credentials of the user. At that moment they had already considered other options like using a token (e.g. RSA) or integrating a captcha on the OWA login form. However, these options required them to obtain additional licenses and products and was not really an option.

Although my first choice would have been to use a TMG, I had to look for alternatives and could come up with one that was relatively simple yet very effective: client certificates.

Client Certificates

Since OWA is basically a web page that is published through IIS you can easily protect the server, website or separate virtual directories using client certificates. If you enable the option, users/devices who are not able to “provide” a valid certificate will be denied access.

The solution based on client certificates requires you to have already deployed the following components (if not, you will have to deploy them):

• Internal PKI
• (automated) way of ‘pushing’ these certificates to the clients (preferably GPO).

Note: clients can also manually request the certificate if you use web enrollment on your internal CA.

There are some great resources on TechNet that explain and show how to setup such an infrastructure:

• http://technet.microsoft.com/en-us/library/bb694041.aspx
• http://technet.microsoft.com/en-us/library/cc731242(WS.10).aspx

How does it work?

The principle behind Client certificate authentication is relatively simple and works in pretty much the same way as a web server proving it’s identity to client computers.
The internal root CA will generate a unique certificate for each computer/user. That certificate gets installed on the client’s computer. Upon authentication, the client will present that certificate to the web server. If the server can validate the certificate the computer will be granted access to the resource. In order for the web server to accept and check the validity of the certificate that is presented, it should trust the CA that created the certificate. Since our Exchange server is also a domain-joined computer, it will also trust the internal CA and is therefore able to check/validate the certificates presented by the clients. Alternatively, you can also use public SSL certificates, bought from a trusted third party CA:

1. The internal CA creates a certificate and also stores information about the certificate in Active Directory (maps certificate to a user).

2. The client stores this certificate in its local store.

3. Upon connection to the resource (OWA), the server will request the clients’ certificate after which the client will present the certificate that was stored locally earlier.

4. The web server (CAS) will lookup the client certificate to confirm it’s validity. If confirmed, the client is granted access.

Configuring IIS7

Assuming that your Exchange 2010 (SP1) is installed on a Windows Server 2008 R2, here are the steps that you need to take to configure certificate based authentication:

1. Open up the IIS Manager and navigate to the server node. Click ‘Authentication’ and enable Active Directory Client Certificate Authentication.

2. Navigate to the virtual directories you want to protect and double click ‘SSL Settings’. In this example, we’ll use OWA and ECP:

3. From within the SSL Settings windows, click “Require” under Client certificates:

Repeat steps 2 and 3 for each virtual directory you want to protect.

4. Run an ‘iisreset /noforce’ to apply the settings:

Authentication

We still need to configure the type of authentication we want to use in combination with the client certificates. If you don’t want your users to type in a password at all, you could enable Integrated Windows Authentication by running the following cmdlet from the Exchange Management Shell:

Or, if you still want forms based authentication:

Note: Make sure that you disable authentication methods you don’t want to be available.

By going to the authentication-options of the virtual directory (in the IIS manager), you can review what authentication options have been enabled:

Client experience

In the scenario that the user’s computer has got no client certificate, the following warning/error will be displayed:

However, if the client computer has a certificate stored, the user will be prompted to select the a certificate:

After selecting the appropriate certificate, the user will be transferred to the login page (in case FBA is enabled):

From there, users can continue by providing their credentials and logging in into OWA.