Export (0) Print
Expand All

Configuring Kerberos authentication for load-balanced Client Access servers

 

Applies to: Exchange Server 2010 SP2

Topic Last Modified: 2014-09-11

Summary: Describes how to use Kerberos authentication with load-balanced Client Access servers in Exchange 2013.

In order for you to use Kerberos authentication with load-balanced Client Access servers, you need to complete the configuration steps described in this article.

All load-balanced computers that are running Client Access servers must use the same account. In addition, any Client Access servers that may be called on in a datacenter activation scenario must also use the same account in order to prevent a split-brain condition. In general, it's sufficient to have a single account for a forest. This account is also called the alternate service account credential or ASA credential.

When you set up the ASA credential, keep these guidelines in mind:

  • Account type. We recommend that you create a computer account instead of a user account. A computer account doesn’t allow interactive logon and may have simpler security policies than a user account. If you create a computer account, the password doesn’t expire, but we recommend you update the password periodically anyway. You can use local group policy to specify a maximum age for the computer account and scripts to periodically delete computer accounts that do not meet current policies. Your local security policy also determines when you need to change the password. Although we recommend you use a computer account, you can create a user account.

  • Account name. There are no requirements for the name of the account. You can use any name that conforms to your naming scheme.

  • Account group. The account you use for the ASA credential doesn't need special security privileges. If you are using a computer account then the account only needs to be a member of the Domain Computers security group. If you are using a user account then the account only needs to be a member of the Domain Users security group.

  • Account password. The password you provide when you create the account will be used. So when you create the account, you should use a complex password and ensure that the password conforms to your organization’s password requirements.

To create the ASA credential as a computer account
  1. On a domain-joined computer, run Windows PowerShell or the Exchange Management Shell.

    Use the Import-Module cmdlet to import the Active Directory module.

    Import-Module ActiveDirectory
    
  2. Use the New-ADComputer cmdlet to create a new Active Directory computer account using this cmdlet syntax:

    New-ADComputer [-Name] <string> [-AccountPassword <SecureString>] [-AllowReversiblePasswordEncryption <System.Nullable[boolean]>] [-Description <string>] [-Enabled <System.Nullable[bool]>]
    

    Example:

    New-ADComputer -Name EXCHASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCHASA
    

    Where EXCHASA is the name of the account, the description Alternate Service Account credentials for Exchange is whatever you want it to be, and the value for the SamAccountName parameter, in this case EXCHASA, must be unique in your directory.

    For more information about these cmdlets, see Import-Module and New-ADComputer.

If you have a cross-forest or resource-forest deployment, and you have users that are outside the Active Directory forest that contains Exchange, you must configure trust relationships between the forests. Also, for each forest in the deployment, you need to set up a routing rule that enables trust between all name suffixes within the forest and across forests. For more information about managing cross-forest trusts, see Managing forest trusts.

After you create the ASA credential, you must associate Exchange Service Principal Names (SPNs) with the ASA credential. The list of Exchange SPNs may vary with your configuration, but should include at least the following:

  • http/   Use this SPN for Outlook Anywhere, MAPI over HTTP, Exchange Web Services, Autodiscover, and Offline Address Book.

The SPN values must match the service name on the network load balancer instead of on individual servers. To help plan which SPN values you should use, consider the following scenarios:

In each of these scenarios, assume that the load-balanced, fully-qualified domain names (FQDNs) have been deployed for the internal URLs, external URLs, and the autodiscover internal URI used by the Client Access server members. For more information, see Understanding proxying and redirection.

If you have a single Active Directory site, your environment may resemble the one in the following figure:

CAS Array with Single AD and Kerberos auth

Based on the FQDNs that are used by the internal Outlook clients in the preceding figure, you need to associate the following SPNs with the ASA credential:

  • http/mail.corp.tailspintoys.com

  • http/autodiscover.corp.tailspintoys.com

If you have multiple Active Directory sites, your environment may resemble the one in the following figure:

CAS array with multiple AD sites and Kerberos auth

