Note: Exchange Server 2013 Cumulative Update 5 and later supports certificate-based authentication with ActiveSync.
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.
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:
To configure the Client Access server to enforce CBA:
Important: IISreset does not pick up the changes properly. You must restart this service.
Once this is configured, all that's left to do is 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:
Caution: Use appropriate security measures to ensure that only the user who owns the certificate is able to access it from the device.
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.)
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:
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders "Negotiate,NTLM"
On the Exchange 2003 mailbox server, launch Exchange System Manager and follow these steps:
Use the following steps to configure the Exchange 2010 to Exchange 2003 communication for Kerberos Constrained Delegation (KCD).
Note: You may need to add the SPN as per Setspn Overview
Thanks to: DJ Ball for his previous work in documenting certificate based authentication for Outlook Web App (see How to Configure Certificate Based Authentication for OWA - Part I and How to Configure Certificate Based Authentication for OWA - Part II Mattias Lundgren, for starting the documentation process on certificate based authentication for EAS. DJ Ball and Will Duff for reviewing this document. Henning Peterson and Craig Robicheaux for reviewing this document. Greg Taylor for technical review.