Jaa

Configuring Kerberos Authentication for Load-Balanced Client Access Servers

  • Artikkeli

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

To use Kerberos authentication with a load-balanced array of Client Access servers, several configuration steps must be completed. For more information about how to use Kerberos with a Client Access server array or a load-balancing solution, see Using Kerberos with a Client Access Server Array or a Load-Balancing Solution.

Create the Alternate Service Account Credential in Active Directory

All computers within the Client Access server array must share the same service account. In addition, any Client Access servers that may be called on in a datacenter activation scenario must also share the same service account. In general, it's sufficient to have a single service account per forest. This account is referred to as the alternate service account credential (ASA credential).

Note

If your deployment is complex and extends beyond the scenarios outlined below, has administrator delegation issues, or has multiple forest segments on different Exchange deployment schedules, you may have to create additional accounts. The RollAlternateServiceAccountPasswordl.ps1 script must be run separately for every account created.

Credential Type

You can create a computer account or a user account for the alternate service account. Because a computer account doesn’t allow interactive logon, it may have simpler security policies than a user account and therefore is the preferred solution for the ASA credential. If you create a computer account, the password doesn't actually expire, but we still recommend updating the password periodically. Local group policy can specify a maximum account age for computer accounts and there might be scripts scheduled to periodically delete computer accounts that do not meet current policies. Periodically updating the password for computer accounts will ensure that your computer accounts aren't deleted for not meeting local policy. Your local security policy will determine when the password needs to be changed.

Credential Name

There are no particular requirements for the name of the ASA credential. You can use any name that conforms to your naming scheme.

Groups and Roles

The ASA credential doesn't need special security privileges. If you are deploying a computer account for the ASA credential this means that the account only needs to be a member of the Domain Computers security group. If you are deploying a user account for the ASA credential, this means that the account only needs to be a member of the Domain Users security group.

Password

The password you provide when you create the account will never actually be used. Instead, the script will reset the password. So when you create the account, you can use any password that conforms to your organization’s password requirements.

Cross-Forest Scenarios

If you have a cross-forest or resource-forest deployment, and users are outside the Active Directory forest that contains Exchange, you must configure cross-forest trusts and routing name suffixes across forests. For more information, see Accessing Resources Across Forests and Routing Name Suffixes Across Forests.

Identifying the Service Principal Names That Should Be Associated with the Alternate Service Account Credential

After you create the alternate service account, you must determine the Exchange service principal names (SPNs) that will be associated with the ASA credentials. The list of Exchange SPNs may vary with your configuration, but should include at least the following.

  • http Use this SPN for Exchange Web Services, Offline Address Book downloads, and the Autodiscover service.

  • exchangeMDB Use this SPN for RPC Client Access.

  • exchangeRFR Use this SPN for the Address Book service.

  • exchangeAB Use this SPN for the Address Book service.

The SPN values must be configured to match the service name being used on the network load balancer, rather than on individual servers.

To help plan which SPN values you should deploy, consider the following conceptual scenarios:

  1. Single Active Directory Site

  2. Multiple Active Directory Sites

  3. Multiple Active Directory Sites with DAG Site Resiliency

In each of these scenarios, it’s assumed that load-balanced fully qualified domain names have been deployed for the Internal URLs, External URLs, and Autodiscover Internal URI used by the Client Access server members. For more information see Understanding Proxying and Redirection.

Single Active Directory Site

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

Single Active Directory Site

Based on the fully qualified domain names that are used by the internal Outlook clients in the previous illustration, the following SPNs would need to be deployed on the ASA credential:

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

External or Internet-based clients that use Outlook Anywhere won’t use Kerberos authentication. Therefore, the fully qualified domain names that are used by these clients don’t have to be added as SPNs to the ASA credential.

Important

If you deploy a split DNS infrastructure, external and internal clients use the same fully qualified domain names and those names must be represented as SPNs on the ASA credential.

Multiple Active Directory Sites

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

Kerberos Authentication with Mulitple Sites

Based on the fully qualified domain names that are used by the internal Outlook clients in the previous illustration, the following SPNs would have to be deployed on the ASA credential that’s used for the Client Access server array with the Active Directory site ADSite1:

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

Based on the fully qualified domain names that are used by the internal Outlook clients in the previous illustration, the following SPNs would need to be deployed on the ASA credential that’s used for the Client Access server array within the Active Directory site ADSite2:

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

Note

This example shows that you can use multiple ASA credentials for this particular scenario. However, you can use a single ASA credential for all Active Directory sites that host Client Access server arrays where you want to deploy Kerberos authentication.

Multiple Active Directory Sites with DAG Site Resiliency

If you have multiple Active Directory sites with DAG site resiliency, your environment may resemble the one in the following illustration.