Based on the FQDNs that are used by the Outlook clients in the preceding figure, you would need to associate the following SPNs with the ASA credential that is used by the Client Access servers in ADSite 1:

  • http/mail.corp.tailspintoys.com

  • http/autodiscover.corp.tailspintoys.com

You would also need to associate the following SPNs with the ASA credential that is used by the Client Access servers in ADSite 2:

  • http/mailsdc.corp.tailspintoys.com

  • http/autodiscoversdc.corp.tailspintoys.com

After you’ve created the account, you need to verify that the account has replicated to all AD DS domain controllers. Specifically, the account needs to be present on each Client Access server that will use the ASA credential. Next, you configure the account as the ASA credential on each Client Access server in your deployment.

You configure the ASA credential by using the Exchange Management Shell as described in one of these procedures:

Once configured, you can verify the configuration by completing this task, To verify the configuration of the ASA credential.

For instructions on opening the Exchange Management Shell, see Open the Shell.

To configure the ASA credential on a computer running only the Client Access server role
  1. On the Client Access server, open the Exchange Management Shell.

    By default, the Shell makes a connection to the computer running the Mailbox Server role for the session. To connect to the Client Access server and configure the ASA credential, run the following commands one at a time.

    $creds = Get-Credential
    

    When prompted, enter the account name and password you created for the ASA credential.

    $session = CreateOrGetExchangeSession EXCH1.tailspintoys.com $null $true $false EXCH1.tailspintoys.com
    
    Invoke-Command -Session $session -Args ($creds) -ScriptBlock {param($AsaCreds) Set-ClientAccessServer EXCH1 -AlternateServiceAccountCredential $AsaCreds}
    
  2. Repeat this procedure on each Exchange 2013 Client Access server that will use the ASA credential.

To configure the ASA credential on a computer running the Mailbox server and Client Access server roles
  1. On the Exchange server, open the Exchange Management Shell and run the following commands.

    Set-ClientAccessServer EXCH1 -AlternateServiceAccountCredential (Get-Credential)
    

    When prompted, enter the account name and password you created for the ASA credential.

To verify the configuration of the ASA credential
  1. Open the Exchange Management Shell and then type the following command.

    Get-ClientAccessServer EXCH1 -IncludeAlternateServiceAccountCredentialStatus | Format-List Name,Alt*
    
    

    The result should look similar to the following output:

    Name                                 : EXCH1
    AlternateServiceAccountConfiguration : Latest: 2/25/2014 1:10:53 PM, TOYS\EXCHASA$
                                           Previous: <Not set>
    Name                                 : EXCH2
    AlternateServiceAccountConfiguration : Latest: 2/25/2014 1:11:51 PM, TOYS\EXCHASA$
                                           Previous: <Not set>
    
    

Before you associate the SPNs with the ASA credential, you need to verify that the target SPNs aren't already associated with a different account in the forest. The ASA credential must be the only account in the forest with which these SPNs are associated. You can verify that no other account in the forest is associated with the SPNs by running the setspn command from the command line.

To verify an SPN is not already associated with an account in a forest by running the setspn command
  1. Press Start. In the Search box, type Command Prompt, then in the list of results, select Command Prompt.

  2. At the command prompt, type the following command:

    setspn -F -Q <SPN>
    

    Where <SPN> is the SPN you want to associate with the ASA credential. For example:

    setspn -F -Q http/mail.tailspintoys.com
    

    The command should return nothing. If it returns something, another account is already associated with the SPN. Repeat this step once for each SPN you want to associate with the ASA credential.

To associate an SPN with an ASA credential by using the setspn command
  1. Press Start. In the Search box, type Command Prompt, then in the list of results, select Command Prompt.

  2. At the command prompt, type the following command:

    setspn -S <SPN> <Account>$
    

    Where <SPN> is the SPN you want to associate with the ASA credential and <Account> is the account associated with the ASA credential. For example:

    setspn -S http/mail.tailspintoys.com TOYS\EXCHASA$
    

    Run this command once for each SPN you want to associate with the ASA credential.

