Configuring Kerberos Authentication in Exchange 2010

There are many benefits to enabling Kerberos Authentication for your CAS Array in Exchange 2010 (SP1 and above).  One of the primary benefits is to alleviate the NTLM authentication issues in Exchange 2010 that I blogged about in my previous post.  Kerberos authentication provides a SIGNIFICANT reduction in authentication traffic versus NTLM, and helps prevent those authentication bottlenecks that can be crushing to an Exchange 2010 infrastructure.   

 

Essentially these are the main steps to configure Kerberos Authentication for Exchange 2010:

  • Create an account to be used as the ASA credential
  • Deploy the ASA credential to the CAS servers
  • Convert the OAB Virtual Directory to a web application
  • Assign the SPNs to the ASA credential account
  • Testing

 

Create an account to be used as the ASA credential 

I prefer using a computer account so the password doesn’t expire, otherwise you’d have to make sure to update the credentials regularly.  The computer name you give it doesn’t matter, but I typically use ASA or CASARRAY.  In the description, make sure to put something along the lines of DO NOT DELETE: and followed by something like This account is used for Kerberos Authentication on the CASARRAY.     

Deploy the ASA credential to the CAS servers

There is a built-in script that will deploy the ASA account credentials to all CAS servers: RollAlternateServiceAccountPassword.ps1 

 

Here is the command to use once you have created the ASA account and the associated SPNs:   

.\RollAlternateserviceAccountPassword.ps1 -ToArrayMembers {CAS array name} -GenerateNewPasswordFor "{Domain}\{ASA}" –Verbose

 

Using our examples it would look something like this:

.\RollAlternateserviceAccountPassword.ps1 -ToArrayMembers outlook -GenerateNewPasswordFor “CONTOSO\ASA$" –Verbose

  • Answer Yes when the script asks if you want to change the password for the ASA account at this time.
  • The final output should tell you if the script has succeeded… or if it failed at any point.   

 

Convert the OAB virtual directory to a web application

Since the OAB virtual directory is not actually a web application, we must convert it to a web application to allow Kerberos requests to the OAB.   

To convert the OAB, you must download this script  https://gallery.technet.microsoft.com/scriptcenter/525fb1dc-b612-4998-a2d1-55f32a6c35ac  

Then login to EACH Client Access server, copy over the script to the Scripts directory (Default location is C:\Program Files\Microsoft\Exchange Server\V14\Scripts) and run the ConvertOABDir.ps1 script 

NOTE: This step MUST be done from EACH Client Access Server.

 

Assign the SPNs to the ASA credential account

In this step we will assign the Exchange service principal names (SPNs) that will be associated with the ASA credential account we created in the previous step.  Since Exchange may also need the NETBIOS (short name), we will create SPNs for both the NETBIOS & FQDN for each.  Once this step is complete, clients will be able to start authenticating to the CAS Array via Kerberos Authentication.    

There are various SPNs that are required. 

  • http:   This SPN will be used for AutoDiscover, Exchange Web Services (EWS), and the Offline Address Book (OAB).
  • exchangeMDB:  This SPN is used for the RPC Client Access Service
  • exchangeRFR:  This SPN is used for the Address Book Service
  • exchangeAB:  This SPN is used for the Address Book Service

 

Example commands to create the SPNs: 

Note: the $ after the ASA credential account (ASA in this example) is required when a computer account is used.  Outlook refers to the FQDN of the Client Access Array in my lab.

 

setspn -s exchangeMDB/outlook ASA$

setspn -s exchangeRFR/outlook ASA$

setspn -s exchangeAB/outlook ASA$

setspn -s exchangeMDB/outlook.contosos.local ASA$

setspn -s exchangeRFR/outlook.contoso.local ASA$

setspn -s exchangeAB/outlook.contoso.local ASA$

setspn -s http/mail.contoso.local ASA$

setspn -s http/autodiscover.contoso.com ASA$  

 

NOTE: To disable/remove Kerberos Authentication... simply remove these SPNs.  

 

Testing Kerberos Authentication

Now that you have completed all the steps we need to test if Kerberos authentication is working. 

 

Verify the Client Access Servers

Verify that all Client Access Servers in the CAS Array have accepted the ASA Credential by running the following command:

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialstatus |Fl Name, AlternateServiceAccountConfiguration

If one of the Client Access servers did not get the credentials, then you can run the following command to copy the credentials to any CAS server(s) that didn't get the credentials:

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

 

Verify the OAB virtual directory has been successfully converted to a web application by checking for a new application pool for the OAB virtual directory in IIS Manager.

Another good test is to open a current Address Book Log (Default location is C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBookService) and make sure that for new entries the Authentication method sent is Kerberos.  There may still be some NTLM as well, but you should now see Kerberos.

 

Verify from Outlook

To test from an Outlook client, you can open Outlook and verify that the Connection Status now shows Negotiate as the authentication type [Outlook 2013].

Configure your Outlook client to connect via Kerberos:

 

Close and then open Outlook... if it connects without any problems then Kerberos is working. 

 

As another test once Outlook is open, you can also run the KLIST command (WIN7 and above) from the command prompt to ensure you have Kerberos tickets generated for the SPNs we created. 

You will see something like this - look for the SPNs for your Exchange services:

#1            Client:  user @ CONTOSO.COM

                Server: exchangeMDB/Outlook.contoso.local @ contoso.local

                KerbTicket

                Ticket Flags

 

#2           Client:  user @ CONTOSO.COM

               Server: exchangeAB/Outlook.contoso.local @ contoso.local

                KerbTicket…

                Ticket Flags…

 

#3           Client:  user @ CONTOSO.COM

                Server: exchangeRFR/Outlook.contoso.local @ contoso.local

                KerbTicket...

                TicketFlags…

 

You have now successfully enabled Kerberos authentication for your Client Access Array!

~Craig