Last year, the Exchange Product Team announced that enabling Kerberos authentication for MAPI clients was the recommendation from then on forward. Since then, I’ve come across numerous Exchange deployments that still don’t have Kerberos enabled. Why is that? Mostly because they’re not experiencing any issues with NTLM and for some part also because the recommendation is either unknown or they’re struggling with the configuration. That’s why I’m writing this article: to shed (another) light on the recommendation and recap the information that Ross already laid out very well in his article.
Where the recommendation comes from
By default, Outlook 2007 and newer clients will negotiate the strongest authentication available. In previous versions of Exchange Server the client would connect directly to the mailbox server which is – at that point – a single identity. Since Kerberos requires that the both client/server engaging in the authentication process have each an unique identity, Kerberos could be used. In Exchange 2010, however, this is not always true: most deployments leverage the built-in high availability features like a load-balanced array of Client Access Servers which imposes some additional challenges for Kerberos.
So despite there’s an additional challenge to deploying Kerberos, why change? NTLM potentially overloads your Domain Controller(s): whenever a client connects to CAS, it sends along its authentication information. The CAS will then verify the received information by contacting a Domain Controller (btw this process is a ‘Secure Channel Call’). A Client Access Server has affinity with only a single DC which means that all requests from a specific CAS go to the same DC. Furthermore, there is no mechanism in Exchange that controls which CAS can connect to what domain controller. So you could end up with multiple CAS connecting to the same DC, which in turn could get overloaded because of that. By default, Windows limits the number of concurrent secure channel calls that can be made to 2. Although you could increase that number of concurrent calls, doing so can also negatively impact a domain controller’s performance and therefore not recommended either. It is possible to monitor the number of failed NTLM request, which helps you identify whether you’re having problems or not. Please have a look at KB928576 for more information. It goes without saying that smaller deployments are less likely to experience issues with NTLM; larger deployments on the other hand might run into these limitations more easily.
Before getting our hands “dirty” by diving into the configuration-part, let’s refresh our memory and see how Kerberos actually works and what the issues are.
A while back, I created a drawing which visually explains how all pieces actually come together. Although the article from Ross actually does a very good job at explaining (in a way that is commonly understandable) how Kerberos works, I thought that it wouldn’t hurt. After all, an image says more than a thousand words, doesn’t it?
You can download the image from here. The document also contains some additional information on cross-domain authentication w/ Kerberos.
If you’re interested in a deeper dive into Kerberos v5, have a look here: http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx
In step 8 (in the image above), the client sends a request for access to the TGS using the service’s ID. This ID is also known as the Service Principal Name (SPN). Under normal circumstances (e.g. in Exchange 2007) there would be three different SPN associated with the mailbox server:
Because the SPN matches the hostname of the server, a client would be able to negotiate Kerberos authentication.
In Exchange 2010 a client does not necessarily use the same namespace as the mailbox server’s name when accessing mailbox information. When a CAS Array is implemented, the FQDN that the client uses to connect to Exchange points to an array of CAS servers instead of a single server. This is an issue for Kerberos since an SPN can only be attributed to a single, unique entity. (The latter is also what prevents you from manually registering the same SPN on each individual CAS server).
The following image tries to visually explain why this is a problem, starting from the point where the client requests access to a service (in this case: a mailbox), thus assuming that the client already successfully obtained a TGT.
The solution: ASA Credential a.k.a. Alternative Service Account Credential
Exchange 2010 Service Pack 1 introduced an extension to the Microsoft Exchange Service Host that runs on the CAS server role which enables Kerberos authentication for MAPI clients by using a Alternative Service Account. The latter is either a computer- or a user account that needs to be “shared” amongst the different Client Access Servers in an array.
The following tasks need to be executed in order to get things working:
- Create an account (to be used as the ASA credential)
- Deploy the ASA credential to the Client Access Servers
- Convert Offline Address Books to a WebApp
- Configure SPNs
- (Testing the configuration)
Step 1: Creating an Alternative Service Account
First, start by creating a new account in Active Directory. As said before, this can either be a computer- or user account. Computer account cannot logon interactively, so they are the preferred way.
- Open Active Directory Users & Computers, and create a new computer account. Name the account so that you know what it is used for:
Note Make sure that the account that you’ve created has been replicated throughout the forest before moving to the next step.
Step 2. Deploy the ASA Credential
Deploying the credential is fairly easy. Microsoft has developed a script which takes care of the configuration. The script is called: RollAlternativeServiceAccountPassword.ps1 and is located in the $exscripts folder which you usually can find under: “<drive>:\Program Files\Microsoft\Exchange Server\V14\Scripts”
- Run the script from the Exchange Management Shell:
.\RollAlternativeServiceAccountPassword.ps1 –ToArrayMembers <arrayname> –GeneratePasswordFor <accountname$>
Note don’t forget to add the dollar-sign ($) after the account name to indicate it’s a computer-account.
To verify if the accounts were configured correctly, run the following cmdlet:
Get-ClientAccessServer –IncludeAlternateServiceAccountCredentialPassword | FT Name,*Alternate*
Step 3: Convert the OAB
By default, the OAB isn’t a WebApp (therefore not controlled by the Exchange Service Host) but needs to be converted to one. Microsoft also created a script to accomplish this task: ConvertOABDir.ps1. The script needs to be run on each array member:
- Run the script from the Exchange Management Shell:
When taking a peek in the IIS Manager, you will notice that the OAB changed:
Note Don’t forget to run this script on all array members!
Step 4: Configure SPNs
All that is left to do, is associating the different SPNs with the Alternative Service Account Credential. Note that the SPNs should only be associated with the ASA Credential. If you’d like to verify whether an SPN has already been associated with another account, run the SETSPN command with the -Q parameters. If you’re running the command from a Windows Server 2008 Domain Controller, you can also add the –F parameter which will automatically look for duplicates in the entire forest instead of only the domain from where you’re running it:
Before you can configure SPNs, you need to know which ones. But how do you know what SPNs to configure? You will at least need to take into account the following ones:
- http (used from EWS, OAB and Autodiscover)
- exchangeMDB (RPC Client Access)
- exchangeRFR (Address Book Service)
- exchangeAB (Address Book Service)
What values you have to configure, greatly depends on your deployment an will vary from case to case. The following article provides – next to some more information – some scenarios the can help you understand what SPNs you need to configure:
Let’s take the example that you have to configure the following SPNs:
You would then run the following commands:
- setSPN –s http/outlook.exblog.be exblog\KERB-EXCHANGE$
- setSPN –s exchangeMDB/outlook.exblog.be exblog\KERB-EXCHANGE$
- setSPN –s exchangeRFR/outlook.exblog.be exblog\KERB-EXCHANGE$
- setSPN –s exchangeAB/outlook.exblog.be exblog\KERB-EXCHANGE$
To verify that the SPNs have been configured correctly, run the following command:
- setSPN –l exblog\KERB-EXCHANGE$
To validate that the configuration is working you can do a few things:
- Open your Outlook Profile and go to the advanced settings. On the security-tab change network security from “Negotiate Authentication” to “Kerberos Password Authentication”:
Open outlook an verify that you can successfully connect to Exchange:
- On a Windows 7 computer, you can run KList.exe and verify that you have got a corresponding Kerberos-ticket:
- Run the following cmdlet from the Exchange Management Shell:
Test-OutlookConnectivity –Identity <user> –MailboxCredential (get-credential) –Protocol TCP
As you can see, there are quite some things to take into account but after all the process of enabling Kerberos should be relatively painless. If you feel that you need more information, have a look at the following pages:
Michael Van Horenbeeck