Enabling Kerberos Authentication for MAPI Clients Connecting to Exchange 2010 SP1

Introduction

When Exchange 2010 SP1 RTW’d back in August 2010, one of the things that the Exchange Product group had spent a fair amount of resources on getting into the product was a feature that made it possible for MAPI clients (usually internal Outlook clients) to connect to a load balanced CAS array to be able to authenticate with Exchange using Kerberos authentication. Previous versions of Exchange server supported Kerberos authentication since the MAPI clients connected to the mailbox server FQDN and not a FQDN pointing at a load balancer in front of a CAS array. With Exchange 2010 RTM, there was no way for MAPI clients to authenticate using Kerberos authentication.

In this article, I’ll provide you with the steps necessary to enable Kerberos authentication for MAPI clients. I’ll use the lab environment which also was used as the basis for the Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization article series. Some of you will probably wonder why this topic wasn’t included in the series. There’s a good reason for this. It’s because the Exchange Product group just recently stated publically that they recommend all customers that either have a load balanced CAS array or even a non-load balanced CAS array with the CAS array DNS object pointing to the IP address of an Exchange 2010 CAS server to enable Kerberos authentication. The reason for this sudden recommendation is because the Exchange Product group, in some customer environments, has seen some pretty serious performance issues caused by the fact that MAPI clients authenticated using NTLM and not Kerberos.

What is Kerberos Authentication and why Enable this Authentication Mechanism?

Since this is already well explained in this blog post on the MS Exchange Team blog as well as in the core Exchange 2010 TechNet documentation, I won’t spend time explaining this. Instead, I recommend you visit those two references in order to get up to speed on Kerberos authentication. When done, come back here and read on.

Why Enable Kerberos Authentication for MAPI Clients?

The reason why this is recommended is because you can hit some rather significant performance issues when using NTLM authentication. If you haven’t already done so, read this blog post on the MS Exchange Team blog and come back to this article when you’re ready to set up Kerberos authentication in your environment.

The Environment Used in this Article

I know you’re eager to get this Kerberos stuff enabled but before we move on, here’s a quick overview of the environment in which we’re going to enable Kerberos authentication. This is important in order to understand which Service Principal Names (SPNs) should be registered and how you should go about enabling Kerberos authentication on the Client Access servers in the environment.

So we have an environment consisting of two physical locations (datacenters). At site 1 we have the following:

• 1 Active Directory site (Datacenter-1)
• 2 Domain Controllers (one of which acts as witness server)
• 2 Exchange 2010 Multi-role servers
• 2 physical load balancers
• 1 CAS array (outlook-1.exchangeonline.dk)

At site 2 we have the following:

• 1 Active Directory site (Datacenter-2)
• 2 Domain Controllers (one acting as alternate witness server)
• 2 Exchange 2010 Multi-role servers
• 2 physical load balancers
• 1 CAS array (outlook-2.exchangeonline.dk)

In addition, we have one database availability group (DAG) stretched between the two AD sites. All active users connect to site 1 unless a partial or full switchover occurs for planned or unplanned reasons.

The primary namespace is mail.exchangeonline.dk and points to site 1. The secondary namespace is failover.exchangeonline.dk and points to site 2.

The environment is depicted in the diagram shown in Figure 1. The namespaces used in each site are also included.

Figure 1:
Environment used in this article

The load balancer in each datacenter has been configured as shown in Figure 2.

Figure 2: Load Balancer Configuration

Creating the Alternate Service Account

In order to enable Kerberos authentication for MAPI clients, Exchange 2010 needs to leverage an Alternate Service Account (ASA) credential mechanism. To archive this, the first step is to create a service account in the Active Directory domain. In theory, this can be a user account or a computer account. For security reasons, the recommendation is to use a computer account.

In general, all Client Access servers in a CAS array should share the same service account. If we have two datacenters (each with their own CAS array) we should use the same service account for all CAS servers belonging to one of these CAS arrays. The reason for this has to do with switchover situations where Outlook clients are updated to connect to the CAS array in the failover datacenter.

To create the computer account open the “Active Directory Users and Computers” MMC snap-in. If you already have an organizational unit (OU) dedicated to service accounts, you might need to create the computer account in this OU. Right-click on the OU and then select New > Computer in the context menu.

Figure 3: Creating the Computer Account

Give the computer account a meaningful name and leave the defaults. Click “OK”.

Figure 4: Creating the ASA Computer Account

By default the new computer account object will be added to the Domain Computers group which is sufficient.

Figure 5: Computer Account is added to the Domain Computers group by default

Important:
Since the computer account we just created is a critical step for the Kerberos authentication to work, it’s important that it isn’t deleted. A common policy used in customer environments is to implement a policy that that deletes all accounts that haven’t had their password changed within N number of days.

Deploying Alternate Service Account Credential to the Client Access Servers

It’s time to deploy the Alternate Service Account (ASA) credential to the Client Access Servers member servers in each CAS array. To do so, log on to an Exchange 2010 server and launch the Exchange Management Shell. In the Exchange Management Shell navigate to the Exchange Scripts folder which is located under “C:\Program Files\Microsoft\Exchange Server\V14\Scripts”. In this folder, you’ll see a PowerShell script named RollAlternateServiceAccountPassword.ps1.

Figure 6: RollAlternateServiceAccountPassword.ps1 Script

Depending on whether you have multiple CAS arrays or not, the command we’re going to execute differs. If you have a single CAS array, you would use the following command:

.\RollAlternateServiceAccountPassword.ps1 –ToArrayMembers <CAS array FQDN> -GenerateNewPasswordFor domain\computeraccount$

If I only wanted to enable Kerberos authentication for the CAS array at site 1, I would use this command:

.\RollAlternateServiceAccountPassword.ps1 –ToArrayMembers outlook-1.exchangeonline.dk –GenerateNewPasswordFor Exchangeonline.dk\ExchangeASA$

As can be seen in Figure 7, this will push the ASA credentials to all the CAS servers in the specified CAS array as well as change the password of the ASA computer account.

Figure 7: Running the script against a specific CAS array

But since this environment includes two CAS arrays, I would either use the following command:

.\RollAlternateServiceAccountPassword.ps1 –ToEntireForest –GenerateNewPasswordFor Exchangeonline.dk\ExchangeASA$

Or:

.\RollAlternateServiceAccountPassword.ps1 –ToSpecificServers EX01,EX02,EX03,EX04 –GenerateNewPasswordFor Exchangeonline.dk\ExchangeASA$

To verify that the ASA credentials have been deployed properly use the following command:

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

Figure 8: Verifying the ASA credentials have been deployed to the CAS servers

Converting OAB Virtual Directory to a Web Application

By default, the OAB virtual directory is not a web application so in order to use Kerberos authentication for the OAB vdir, it must be converted to a web application. This can be done using this script developed by the Exchange Product group. You simple execute it in the Exchange Management Shell on each CAS server that had the ASA credentials deployed.

Figure 9: Converting the OAB vdir to a web application

Assigning Service Principal Names with ASA Account Credential

Now we will need to have the relevant Service Principal Names (SPNs) assigned to the ASA credential account. We’ll need to register the following:

• http (EWS, OAB and Autodiscover)
• exchangeMDB (RPC CA service)
• exchangeRFR (Address Book service)
• exchangeAB (Address Book service)

As mentioned earlier, we use the following FQDNs for Exchange CAS services in this environment:

• Mail.exchangeonline.dk
• Failover.exchangeonline.dk
• Outlook-1.exchangeonline.dk
• Outlook-2.exchangeonline.dk

Note:

For internal autodiscover, we use mail.exchangeonline.dk as the URL/FQDN. If you use autodiscover.domain.com as the URL/FQDN, you must also assign this URL/FQDN with the ASA credential account.

To assign the relevant SPNs, we need to launch the following commands:

Setspn –S exchangeMDB/outlook-1.exchangeonline.dk exchangeonline\ExchangeASA$

Setspn –S exchangeMDB/outlook-2.exchangeonline.dk exchangeonline\ExchangeASA$

Setspn –S exchangeRFR/outlook-1.exchangeonline.dk exchangeonline\ExchangeASA$

Setspn –S exchangeRFR/outlook-2.exchangeonline.dk exchangeonline\ExchangeASA$

Setspn –S exchangeAB/outlook-1.exchangeonline.dk exchangeonline\ExchangeASA$

Setspn –S exchangeAB/outlook-2.exchangeonline.dk exchangeonline\ExchangeASA$

Setspn –S http/mail.exchangeonline.dk exchangeonline\ExchangeASA$

Setspn –S http/failover.exchangeonline.dk exchangeonline\ExchangeASA$

Figure 10: Registering relevant SPNs

To verify all relevant SPNs have been assigned properly, run the following command:

Setspn –L Exchangeonlineonline.dk\ExchangeASA

Figure 11: Assigned SPNs

Verifying MAPI Clients are Using Kerberos Authentication

We have now gone through the steps necessary to enable Kerberos authentication. It wasn’t that bad was it? Now we just need to verify that the MAPI (Outlook) clients are using/can use Kerberos. Before we do that, I recommend you restart the Exchange Address Book Service and the Exchange RPC Client Access Service on each CAS server.

Be aware that the client may get the infamous: “Administrator has made changes…” message after you enable Kerberos authentication in the environment. Needless to say, you should communicate this to the end users prior to enabling Kerberos authentication.

Figure 12: The infamous Exchange administrator has made changes warning

Now open the properties of an Outlook profile. Navigate to “More Settings” and then click on the “Security” tab. By default Outlook 2003/2007/2010 clients are set to negotiate authentication. This means that if Kerberos authentication isn’t enabled on Exchange 2010 CAS servers, the clients will failover to NTLM.

Change the Logon network security settings to “Kerberos Password Authentication”. Then close the Outlook profile.

Figure 13: Outlook Logon network security settings

Now launch Outlook. In Outlook open the Connection Status window and check whether Outlook is connecting using TCP/IP or HTTPS. If it uses the latter, Outlook has failed over to using HTTPS because Kerberos isn’t working as expected.

Figure 14: Outlook Connection Status window

If Outlook connects using TCP/IP, it looks like things work as expected. To be sure Outlook has authenticated using Kerberos, open a command prompt on the client (in non-administrator mode) and type:

Klist.exe

This will list all the service tickets currently used on the client. Here you should see something like Figure 15. Here we can see that the SPNs we registered are being used to authenticate against Exchange.

Figure 15: Service Tickets on the Client Machine

Periodically Changing the Password for the ASA Credential Account

It’s recommended to periodically change the password for the ASA credential account. To do so you would need to create a scheduled task that runs the RollAlternateServiceAccountPassword.ps1 script. For more info check the Exchange 2010 TechNet documentation.