Kerberos Authentication in a DAG

Because this architecture includes a Database Availability Group (DAG) that’s stretched across both Active Directory sites, you must deploy a single ASA credential for use by members of the Client Access server arrays in ADSite1 and ADSite2. If you don’t use a single ASA credential, clients will have Kerberos authentication issues when you perform a datacenter switchover because the secondary datacenter Client Access server array members won’t be able to decrypt the Kerberos session ticket. For more information about activating the secondary datacenter, see Datacenter Switchovers.

Based on the fully qualified domain names that are used by the internal Outlook clients in the previous illustration, the following SPNs would need to be deployed on the ASA credential that’s in use for the Client Access server arrays in ADSite1 and ADSite2:

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

Convert the Offline Address Book Virtual Directory to an Application

Out of the box, the Offline Address Book virtual directory isn’t a Web application, so it isn’t controlled by the Microsoft Exchange Service Host service. Therefore, Kerberos authentication requests to the Offline Address Book virtual directory can’t be decrypted by the ASA credential.

To convert the Offline Address Book virtual directory to a Web application, run the ConvertOABDir.ps1 script on each Client Access server member. The script will also create a new application pool for the Offline Address Book virtual directory. The script is located in the Exchange 2010 SP2 Scripts directory, or you can download the script here.

Deploying the Alternate Service Account Credential

After you’ve created the ASA credential, verify the account has replicated to all domain controllers within all Active Directory sites that contain the client Access servers that will use the ASA credential.

You can then run the AlternateServiceAccount credential script in the Exchange Management Shell. For more information, see Using the RollAlternateserviceAccountPassword.ps1 Script in the Shell. After the script has run, we recommend that you verify that all the targeted servers have been updated correctly.

Note

The script is provided in English only.

For help troubleshooting script errors, see Troubleshooting the RollAlternateServiceAccountCredential.ps1 Script.

The following example output of the RollAlternateServiceAccountPassword.ps1 script uses a computer account that’s created as the ASA credential. The account is named contoso/newSharedServiceAccountName. In the following example, the script applies the credential settings to each member of a Client Access server array called outlook.corp.contoso.com.

To run the script, use the following command.

RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$

You should receive the following output after you run the script. There’s one prompt that asks you for approval to change the password.

========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName                               Password--------                               --------contoso\newSharedServiceAccountName$                System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName       Last Pwd Update     --------------------- -----------------       ---------------     computer              contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion:   Array: outlook.corp.contoso.comIdentity  AlternateServiceAccountConfiguration--------  ------------------------------------NAE14CAS  Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>

You’ll also see two Event IDs in your event logs. One event is for the start of the script and one is for successful completion. The following is an excerpt from the successful completion event.

Log Name:      ApplicationSource:        MSExchange Management ApplicationEvent ID:      14002Task Category: KerberosLevel:         InformationDescription:Maintenance of the Alternate Service Accounts succeeded.

Verifying the Deployment of the ASA Credential

In the Exchange Management Shell, run the following command to check the settings on the Client Access servers.

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

The result of this command should look like the following.

Name                                 : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>Name                                 : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>

If you’ve run the script several times and made changes, the Previous entry will show you when the last change was made.

Name                                 : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name                                 : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$

Associating Service Principal Names with the Alternate Service Account Credential

Before you configure the SPNs, verify that the target SPNs aren't already configured on 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 has the SPNs associated with it by running the setspn command with the –q and –f parameters from the command line. The following example shows how to run this command. The command should return nothing. If it returns a value, another account is already associated with the SPN you’re thinking of using.

Note

Only Windows Server 2008 supports the duplicate-checking forest wide parameter (-f) in the setspn command.

Setspn -q -f exchangeMDB/outlook.corp.contoso.com

The following command provides an example of how to set the SPNs on the shared ASA credential. The setspn command with this syntax must be run once for every target SPN that you identify.

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

When you've set the SPNs, verify that they've been added by using the following command.

Setspn -L contoso\newSharedServiceAccountName$

Validating Exchange Client Kerberos Authentication

After you've successfully configured Kerberos and deployed the RollAlternateServiceAccountPasswordl.ps1 script, verify that clients can authenticate successfully.

Verifying that the Microsoft Exchange Service Host Service is Running

The Microsoft Exchange Service Host service on the Client Access servers is responsible for managing the ASA credential. If this service isn’t running, Kerberos authentication won’t be possible. By default, the service is configured to automatically start when the computer is started. Ensure that you’ve installed Exchange Server 2010 SP1 Rollup 3 or a later version on all Client Access servers in your environment.

Validating Authentication from Outlook

