Steps to Configure Kerberos Authentication for an Exchange 2010 CAS Array

As a Microsoft Premier Field Engineer, I found customers asking for specific steps to configure Kerberos for their CAS Array. Below is an example of how Contoso configured Kerberos for their CAS Array.


Enable Kerberos for the CAS Array

  1. Create a new Computer Account in Active Directory User and Computers (ADUC) called CASARRAY-ASANote:ASA stands for Alternative Service Account
  2. Distribute the newly created account to all CAS Array members using a script. Open the Exchange Management ShellWithin the Exchange Management Shell change to
    c:\Program Files\Microsoft\Exchange Server\V14\Scripts

Tip: Use the existing variable to switch fast to the scripts folder by running the following command in the Exchange Management Shell:

cd $exscripts


.\RollAlternateserviceAccountPassword.ps1 –ToArrayMembers outlook -GenerateNewPasswordFor contoso\CASARRAY-ASA$ –Verbose

When asked to change the password in Active Directory for CASARRAY-ASA$, choose “Yes”

Note: outlook is the name of the CAS Array (Get-ClientAccessArray | FL Name)

3. Set the SPNs for the Alternate Service Account (ASA):

Note: You must set the Exchange service principal names (SPNs) that will be associated with the ASA credentials. The list of Exchange SPNs may vary with your configuration, but should include at least the following. Review: Configuring Kerberos Authentication for Load-Balanced Client Access Servers -


  • http Use this SPN for Exchange Web Services, Offline Address Book downloads, and the Autodiscover service.
  • exchangeMDB Use this SPN for RPC Client Access service.
  • exchangeRFR Use this SPN for the Address Book service.
  • exchangeAB Use this SPN for the Address Book service.


a.      Open cmd and run:
( is the CAS Array fqdn
contoso is the domain where CASARRAY-ASA was created)

setspn -s exchangeMDB/ contoso\CASARRAY-ASA$

setspn -s exchangeRFR/ contoso\CASARRAY-ASA$

setspn -s exchangeAB/ contoso\CASARRAY-ASA$

setspn -s http/ contoso\CASARRAY-ASA$

setspn -s http/ contoso\CASARRAY-ASA$

b.      Verify that all SPNS are set correctly, run

setspn –L contoso\CASARRAY-ASA$
setspn –L


Note: The Script RollAlternateServiceAccountPassword.ps1 offers additional capabilities:

1. Copying ASA Credential to new Servers added to the CAS ARRAY:

.\RollAlternateServiceAccountPassword.ps1 -CopyFrom ServerA -ToSpecificServers ServerB –Verbose

2. Schedules a once-a-month automated password roll scheduled task called “Exchange-RollAsa”. It will update the ASA credential for all Client Access servers in the entire forest with a new, script-generated password. The scheduled task is created, but the script is not run. When the scheduled task is run, the script runs in unattended mode

.\RollAlternateServiceAccountPassword.ps1 -CreateScheduledTask "Exchange-RollAsa" -ToEntireForest -GenerateNewPasswordFor 'contoso\computerAccount$'

Exchange stores the current and previous used ASA password. This prevents access problems due to AD replication delays.


Convert OAB virtual directory to a Web application

Out of the box, the OAB virtual directory is not a web application and, therefore, is not under the control of the Microsoft Exchange Service Host service.  As a result, Kerberos authentication requests to the OAB virtual directory cannot be decrypted by the ASA credential.

1. To convert the OAB virtual directory to a web application, execute the ConvertOABVDir.ps1 script on each CAS member.  The script will also create a new application pool for the OAB virtual directory.
Script location:

Before converting the OAB to a virtual directory:

After converting the OAB to a virtual directory (notice the icon change for OAB and MSExchangeOabAppPool):



A fix has been made in Windows to allow RPC Anonymous with RPC/Http

2619234.  A hotfix is available to enable the Association Cookie/GUID that is used by RPC over HTTP to also be used at the RPC layer in Windows 7 and in Windows Server 2008 R2.

After you apply this hotfix, Association Cookie/GUID is used to match the HTTP layer authentication context with the RPC connection allowing a new RPC authentication called Anonymous.

When RPC over HTTP clients connect to RPC over HTTP servers and Negotiate authentication is configured, Kerberos will be attempted if configured used for the HTTP layer. Meanwhile, Anonymous authentication is used for the RPC layer.



Additional Reading:

Recommendation: Enabling Kerberos Authentication for MAPI Clients

Configuring Kerberos Authentication for Load-Balanced Client Access Servers

Exchange 2013 and Exchange 2010 Coexistence with Kerberos Authentication


Comments (0)

Skip to main content