To verify you associated the SPNs with the ASA credentials by using the setspn command
  1. Press Start. In the Search box, type Command Prompt, then in the list of results, select Command Prompt.

  2. At the command prompt, type the following command:

    setspn -L <Account>$
    

    Where <Account> is the account associated with the ASA credential. For example:

    setspn -L TOYS\EXCHASA$
    

    You only need to run this command once.

After you've successfully configured Kerberos and the ASA credential, verify that clients can authenticate successfully as described in these tasks.

The Microsoft Exchange Service Host service (MSExchangeServiceHost) on the Client Access server is responsible for managing the ASA credential. If this service isn’t running, Kerberos authentication isn’t possible. By default, the service is configured to automatically start when the computer starts.

To verify the Microsoft Exchange Service Host service is started
  1. Click Start, type services.msc, and then select services.msc from the list.

  2. In the Services window, locate the Microsoft Exchange Service Host service in the list of services.

  3. The status of the service should be Running. If the status is not Running, right-click the service, and then click Start.

When you configured the ASA credential on each Client Access server, you ran the set-ClientAccessServer cmdlet. Once you have run this cmdlet, you can use the logs to verify successful Kerberos connections.

To validate that Kerberos is working correctly by using the HttpProxy log file
  1. In a text editor, browse to the folder where the HttpProxy log is stored. By default, the log is stored in the following folder:

    %ExchangeInstallPath%\Logging\HttpProxy\RpcHttp

  2. Open the most recent log file and look for the word Negotiate. The line in the log file will look something like the following example:

    2014-02-19T13:30:49.219Z,e19d08f4-e04c-42da-a6be-b7484b396db0,15,0,775,22,,RpcHttp,mail.tailspintoys.com,/rpc/rpcproxy.dll,,Negotiate,True,TOYS\Wendy,tailspintoys.com,MailboxGuid~ad44b1e0-e44f-4a16-9396-3a437f594f88,MSRPC,192.168.1.77,EXCH1,200,200,,RPC_OUT_DATA,Proxy,exch2.tailspintoys.com,15.00.0775.000,IntraForest,MailboxGuidWithDomain,,,,76,462,1,,1,1,,0,,0,,0,0,16272.3359,0,0,3,0,23,0,25,0,16280,1,16274,16230,16233,16234,16282,?ad44b1e0-e44f-4a16-9396-3a437f594f88@tailspintoys.com:6001,,BeginRequest=2014-02-19T13:30:32.946Z;BeginGetRequestStream=2014-02-19T13:30:32.946Z;OnRequestStreamReady=2014-02-19T13:30:32.946Z;BeginGetResponse=2014-02-19T13:30:32.946Z;OnResponseReady=2014-02-19T13:30:32.977Z;EndGetResponse=2014-02-19T13:30:32.977Z;,PossibleException=IOException;
    
    

    If you see the AuthenticationType value is Negotiate, then the server is successfully creating Kerberos authenticated connections.

If you need to refresh the password on the ASA credential periodically, use the steps for configuring the ASA credential in this article. Consider setting up a scheduled task to perform regular password maintenance. Be sure to monitor the scheduled task to ensure timely password rollovers and prevent possible authentication outages.

To configure your Client Access server so that it doesn't use Kerberos, disassociate or remove the SPNs from the ASA credential. If the SPNs are removed, Kerberos authentication won't be attempted by your clients, and clients configured to use Negotiate authentication will use NTLM instead. Clients configured to use only Kerberos will be unable to connect. Once the SPNs are removed you should also delete the account.

To remove the ASA credential by using the Exchange Management Shell
  1. On the Client Access server, open the Exchange Management Shell and run the following command. For instructions, see Open the shell.

    Set-ClientAccessServer EXCH1 -RemoveAlternateServiceAccountCredentials
    
    
  2. Although you don’t have to do this immediately, you should eventually restart all client computers to clear the Kerberos ticket cache from the computer.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft