In previous posts, we have discussed certificate based authentication (CBA) for Outlook Web App, and Greg Taylor has covered publishing Outlook Web App and Exchange ActiveSync (EAS) with certificate based authentication using ForeFront TMG in this whitepaper. Certificate based authentication for OWA only can also be accomplished using ForeFront Unified Access Gateway.

In this post, we will discuss how to configure CBA for EAS for Exchange 2010 in deployments without TMG or UAG.

To recap some of the common questions administrators and IT decision-makers have regarding CBA:

What is certificate based authentication? CBA uses a user certificate to authenticate the user/client (in this case, to access EAS). The certificate is used in place of the user entering credentials into their device.

What certificate based authentication is not:
By itself, CBA is not two-factor authentication. Two-factor authentication is authentication based on something you have plus something you know. CBA is only based on something you have.

However, when combined with an Exchange ActiveSync policy that requires a device PIN, it could be considered two-factor authentication.

Why would I want certificate based authentication?
By deploying certificate based authentication, administrators gain more control over who can use EAS. If users are required to obtain a certificate for EAS access, and the administrator controls certificate issuance, access control is assured.

Another advantage: Because we're not using the password for authentication, password changes don't impact device access. There will be no interruption in service for EAS users when the they change their password.

Things to remember:
There will be added administration overhead. You will either need to stand up your own internal Public Key Infrastructure (PKI) using Active Directory Certificate Services (AD CS, formerly Windows Server Certificate Services) or a 3rd-party PKI solution, or you will have to purchase certificates for your EAS users from a public certification authority (CA). This will not be a one-time added overhead. Certificates expire, and when a user’s certificate expires, they will need a new one, requiring either time invested in getting the user a new certificate, or budget invested in purchasing one.

Prerequisites:

You need access to a CA for client certificates. This can be a public CA solution, individual certificates from a vendor, or an Active Directory Certificate Services solution. Regardless, the following requirements must be met:

The user certificate must be issued for client authentication. The default User template from an AD CS server will work in this scenario.

The User Principal Name (UPN) for each user account must match the Subject Name field in the user's certificate.

All servers must trust the entire CAtrust chain. This chain includes the root CA certificate and any intermediate CA certificates. These certificates should be installed on all servers that may require them, to include (but not limited to) ISA/TMG/UAG server(s) and the Client Access Server (CAS).

The root CA certificate must be in the Trusted Root Certification Authorities store, and any intermediate CA certificates in the intermediate store on all of these systems. The root CA certificate, and intermediate CA certificates must also be installed on the EAS device.

The user’s certificate must be associated with the user’s account in Active Directory

In IIS manager open the configuration editor under the Microsoft-Server-ActiveSync directory.

Browse the option for clientCertificateMappingAuth and set the value to True

Once this is configured, all that's left to do is client configuration.

Client Configuration

You'll need to get the user’s certificate to the device. This will be accomplished in different ways for different devices. Some possibilities include:

Make the Trusted Root Certification Authority (Root CA) certificate available on a web site or other means of distribution.

Make the user’s certificate, including the private key, available on a website or other means of distribution.

Caution: Use appropriate security measures to ensure that only the user who owns the certificate is able to access it from the device.

If the device supports external storage, you can place the certificate on a memory card or other external storage device and install it from the card.

Some devices have a certificate manager available for a host operating system. You can plug the device into your computer, run the certificate manager and install the certificate.

Once the certificate is on the device, the user can configure the Exchange ActiveSync client (usually a mail app) on the device. When configuring EAS for the first time, users will be required to enter their credentials. When the device communicates with the Client Access Server for the first time, users will be prompted to select their certificate. After this is configured, if users check the account properties, they'll see a message similar to the following:

Microsoft Exchange uses certificates to authenticate users when they log on. (A user name and password is not required.)

Exchange Server 2003 Mailbox Coexistence

This is an added step that requires some simple changes, and must be performed whether TMG is used to access Exchange 2010 or not. Use the following steps to enable this for access to Exchange 2003 mailboxes.

Apply the hotfix from the following article (or one that has a later version of EXADMIN.DLL) to the Exchange 2003 servers where the mailboxes are homed.937031 Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server

The article instructs you to run a command to configure IIS to support both Kerberos and NTLM. You must run the command the command prompt using CSCRIPT, as shown below:

Could you please confirm that on iOS, Windows Phone 7 and Windows 8 Phone, it is not possible to setup multiple mail profiles on a single device using certificate-based authentication. i.e. it is not possible for me to access both my normal mail account, and a support account.

I have tried this and sure it works. What I found problematic was customers with a broad difference in mobile devices (iPhone, Android, Windows Phone) and the problem was to get the actual certificate issued to the devices. Anyone else who has tried this and seen that some devices are easier to manage than others? Without the need to implement a proper Mobile Device Management application.

Good article, however the SPN to add for the Exchange 2003 server is "HTTP/serverFQDN", not "http://serverFQDN&quot;. You may also consider adding the shortname as it's a common practice even though probably not required.

In the article you mention that UAG also supports CBA for ActiveSync. Has something changed? UAG doesnt currently support CBA for EAS – Is this functionality being added in the Service Pack 3 for UAG release?

It seems that in our testing the cert does not have to be published back to the user account, only the Subject / SAN name have to include the email address. We have an MDM pushing the Cert with SCEP/NDES and it writes all the certs back to the MDM's account. So it looks like it doesn't matter which account it is written back to. Does that seem like a security flaw? or am I over thinking it?