Implement VMware AirWatch Certificate Authentication for Exchange ActiveSync with Secure Email Gateway: Exchange 2013 Edition

By far, this is the most challenging component to implement as part of our AirWatch infrastructure. The concept of leveraging certificate-based authentication over username and password to improve user’s experience is noble, however, the process to the finish line is not for the faint of heart. The same complexity can be seen in other MDM providers as well such as Blackberry UEM (you can check out my post on that setup by clicking here.)

I do, however, praise VMware AirWatch for continuous improvement in its documentation on this setup via the post below over the years. More importantly, the diagram below explains the interaction between various components during the authentication process at a high level.

VMware AirWatch Certificate Authentication for EAS with SEG

SEGwithKCD1.jpg

This set up was based on SEG classic with Kerberos Constrained Delegation (KCD) in an Exchange 2013 environment with two or more CAS. The steps should be more or less the same for Exchange 2016 environment as well. Keep in mind, however, support for SEG classic will end in May 2019. Customers are encouraged to upgrade to V2 soon, and you can read my post on the upgrade process here.

Before we begin, let’s take a look at the list of prerequisites for this setup:

  • An internal certificate authority (CA) which can be Microsoft or others. External CA, however, is not supported.
  • Certificate Authorities section under GROUPS & SETTINGS -> All Settings -> System -> Enterprise Integration properly configured (see screenshots below)
  • A working Secure Email Gateway (SEG) within the same domain as the CA.
  • A device profile configured with both Exchange ActiveSync (EAS) and certificate from CA to be published to devices within the AirWatch web console.

SEGwithKCD30.jpg

SEGwithKCD31.jpg

SEGwithKCD32.jpg

SEGwithKCD33.jpg

SEGwithKCD34.jpg

The guide mentioned earlier describes completing the major steps in the order listed below. You may require additional setup depending on your Microsoft Exchange infrastructure especially with multiple CAS.

  1. Identify and register the specific service that Secure Email Gateway (SEG) will delegate traffic to Exchange ActiveSync (EAS) server.
    1. Create alternative service account (ASA) first if you have multiple client access servers (CAS). Only then, complete step b below
    2. Otherwise, create Service Principal Name (SPN)
  2. Configure security settings of SEG (computer account) in Active Directory (AD) to impersonate user for authentication on the EAS server.
    1. Configure AD to give permission to SEG to impersonate a user
    2. Enable SEG to delegate HTTP EAS traffic to EAS server
  3. Enable “Windows Authentication” in EAS server to accept and analyze Kerberos ticket received from SEG
  4. Configure SEG to authenticate user’s device assigned with a certificate
    1. Configure IIS to accept the certificate
  5. Enable SEG EAS service account to start granting access to EAS server through user impersonation
    1. Verify identity in IIS
    2. Configure local security policy for SEG
      1. to act as part of the OS
      2. to impersonate a client after authentication

Step 1: Identify and register the specific service that Secure Email Gateway (SEG) will delegate traffic to Exchange ActiveSync (EAS) server.

In my Exchange environment, I do have multiple client access servers. Thus, I need to create an alternative service account (ASA) first to represent all of my CAS. Be sure to enable the AES256 encryption cipher for encrypting Kerberos traffic.

Set-ADComputer <domain\ASA> -add @{msDS-SupportedEncryptionTypes”=”28″}

Step 1 of the guide from AirWatch tells you to verify the CAS’s FQDN after creating the ASA and then create the SPN for it. However, this is INCORRECT, especially if you have two or more CAS in your environment (and hence we created an ASA earlier).

First of all, there’s no CAS array starting with Exchange 2013.

SEGwithKCD2.jpg

Second, Microsoft documentation clearly advises not to associate SPN with an ASA account until you have deployed credential to at least one Exchange server.

SEGwithKCD3.jpg

