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:
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.
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
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 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.
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.
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.
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
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.
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