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:

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 – Configure Legacy Public Folder Access

As discussed in On-Premises Legacy Public Folder Coexistence for Exchange 2013 CU7 and Beyond, in order for Exchange 2013 mailboxes to access legacy Public Folders correctly, we need to ensure that the legacy Public Folders are discoverable via AutoDiscover.  This enables the Outlook client to perform a second AutoDiscover request using the legacy Public Folder discovery mailbox’s SMTP address, allowing Outlook to use the correct connection endpoint and authentication settings.

For more information on how to configure legacy Public Folder Access, see the Configure legacy public folders where user mailboxes are on Exchange 2013 servers TechNet article.

Step 3 – 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. Also, when using a computer account, you will want to enable the AES256 encryption cipher for encrypting Kerberos traffic:

Set-ADComputer <domain\E2013ASA> -add @{"msDS-SupportedEncryptionTypes"="28"}

Step 4 – 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:

  1. Obtain the HTTP sessions you need to remove from the Exchange 2010 ASA:

    setspn –F <domain\E2010ASA$>

  2. For each HTTP record that needs to be removed, execute the following:

    setspn –D http/<record> <domain\E2010ASA$>

Step 5 – 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 6 – 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 7 – 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.


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.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience


  • 3/11/15: Added section on configuring legacy Public Folder access.
  • 9/28/15: Added guidance on configuring encryption cipher for computer accounts.
Not applicable
@Ross that's strange, because a few weeks ago, the documentation on Technet describes the "enabling" without using the RollAlternateserviceAccountCredential.ps1 and we did that this way.

So we used:

New-ADComputer -Name EXCHGASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCHGASA

and set the credentials with the cmdlet

Set-ClientAccessServer $env:computername -AlternateServiceAccountCredential (Get-Credential)



Not applicable
Interesting, thanks for the article.

This reminded me about an issue I saw recently where the Exchange 2010 version of the script tries to update the ASA on the Exchange 2013 CAS server my customer added to the site. See


Not applicable
I am utilizing Kerberos ASA in my 2010 environment right now. I'm not too surprised that we would need to have two separate ASAs for each infrastructure.

I am curious though, step one states you need to be running more current versions of Outlook and related updates; will this not work properly with 2007?

If 2007 cannot be used properly, what work-arounds exist? Simply disabling Kerberos ASA before beginning the migration to 2013, then re-creating afterwards?

Not applicable
@Jörg von der Ohe - that's why I had the article replaced with the correct steps.
Not applicable
Configuring Kerberos authentication for load-balanced Client Access servers.All Client Access servers that share the same namespaces and URLs need to use the same alternate service account credentials. In general, it's sufficient to have a single account

for a forest for each version of Exchange. alternate service account credential or ASA credential.

Not applicable
In our environment we use the same account for ASA across 2010 and 2013 setting the credential manually on each 2013 server during deployment rather then using the script to roll it. I'm guessing you'll say its unsupported but its definitely works.
Not applicable
@krisasmith - Correct. The only supported method to add the ASA credentials is via the RollAlternateserviceAccountCredential.ps1 script. Any other method to apply the credentials is not supported and sharing an ASA is, therefore, not supported.


Not applicable
@Paul, Outlook 2007 is in extended support and is only receiving security updates at this point in its product support lifecycle. We strongly recommend you test Outlook 2007 in your lab that mimics your production configuration to validate if it continues

to work with this Kerberos config. If you only have Exchange 2013 I do not suspect issues, but you should focus on multi-version testing when there are things like shared mailboxes and legacy public folders still on Exchange 2007 when the mailbox is on Exchange


Not applicable
Hi Ross,

The same issue exist with Office 365 in Hybrid scenarios. Do you have a solution for this as well... Thanks! :)


Not applicable
Great article, thank you very much Ross! :-)
Not applicable
The Outlook updates you recommend were just released. Are we saying that nobody had been able to Co exist Exchange 2013 with Exchange 2010 utilizing Kerberos prior to January 2015? Or are you just recommending the latest patches?