Enabling Kerboros authentication for MAPI clients with Exchange 2013

In my experience security behind authentication mechanisms in Exchange is often overlooked - I am not going to go on a big rant about what kerboros can do and why it should

be used (you can do that pretty easily by doing a quick search e.g. ntlm vs kerboros.) Although in this post I will highlight the main steps in order to get Kerboros up and running in your Exchange environment.

It is worth noting that by default Outlook client are set to negotiate the most secure authentication mechanism available - so when Kerboros has been setup on the server side the client configuration should pickup the changes.

1. Create a computer account called "ExchangeASA" which will be used as an 'Alternative Service Account' - this account is necessary due to when working with CAS Arrays (in Exchange 2010) or a cluster of client access servers the TGT (Ticket Granting Ticket) contains the target server - of which will be the load balancer namespace e.g. cas-cluster.domain.com - when in actuality the end server will be different e.g. cas01.domain.com or cas02.domain.com.

The following from TechNet explains goes into a little more detail of this process:

a) Client contacts KDC and obtains a TGT.
b) Client sends a request to the TGS based on the TGT, the authenticator, and the name of the target server. In this case, the name of the target server outlook.contoso.com, and not the FQDN of the Client Access server.
c) Client retrieves service ticket and sends it to outlook.contoso.com, which happens to get directed by the load balancer to cas1.contoso.com. cas1.contoso.com fails to decrypt the service ticket because: Its name does not match outlook.contoso.com.
e) The SPN is not associated with cas1.contoso.com or multiple objects within Active Directory have an SPN associated with the associated service and outlook.contoso.com.
f) Client fails to obtain an access token using Kerberos authentication.


2. Run the following powershell script to setup the relevent SPN's - replacing the relevent hostnames where necessary:

$acct="domain.com\ExchangeASA`$"

$spnlist=@("http/owa.domain.com”,"http/autodiscover.domain.com","http/failback.domain.com”,"exchangeMDB/loadbalancer-namespace.domain.com","exchangeRFR/loadbalancer-

namespace.domain.com","exchangeAB/loadbalancer-namespace.domain.com")

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

3. Within the Exchange 2013 scripts folder you will find a scipt entitled: RollAlternateserviceAccountCredential.ps1 - this will register (or update) the ASA credentials

assoisiated with the CAS load balancing set (or CAS array if you are running 2010):

.\RollAlternateServiceAccountPassword.ps1 -ToArrayMembers loadbalancing-namespace.domain.com -GenerateNewPasswordFor Contoso\ExchangeASA$ -verbose

That's it! Just note that if you ever have add any additional CAS nodes to the load balancing set / array you will have to re-run this script - as Kerboros will fail!

Sources:
http://anexinetisg.blogspot.co.uk/2013/07/kerberosslaying-dragon-in-exchange.html
http://blogs.technet.com/b/exchange/archive/2011/04/15/recommendation-enabling-kerberos-authentication-for-mapi-clients.aspx