Typically, mail clients on domain-joined computers inside your network use NTLM authentication. In some circumstances, you might have to use Kerberos authentication. This should only be done if it's required, because Kerberos presents additional challenges in setup and implementation. For more information about Kerberos, see Kerberos Enhancements and Microsoft Kerberos.

Note:
Kerberos can only be used for domain-joined computers inside your network. This includes clients connected by a VPN. For connections outside the network, such as Outlook Anywhere, Kerberos isn't supported.

You may be required to use Kerberos authentication for your Exchange 2010 organization for the following reasons:

• Kerberos authentication is necessary for your local security policy.
  
  
• You're encountering or anticipating NTLM scalability issues, for example, when direct MAPI connectivity to the RPC Client Access service causes intermittent NTLM failures.
  
  In large-scale customer deployments, NTLM can cause bottlenecks on Client Access servers that can result in sporadic authentication failures. Services that use NTLM authentication are more sensitive to Active Directory latency issues. These lead to authentication failures when increases in the rate of Client Access server requests are encountered.
  
  

To configure Kerberos authentication, you must be familiar with Active Directory and the setup of Client Access server arrays. And you must have a working knowledge of Kerberos.

When Client Access servers are load-balanced or are part of a Client Access server array, clients configured with NTLM authentication will connect without a problem. However, using Kerberos requires additional setup and was problematic prior to Exchange 2010 Service Pack 1 (SP1).

In a topology with a load balancer or a Client Access array, a client doesn't connect to an individual server by name, but rather by the array or load balancer name. This impedes Kerberos authentication unless you perform additional configuration steps.

When you use Kerberos, the first configuration step is to set up an array of specific Service Principal Names (SPNs) for the client access services. As soon as the array is set up, e-mail clients that are configured to use Negotiate authentication will try to perform Kerberos authentication. They'll obtain Kerberos service tickets in the context of the array and present those tickets to the Client Access server. However, on any particular Client Access server, Exchange services run in the context of either the local system or network service account and will try to authenticate the Kerberos service tickets in those contexts, rather than in the context of the array. This causes a context mismatch and results in a Kerberos authentication failure. Because of the enhanced security of Kerberos, clients configured to perform Negotiate authentication won't just fall back to NTLM authentication, but will either default to using Outlook Anywhere, if available, or fail to authenticate and connect.

For Kerberos authentication to succeed, the Client Access server array member must use an alternate credential that's shared by all members of the array. The credential must also be associated with the array-specific SPNs. This shared credential may be either a computer account or a service account and must be known by every Client Access server within the array. Typically, organizations require that account passwords change periodically. This mandates an ongoing task of distributing and updating this shared credential to all Client Access servers. Before Exchange 2010 SP1, neither Windows Server 2008 nor Microsoft Exchange had a solution for this issue.

Note:

Although this discussion refers to a network load balancer and a Client Access server array, any network infrastructure or configuration that doesn't result in the client connecting directly to a specific Client Access server will have these same authentication issues. Other examples of this configuration include Client Access servers with DNS round-robin load balancing and Client Access servers with custom DNS records. The following solution is designed to simplify distribution of the alternate service account credential to members of a Client Access server array or Client Access servers behind a network load balancer. It's not designed to work with configurations where the Client Access servers aren't configured in a Client Access array.

To resolve this problem, there must be a shared credential that can be used by all Client Access servers in the array or behind the load balancer. This credential is known as an alternate service account credential (ASA credential) and can be either a computer or a user service account. To distribute this alternate service account credential to all Client Access servers, a three-fold solution has been implemented in Exchange 2010 SP1.

The Client Access server service host has been extended to use a shared credential for Kerberos authentication. This service host extension monitors the local machine. When credentials are added or removed, the Kerberos authentication package on the local system and the network service context is updated. As soon as a credential is added to the authentication package, all client access services can use it for Kerberos authentication. The Client Access server will also be able to authenticate service requests addressed directly in addition to being able to use the shared credential. This extension, known as a servicelet, runs by default and requires no configuration or action to run.

The shared credential and password can be obtained and set using the Exchange Management Shell. This enables the credential to be set from a remote computer. The credential is set by storing the credential in the target computer's registry for consumption by the service host. You set the credential using the Set-ClientAccessServer cmdlet with the new AlternateServiceAccountCredential parameter. After the shared credential password has been set, the shared credential allows Client Access services to perform Kerberos authentication for Intranet connected clients. For more information about the Set-ClientAccessServer cmdlet, see Set-ClientAccessServer.

A management script has been created to help automate the distribution of the shared credential to all Client Access servers specified within the scope of the script. This script is the recommended way to use and maintain a shared credential for client Access server array Kerberos authentication. The script provides an automated way to use the Set-ClientAccessServer cmdlet to facilitate the following tasks:

• Initial Setup   The ASA credential is set on all Client Access servers within an array or forest.
  
  
• Password Rollover   A new password for the ASA credential is generated and rolled out to all Client Access servers in addition to updating Active Directory.
  
  
• Adding one or more computers to a Client Access server array   The ASA credential is copied from an existing server and distributed to other servers so they can perform Kerberos authentication with the current credential and password.
  
  
• Ongoing maintenance   A scheduled task is created to regularly roll the password by using an unattended method.
  
  

For more information about how to configure Kerberos authentication for load-balanced Client Access servers, see Configuring Kerberos Authentication for Load-Balanced Client Access Servers.

For more information about the RollAlternateServiceAccountCredential.ps1 script, see Using the RollAlternateserviceAccountPassword.ps1 Script in the Shell.