In April 2011, I documented our recommendation around utilizing Kerberos authentication for MAPI clients to address scalability limits with NTLM authentication. The solution leverages deploying an Alternate Service Account (ASA) credential so that domain-joined and domain-connected Outlook clients, as well as other MAPI clients, can leverage Kerberos authentication.
Recently, we published guidance on how to enable Kerberos Authentication for Exchange 2013 MAPI clients. While this guidance explains the necessary steps to deploy the ASA credential to Exchange 2013, it does not describe what steps you must take to coexist in Exchange 2010 environment. There are certain steps you must take in order to deploy Kerberos authentication for Exchange 2013 and coexist with Exchange 2010.
As with all configuration changes, we recommend you thoroughly test this in a lab environment that mirrors your production environment.
Step 1 – Deploy Outlook Updates
In order to ensure an Exchange 2013 mailbox utilizing Kerberos authentication can connect via the Outlook client to legacy Public Folders and shared mailboxes hosted on Exchange 2010, the Outlook client must be running the following minimum versions:
- Outlook 2013 Service Pack 1 with the December 2014 Cumulative Update
- Outlook 2010 Service Pack 2 with the January 2015 Cumulative Update
Until you install these Outlook updates, you must not attempt to enable Kerberos authentication within your messaging environment when coexisting with Exchange 2013 and Exchange 2010, otherwise your users will see continuous authentication dialog prompts.
Step 2 – Create a New Alternate Service Account Credential
The RollAlternateserviceAccountCredential.ps1 script cannot deserialize objects and pass them between servers that are different versions. This means the script cannot be used to copy the credentials from an Exchange 2010 server or push the credentials to an Exchange 2010 server. As a result, Exchange 2013 and Exchange 2010 cannot share the same Alternate Service Account (ASA) credential.
The Exchange 2013 ASA has the same requirements that were established with Exchange 2010. Specifically, all computers within the Client Access server array must share the same service account. In addition, any Client Access servers that participate in an unbound namespace or may be activated as part of a datacenter switchover must also share the same service account. In general, it’s sufficient to have a single account per forest, but knowing that 2010 and 2013 can’t share the same ASA, this should lead you to conclude you need one per version, per forest.
You can create a computer account or a user account for the alternate service account. Because a computer account doesn’t allow interactive logon, it may have simpler security policies than a user account and is therefore the preferred solution for the ASA credential. If you create a computer account, the password doesn't actually expire, but we still recommend that you update the password periodically. The local group policy can specify a maximum account age for computer accounts and in some customer environments scripts are utilized on a scheduled basis to periodically delete computer accounts that don’t meet current policies. To ensure that your computer accounts aren't deleted for not meeting local policy, update the password for computer accounts periodically. Your local security policy will determine when the password must be changed.
Step 3 – Remove HTTP Service Principal Names from Exchange 2010 ASA
At this point you will be required to schedule an outage for your user population. If you do not, internal users may experience authentication dialogs while attempting to connect to HTTP resources (e.g., Autodiscover, OAB downloads) within Outlook.
If you followed our guidance for Exchange 2010, you have at least the following Service Principal Name (SPN) records associated with the Exchange 2010 ASA:
- http/mail.corp.contoso.com
- http/autod.corp.contoso.com
- exchangeMDB/outlook.corp.contoso.com
- exchangeRFR/outlook.corp.contoso.com
- exchangeAB/outlook.corp.contoso.com
The Exchange 2010 ASA will continue to retain the exchangeMDB, ExchangeRFR, and ExchangeAB SPN records, but will lose the HTTP records as they will move to the Exchange 2013 ASA.
Use the following steps to remove the HTTP SPNs:
- Obtain the HTTP sessions you need to remove from the Exchange 2010 ASA:
setspn –F <domain\E2010ASA$>
- For each HTTP record that needs to be removed, execute the following:
setspn –D http/<record> <domain\E2010ASA$>
Step 4 – Deploy ASA to Exchange 2013 Client Access Servers
To enable deployment of the ASA credential, the RollAlternateServiceAccountPassword.ps1 has been updated to support Exchange 2013. You need to run this script from CU7 or later. The script is located in the Scripts directory.
For more information on how to use the script, please see the section “Configure and then verify configuration of the ASA credential on each Client Access server” in the article Configuring Kerberos authentication for load-balanced Client Access servers.
Step 5 – Assign the Service Principal Names to the Exchange 2013 ASA
Now that the ASA has been deployed to the Exchange 2013 Client Access servers, you can assign the SPNs using the following command:
setspn –S http/<record> <domain\E2013ASA$>
Step 6 – Enable Kerberos Authentication for Outlook clients
By default, Kerberos authentication is not enabled for internal clients in Exchange 2013.
To enable Kerberos authentication for Outlook Anywhere clients, run the following command against each Exchange 2013 Client Access server:
Get-OutlookAnywhere -server <server> | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
To enable Kerberos authentication for MAPI over HTTP clients, run the following against each Exchange 2013 Client Access server:
Get-MapiVirtualDirectory -Server <server> | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm, Negotiate
Once you confirm the changes have replicated across Active Directory and verified Outlook clients have connected using Kerberos authentication (which you can determine via the HTTPProxy logs on the server and klist on the client), the scheduled outage is effectively over.
Summary
Exchange 2010 and Exchange 2013 coexistence requires each version to have a unique ASA credential in order to support Kerberos authentication with MAPI clients. In addition, Outlook client updates are required to support all coexistence scenarios.
For more information, including information on how to plan what SPNs you should deploy with your ASA credential, see Configuring Kerberos Authentication for Load-Balanced Client Access Servers.
Principal Program Manager
Office 365 Customer Experience