Instead, start by deploying the ASA Credential to the first Exchange 2013 Client Access server.

  • Open the Exchange Management Shell on an Exchange 2013 server.
  • Change directories to <Exchange 2013 installation directory>\V15\Scripts.
  • Run the following command to deploy the ASA credential to the first Exchange 2013 Client Access server:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer FQDN_of_1st_CAS -GenerateNewPasswordFor DOMAIN\ASA_Account$ -Verbose

  • When you’re asked if you want to change the password for the alternate service account, answer Yes.

SEGwithKCD4.jpg

SEGwithKCD5.jpg

Continue and deploy the ASA credential to remaining Exchange 2013 Client Access servers

  • Open the Exchange Management Shell on an Exchange 2013 server.
  • Change directories to <Exchange 2013 installation directory>\V15\Scripts.
  • Run the following command to deploy the ASA credential to another Exchange 2013 Client Access server:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer FQDN_of_Additional_CAS -CopyFrom FQDN_of_1st_CAS –Verbose

Below are screenshots when deploying the ASA credential to remaining Exchange 2013 Client Access servers.

SEGwithKCD6

SEGwithKCD7.jpg

  • Verify the deployment of the ASA credential
    • Open the Exchange Management Shell on an Exchange 2013 server.
    • Run the following command to check the settings on a Client Access server:

Get-ClientAccessServer CAS_Hostname -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration

  • Repeat the step above on each Client Access server where you want to verify the deployment of the ASA credential.

SEGwithKCD8

Now we are ready to create the SPN (Service Principal Name) from any domain controller. Hang in there!

Couple pointers to keep in mind for this step:

  • In order for the SEG server to be able to delegate traffic to a specific service, we need to identify and register the service. This can be accomplished by creating the SPN (Service Principal Name).
  • The target service should match the Exchange server Hostname on the “web.config” file of the “Web Listener” folder on SEG. The “SETSPN” command is used to register the service and this can be executed on the AD server or EAS server
  • If GSLB is configured with your load balancer, such as Citrix Netscaler, you will need to append an additional SPN (i.e. mail.gslb.domain.com) to the ASA. Otherwise, authentication will fail when the SEG resolves from mail.domain.com to mail.gslb.domain.com.

Verify an SPN is not already associated with an account in a forest by running the setspn command.

SEGwithKCD9.jpg

Then, run setspn –s http/Your_Webmail_URL DOMAIN\ASA$ (is $ really necessary?). Afterward, verify by running setspn –L ASA$

*You only need to run this command once even if you have multiple CAS.

SEGKCD20.jpg

Step 2: Configure security settings of SEG (computer account) in Active Directory (AD) to impersonate user for authentication on the EAS server

Couple pointers to keep in mind for this step:

  • By default, no infrastructure is permitted to grant access to other servers using Kerberos delegation. Therefore, administrators must first configure security settings on the directory server so that the SEG server can delegate access to the EAS server using HTTP (for EAS traffic).
  • Specifically for Microsoft Active Directory infrastructure, this would entail:
    • Configuring AD to give permissions to SEG to impersonate a user (see steps below).
    • Enabling SEG to delegate HTTP EAS traffic to the EAS server.

Here are the steps in detail.

  1. In Active Directory, look up the SEG host and go to Properties
  2. Click on Delegation tab
  3. Select Trust this computer for delegation to specified services only
  4. Select Use any authentication protocol
  5. Click Add
  6. Click Users or Computers on the Add Services window. The Select Users or Computers window displays.
  7. Enter the ASA created earlier and click OK
  8. Select the http service registered earlier (i.e. your webmail URL) and click OK twice

SEGwithKCD11.jpg

SEGwithKCD13.jpg

SEGwithKCD12.jpg

SEGwithKCD14.jpg

Step 3: Enable “Windows Authentication” in EAS server to accept and analyze Kerberos ticket received from SEG

  1. Open IIS manager on the EAS server (not SEG)
  2. On the left-hand Connections pane, expand Sites and select Microsoft-server-ActiveSync
  3. In the main pane, under IIS, select Authentication and enable Windows Authentication

SEGwithKCD15.jpg

SEGwithKCD16.jpg

