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 credentialThere
- Assign the SPNs to the ASA credential account
- Deploy the ASA credential to the CAS servers
- Convert the OAB Virtual Directory to a web application
- 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.
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. Exchange may also need the NETBIOS (short name), so be sure to create SPNs for both the NETBIOS & FQDN for each.
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$
Deploy the ASA credential to the CAS servers
Once this step is complete, clients will be able to start authenticating to the CAS Array via Kerberos Authentication.
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, you must download the script http://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.
Testing Kerberos Authentication
Now that you have completed all the steps we need to test if Kerberos authentication is working.
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
Verify the OAB virtual directory has been successful converted to a web application by checking for a new application pool for the OAB virtual directory in IIS Manager.
To test from an Outlook client, you can open Outlook and verify that the Connection Status now shows Negotiate as the authentication type.
Once Outlook is connected, 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…
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.
You have now successfully enabled Kerberos authentication for your Client Access Array!