Update: Exchange Server 2013 Cumulative Update 5 and later supports certificate-based authentication with ActiveSync.
Note: For official documentation on this subject, please go to this page on TechNet.
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:
- 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 CA trust 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
Client Access Server Configuration
To configure the Client Access server to enforce CBA:
1. Verify if Certificate Mapping Authentication is installed on the server.
- Right click on Computer in the start menu and choose Manage.
- Expand Roles and click on Web Server (IIS)
- Scroll down to the Role Services section. Under the Security section you should see Client Certificate Mapping Authentication installed.
- If you don’t see Client Certificate Mapping Authentication installed, click add Role Services > (scroll) Security and select Client Certificate Mapping Authentication and then click Install.
- Reboot your server.
2. Enable Active Directory Client Certificate Authentication for the server root in IIS.
- Start IIS Manager
- Click on the Server Name.
- Double click Authenticationin the middle pane.
- Right click on Active Directory Client Certificate Authentication and select Enable
- When this is complete, restart the IIS Admin service from the Services console (or use Restart-Service IISAdmin”from the Shell).
Important: IISreset does not pick up the changes properly. You must restart this service.
3. Require Client Certificates in Exchange management console.
- In the Exchange Management Console, expand Server Configuration and then select the Client Access server you want to configure
- On the Exchange ActiveSync tab, right click on the Microsoft-Server-ActiveSync directory and choose Properties.
- On the Authenticationtab:
4. Modify the ActiveSync XML configuration file to allow Client Certificate Mapping Authentication.
- 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.
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:
- Click Start > Run > type cmd and press Enter.
- Type cd \Windows\System32\AdminScripts and press Enter.
- Type the following command and press enter:
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders “Negotiate,NTLM”
- On the Exchange 2003 mailbox server, launch Exchange System Manager and follow these steps:
- Expand the Administrative Group that contains the Exchange 2003 server.
- Expand Servers > expand <server name> > Protocols > HTTP Exchange Virtual Server
- Right click the Microsoft-Server-ActiveSync virtual directory and select Properties
- On the Access tab, click Authentication and ensure that only Integrated Windows Authentication checkbox is checked.
- Use the following steps to configure the Exchange 2010 to Exchange 2003 communication for Kerberos Constrained Delegation (KCD).
- Open Active Directory Users and Computers on the CAS
- Right click the CAS computer account > Properties
- In the Delegation tab, select Trust this computer for delegation to specified services only
- Select Use any authentication protocol option and then click Add
- In the Add Services window, click Users or Computers and enter the name of the Exchange 2003 server that the CAS is delegating to
- Click OK
- A list of Service Principal Names (SPN) will be displayed for your server.
- Select the appropriate HTTP SPN for the Exchange 2003 server. You’ll need to add the correct SPN, HTTP/serverFQDN
Note: You may need to add the SPN as per Setspn Overview
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.