To ensure that Outlook is able to connect to the Client Access servers with Kerberos authentication, follow these steps:

  1. Confirm that Outlook is configured to point to the correct load-balanced Client Access server array.

  2. Configure the e-mail account server security settings to use logon network security Negotiate Authentication. Or, you could configure the client to use Kerberos Password Authentication. However, if the SPNs are ever removed, the clients won’t be able to authenticate until you change the authentication mechanism back to Negotiate Authentication.

  3. Confirm that Outlook Anywhere isn't enabled for the client. If Outlook fails to authenticate by using Kerberos, it will try to fall back to Outlook Anywhere, so Outlook Anywhere should be disabled for this test.

  4. Restart Outlook.

  5. If your desktop computer is running Windows 7, you can run klist.exe to see which Kerberos tickets have been granted and are in use. If you're not running Windows 7, you can obtain klist.exe from the Windows Server 2003 Resource Kit.

Validating Using the Test-OutlookConnectivity Cmdlet

To test whether Kerberos is working, use the Test-OutlookConnectivity cmdlet. This is the best way to see if TCP connectivity can be established. By default, the cmdlet will use Negotiate authentication for a TCP connection. So if Kerberos is configured, it will be used. The file klist.exe can be used to view the Kerberos tickets on the computer. This can be run from the Client Access server itself, as well as from an automated monitoring tool such as SCOM. When using the Test-OutlookConnectivity cmdlet, ensure that the Mailbox database has the RPCClientAccessServer property set to the Client Access server array name. Otherwise the cmdlet won’t test the shared ASA credential functionality.

Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp

To make sure that the connection is made using Kerberos, view klist.exe to see if there are Kerberos tickets associated with the new SPNs that were added.

Validating Kerberos from the Client Access Server

To confirm that Kerberos is working correctly from the Client Access server, you can examine the protocol logs to verify successful Kerberos connections. You can use these logs in addition to the other validations to confirm that Kerberos is being used.

  • On the Client Access server, examine the Address Book protocol logs. These logs are typically located at the following path: C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBook Service.

  • Examine the latest log file and look for the word Kerberos after the script has been run. If you see Kerberos traffic, a connection has been made successfully. The line in the log file should look something like the following.

    2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,

If you see the word Kerberos, then the server is successfully creating Kerberos authenticated connections. For more information about the Address Book service log, see Understanding the Address Book Service.

Troubleshooting Authentication Failures

There are several common problems that may occur when you're configuring Kerberos authentication.

Outlook Clients Configured to use Kerberos Authentication Only Can't Connect

If your Outlook client that's configured to use only Kerberos authentication can't connect, follow these troubleshooting steps:

  1. Configure Outlook to use NTLM authentication only, and then verify connectivity. If a connection can't be made, verify that the Client Access server array is available or that network connectivity is stable.

    If NTLM connectivity is successful, but Kerberos is not, verify that the SPNs aren't registered on any other account besides the alternate service account. Make sure that the Exchange SPNs are registered on the account used by the shared alternate service account by using the setSPN query command as described earlier in this topic.

  2. Make sure that the password is coordinated between all Client Access servers and Active Directory. To do this, run the script in attended mode and have it generate a new password.

  3. Make sure that the Microsoft Exchange Address Book service is running on your Client Access servers.

  4. If authentication still isn't successful, make sure that the virtual directories for the services you want to access with Kerberos have Integrated Windows authentication enabled. You can use the Get-VirtualDirectory cmdlets to verify the authentication methods. For more information on virtual directories, see Understanding Outlook Web App Virtual Directories and Understanding Exchange Web Services Virtual Directories.

Autodiscover Service Failures

If you notice the following Autodiscover service failure, it's probably because the Autodiscover service request header contains a large Kerberos authentication ticket that caused the header size to exceed the limit configured by the Internet Information Services (IIS) server. The error will be similar to the following.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

To fix this error, increase the IIS header size limit. For more information, see IIS documentation.

Ongoing Maintenance of the ASA Credential

If your local password on the shared ASA credential must be refreshed periodically, see Using the RollAlternateserviceAccountPassword.ps1 Script in the Shell for instructions for 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.

Turning Kerberos Authentication Off

To revert your Client Access server array so that it doesn't use Kerberos, remove the SPNs from the shared service account. If the SPNs are removed, Kerberos authentication won't be attempted by your clients, and clients configured to use Negotiate authentication will use NTLM. Clients configured to use only Kerberos will be unable to connect. Once the SPNs are removed you should also delete the shared service account. You can use the maintenance script to clean out credentials from all Client Access server array members by using the toEntireForest parameter and using the -copy from server parameter to specify a server that does not have any Kerberos credentials. In addition, you should eventually restart all client computers to clear the Kerberos ticket cache.

 © 2010 Microsoft Corporation. All rights reserved.