The steps below are also required if Exchange host returns a 401 error per the same link from AirWatch.

  1. Under the Actions menu on the right side of the page, click Providers and add Negotiate and NTLM to Windows Authentication on Exchange host (pay attention to the order shown below)
  2. Finally, reset IIS!

SEGwithKCD17.jpg

Step 4: Configure SEG to authenticate user’s device assigned with a certificate

  1. Open IIS manager on the SEG server (not EAS)
  2. On the left-hand Connections pane, click on the SEG server. Then, click on Authentication under IIS.
  3. Click on Active Client Certificate Authentication and enable it.

SEGwithKCD19.jpg

SEGwithKCD20.jpg

There are a few more steps within IIS. Let’s continue.

  1. On the left-hand Connections pane, click on the SEG server -> Sites -> Microsoft-Server-ActiveSync. Then, click on Configuration Editor under Management.
  2. Next to Section, browse to system.webServer/security/authentication/clientCertificateMappingAuthentication.
  3. Next to enabled, set it to True and click Apply.

SEGwithKCD21.jpg

SEGwithKCD22.jpg

Since we only allow certificate-based authentication to access email, we will now configure SSL setting to ensure this is enforced.

  1. On the left-hand Connections pane, click on the SEG server -> Sites -> Microsoft-Server-ActiveSync. Then, click on SSL Settings under IIS.
  2. Check off the box Require SSL and select the radio button Require.

SEGwithKCD23.jpg

SEGwithKCD24.jpg

Wait, there’s more before we are done here!

To accommodate the larger amount of data as part of certificate-based authentication, we need to adjust the uploadReadAheadSize value also within IIS. All we need to launch a command prompt and run the commands below.

C:\Windows\System32\inetsrv\appcmd.exe set config “Default Web Site” –
section:system.webServer/serverRuntime /uploadReadAheadSize:”10485760″
/commit:apphost 

* You may replace “Default Web Site” if your site name is different.

iisreset

Step 5: Enable SEG EAS service account to start granting access to EAS server through user impersonation

There are two parts to this process.

Verify identity in IIS

The guide keeps referencing service account which may lead one to believe it needs to be created separately. I was a bit surprised to find that it’s really just another build-in account (i.e Network Service).

  1. On the left-hand Connections pane, click on the SEG server -> Application Pools
  2. Select SecureEmailGateway and confirm the identity is set to NetworkService as shown.

SEGwithKCD25.jpg

Configure local security policy for SEG.

There are two fields we need to add/check.

To act as part of the OS

  1. From the SEG server, launch Local Security Policy.
  2. Browse to Security Settings -> Local Policies -> User Right Assignment
  3. Under Policy, double-click on Act as part of the operating system.
  4. Add or confirm the service account is NETWORK SERVICE

To impersonate a client after authentication

  1. From the SEG server, launch Local Security Policy.
  2. Browse to Security Settings -> Local Policies -> User Right Assignment
  3. Under Policy, double-click on Impersonate a client after authentication.
  4. Add or confirm the service account is NETWORK SERVICE

SEGwithKCD27.jpg

If you haven’t already as part of the prerequisites, create a new or modify an existing mail profile to ensure certificate instead of basic is used for authentication with Exchange for the mailbox access. Then, proceed to publish this mail profile to user’s device and test mail connectivity.

SEGwithKCD28.jpg

SEGwithKCD29.jpg

Once this profile is published to user’s device, you should see the below when navigating to Settings – > General -> Device Management -> Device Manager.

Under More Details -> CERTIFICATES, you should see the user’s certificate issued by your CA.

SEGwithKCD35

Under Accounts, you should see the mail account configured from AirWatch web console.

SEGwithKCD36.jpg

That’s it! Your users will definitely appreciate not having to enter their usernames/passwords on their devices during initial mail profile provisioning or whenever their AD credentials change.

As always, stay mobile!

One comment

Leave a Reply to Steps to migrate Secure Email Gateway (SEG) configured with Kerberos Constrained Delegation (KCD) from Classic Platform to the V2 Platform – Thomas Cheng Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.