Kerberos...Slaying the dragon in an Exchange deployment.

We have all been there.  You are elbow deep in an Exchange deployment, and time is of the essence.  The environment is mid or small-size, and you may be thinking to yourself… “Self, let’s just get this deployment done and do it as easily and painlessly as possible”.  With that line of thinking, enabling Kerberos falls into the category of It can be done after the fact.  While that may be true, let’s look at some of the pros and cons of enabling Kerberos, or leaving things as is with NTLM.  We can begin with NTLM (NT Lan Manager).


It’s Easy!  By default, it’s ready to go out of the box.  No fuss, and you’re up and running quickly.

It’s the default!  Enough said on that.

It can be used outside of the immediate domain.  Kerberos is limited to clients and servers within the domain it’s in, unless third party smartcard is utilized.


It’s a heavier load on Active Directory.  Authentication check for every connection to every server client connects to.

It’s less secure then Kerberos.  NTLM uses an 8 byte sequence that can be sniffed internally.

It’s doesn’t pass authentication between servers.  This means that your credentials and passwords are going everywhere on the network, using only the default encryption mentioned above.

In large scale deployments, NTLM can cause bottlenecks at the CAS servers, causing intermittent authentication failures. 

There is no getting around it, NTLM is definitely easier to configure from startup perspective.  If you’re looking to roll out an environment with less headache, and the client is OK with the default, then NTLM is a viable option.   Security of the Authentication mechanism on the network usually doesn’t become a high priority, until something happens.  Now on to Kerberos:


It’s more secure.  Token based security.  (Three points of contact – KDC, Server, Client)

Your password is not making rounds through the environment.

Less load on Domain Controllers.  When coupled with other Microsoft applications (SP, Lync, etc..)

Ideal for large scale deployments where NTLM scalability is an issue.


It’s a more time consuming to configure.  Involves use and knowledge of SPN records.

It can’t be utilized outside the domain without a smartcard etc...

Client knowledge of Kerberos may be limited.  A thorough understanding of SPN records and their usage is required.

Kerberos, while normally not the go to authentication method, could be making its presence felt as companies continue to add Microsoft applications to their environments.  Think of the authentication traffic going to and from the domain controllers in environments that utilize the full suite of Microsoft products on a daily basis.  All of that server utilization has to be handled by the domain controllers to facilitate those requests.  Rather than build or add additional DC’s as companies hopefully continue to grow and expand, wouldn’t it be easier in the long run to bite the bullet now, and configure the application for the long run?  I encourage you to take a second look at enabling this Authentication method.  Below are some tips and tricks for getting Kerberos enabled in a Microsoft Exchange environment.

Configure the Alternate Service Account Credential

If you’re not familiar with this beauty, I encourage you get familiar with her.  This account (Either computer or user, I prefer computer) will make the creation and utilization of SPN records needed much easier and faster than without.  The ASA account is the account that will be utilized whenever an Authentication needs to be make for a CAS connection within the domain.  This account is created and associated with all of your relevant SPN’s needed and utilized by Exchange.  Below are some quick instructions for configuring it:

1.       Create a Computer account in the Active Directory domain that will be used as the ASA credential. For example, EXCASASA. (Note: Because it is a computer account, the actual account name will be\EXCASASA$.)

Next, run the following script to configure your SPN’s for your ASA account.  Substitute Contoso entries with your environment names.  Delete what’s not needed based on your particular environment.  Please note, this script is written for a Load balancer scenario.  Each line space is a separate entry into PowerShell:

1.       $acct="\excasasa`$"



foreach ($spn in $spnlist) {setspn -F -S $spn $acct}


Lastly, we need to associate our new ASA account to the existing CAS array servers.

2.      From the \program files\Microsoft\Exchange  Server\v14\scripts folder run :

.\RollAlternateServiceAccountPassword.ps1 -ToArrayMembers -GenerateNewPasswordFor Contoso\Excasasa$ -verbose

Please, please, please remember.  Do not run the above script against different CAS servers at different times.  Make sure the scope you set above grabs all of the servers at the same time.  Running the above script against a single CAS will break Kerberos authentication against all others.  Remember, its all or nothing when running this script, it can’t be done piecemeal.  You can also utilize the –ToSpecificServers parameter to select multiple servers who may not be in the CAS array.  Anytime you add a new CAS server, you will have to run the above PowerShell script in step 2. (.\RollAlternateServiceAccountPassword.ps1 ) to reset the password and apply it to all servers in your environment.

The script gives one prompt for changing the password on the account. Answer Y.  When ok, script is exiting with “The script has succeeded”

3.       To verify the script execute:

Get-ClientAccessServer  -IncludeAlternateServiceAccountCredentialstatus |fl name,alternateserviceaccountconfiguration

Well, that’s it.  Kerberos for Exchange in a nutshell.  Hopefully this article adds to your knowledge of Kerberos and SPN’s and their utilization. 

For more information about using Service Principal names see Microsoft TechNet article Service Principal Names (SPNs) SetSPN Syntax (Setspn.exe) (

For more information about configuring the Alternate Service Account Credential see Microsoft TechNet article Using Kerberos with a Client Access Server Array or a Load-Balancing Solution (


Labels: , , , , ,