Synopsis

Multiple ActiveSync virtual directories with the added complication of Certificate Based Authentication on Exchange 2007 environment causes issues when upgrading to Exchange 2013 coexistence.

The Scenario

An Exchange 2007 environment with two ActiveSync Virtual directories load balanced as separate pools across all CAS servers:

  1. Generic ActiveSync access for “ordinary” devices, Basic Authentication, using the default Exchange web site and virtual directory, the namespace “generic.customer.com” and the base IP address of the server bound to it.
  2. Certificate based ActiveSync access for managed devices, Certificate Authentication, using a new Exchange website and virtual directory, the namespace “cert.customer.com”, and a discrete IP.

When Exchange 2013 is introduced to this environment, in the same Active Directory site, the Exchange 2007 virtual directories are changed to the namespace “legacygeneric.customer.com” and “legacycert.customer.com”, and the original names moved to the Exchange 2013 virtual directories, there are two problems:

  1. Certificate based authentication does not work at all.
  2. Generic ActiveSync access is sporadic and occasionally fails.

Issue 1 is due to the background requirements to configure Certificate Based Authentication. We can assume that, as Certificate based authentication was working fine in Exchange 2007 that the user, Active Directory and Certificate configuration is correct and move on to looking into the Exchange configuration:

  1. Verify “Client Certificate Mapping Authentication” and “IIS Client Certificate Mapping Authentication” Role Services are installed.
  2. Enable Active Directory Client Certificate Authentication at the server root in IIS (restart of IIS require).
  3. Make sure the ActiveSync virtual directory (in this instance, the new one not the default) is configured to Require Client Certificates.
  4. Modify the ActiveSync virtual directory XML configuration to set the “system.webServer.security.authentication.clientCertificateMappingAuth” to “True”.

However, in our scenario this results only in sporadic access for Certificated Based Authentication devices in the same manner as generic ActiveSync. Why is this?

The Why

When a user whose mailbox resides on a legacy Exchange 2007 connects via ActiveSync to an Exchange 2013 server, the Exchange server authenticates the user, then does a service discovery and proxies the request on to the namespace of the service is locates (Exchange 2013 no longer supports the HTTP redirect method and will always proxy this traffic). The namespace located by the service discovery is the InternalUrl value of the Microsoft-Server-ActiveSync virtual directory on any Exchange 2007 CAS server in the same site as the mailbox.

This is where the above scenario breaks down.

As there are two namespaces in the legacy environment (legacygeneric.customer.com and legacycert.customer.com) whenever a discovery is made for Exchange 2007 ActiveSync virtual directory namespaces in Exchange 2007 there is an equal (50%) chance of either namespace being returned. When the request returns legacycert.customer.com the Exchange 2013 server will attempt to authenticate against Exchange 2007, but because Certificate Based Authentication is configured here, it will fail and the end-to-end session will also fail. Sadly, the ActiveSync device will report this as a failure to log in to the Exchange 2013 server, which is rather misleading.

The Resolution

Exchange should only have one namespace per service per site (per version of Exchange in a coexistence scenario, with the exception of Outlook Anywhere, but that’s another blog), so to resolve this issue, either:

  1. Delete the Exchange 2007 Certificated Based Authentication ActiveSync virtual directory, or if you are concerned that this will not allow for a seamless roll back;
  2. Change the namespace of the Exchange 2007 Certificate Based Authentication ActiveSync virtual directory to match that of the Exchange 2007 default ActiveSync virtual directory. This will result in traffic being sent on to the correct URL (and therefore load balanced pool, ending up at the correct ActiveSync virtual directory IP) regardless of which virtual directory is chosen. Be aware that in my experience, should rollback be needed, any changes to the configuration of the Certificate Based Authentication virtual directory will wipe the XML change made above, and this will need to be reimplemented before authentication will work as expected.

About the author