配置负载平衡客户端访问服务器的 Kerberos 身份验证

  • 项目

 

适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题： 2016-11-28

要对客户端访问服务器的负载平衡阵列使用 Kerberos 身份验证，必须完成几个配置步骤。有关如何将 Kerberos 与客户端访问服务器阵列或负载平衡解决方案一起使用的详细信息，请参阅将 Kerberos 与客户端访问服务器阵列或负载平衡解决方案一起使用。

在 Active Directory 中创建备用服务帐户凭据

客户端访问服务器阵列中的所有计算机必须共享同一个服务帐户。此外，在数据中心激活方案中可能调用的所有客户端访问服务器也必须共享同一个服务帐户。一般情况下，每个林中有一个服务帐户就足够了。此帐户称为备用服务帐户凭据（ASA 凭据）。

注释注意：
如果您的部署比较复杂并超出下述方案范围，存在管理员委派问题，或者在不同的 Exchange 部署计划中有多个林段，则您必须创建其他帐户。必须为创建的每个帐户单独运行 RollAlternateServiceAccountPasswordl.ps1 脚本。

凭据类型

您可以为备用服务帐户创建计算机帐户或用户帐户。因为计算机帐户不允许交互式登录，它可能拥有比用户帐户更加简单的安全策略，因此是 ASA 凭据的首选解决方案。如果您创建了计算机帐户，实际上密码并不会过期，但是我们仍然建议您定期更新密码。本地组策略可以为计算机帐户指定最长帐户期限，可能有脚本按计划定期删除不符合当前策略的计算机帐户。定期更新计算机帐户的密码可确保计算机帐户不会因为不符合本地策略而遭到删除。您的本地安全策略将决定何时需要更改密码。

凭据名称

没有针对 ASA 凭据名称的特定要求。您可以根据自己的命名方案使用任何名称。

组和角色

ASA 凭据不需要特殊的安全特权。如果您为 ASA 凭据部署计算机帐户，则这表示该帐户只需是域计算机安全组的成员。如果您为 ASA 凭据部署用户帐户，则这表示该帐户只需是域用户安全组的成员。

密码

实际上，永远不会使用您创建帐户时提供的密码。脚本将重置密码。因此，当您创建帐户时，您可以使用符合组织密码要求的任何密码。

跨林方案

如果您有跨林或资源林部署，而用户在包含 Active Directory 的 Exchange 林之外，则您必须配置跨林信任和跨林名称后缀的路由。有关详细信息，请参阅跨林访问资源和跨林路由名称后缀。

识别应与备用服务帐户凭据相关联的服务主体名称

创建备用服务帐户后，必须确定将与 ASA 凭据关联的 Exchange 服务主体名称 (SPN)。Exchange SPN 列表可能因配置而异，但至少应包括以下内容。

  • http 将此 SPN 用于 Exchange Web 服务、脱机通讯簿下载以及自动发现服务。

  • exchangeMDB 将此 SPN 用于 RPC 客户端访问。

  • exchangeRFR 将此 SPN 用于通讯簿服务。

  • exchangeAB 将此 SPN 用于通讯簿服务。

SPN 值必须配置为与网络负载平衡器（而不是单个服务器）上使用的服务名称相匹配。

为帮助规划应部署的 SPN 值，请考虑以下概念性方案：

  1. 单个 Active Directory 站点

  2. 多个 Active Directory 站点

  3. 多个 Active Directory 站点，具有 DAG 站点恢复机制

在每种方案中，都假设已针对内部 URL、外部 URL 和客户端访问服务器成员所使用的自动发现内部 URI 而部署了负载平衡的完全限定的域名。有关详细信息，请参阅 了解代理和重定向。

单个 Active Directory 站点

如果您有单个 Active Directory 站点，则您的环境可能类似于下图所示。

根据上图中的内部 Outlook 客户端所使用的全限定域名，将需要在 ASA 凭据上部署以下 SPN：

  • 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

在任何位置使用 Outlook 的外部或基于 Internet 的客户端将不使用 Kerberos 身份验证。因此，这些客户端所使用的完全限定的域名不必作为 SPN 添加到 ASA 凭据中。

重要重要说明：
如果部署拆分 DNS 基础结构，则外部和内部客户端使用相同的全限定域名，并且这些域名必须在 ASA 凭据上表示为 SPN。

多个 Active Directory 站点

如果您有多个 Active Directory 站点，则您的环境可能类似于下图所示。

根据上图中的内部 Outlook 客户端所使用的全限定域名，必须在用于 Active Directory 站点 ADSite1 内的客户端访问服务器阵列的 ASA 凭据上部署以下 SPN：

  • 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

根据上图中的内部 Outlook 客户端所使用的全限定域名，需要在用于 Active Directory 站点 ADSite2 内的客户端访问服务器阵列的 ASA 凭据上部署以下 SPN：

  • 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

注释注意：
该示例说明您可以将多个 ASA 凭据用于此特定方案。但是，您可以将单个 ASA 凭据用于承载客户端访问服务器阵列（要在其中部署 Kerberos 身份验证）的所有 Active Directory 站点。

具有 DAG 站点恢复机制的多个 Active Directory 站点

如果有多个具有 DAG 站点恢复机制的 Active Directory 站点，则您的环境可能类似于下图所示。

由于该体系结构包含贯穿这两个 Active Directory 站点的数据库可用性组 (DAG)，因此必须部署一个 ASA 凭据，供 ADSite1 和 ADSite2 中的客户端访问服务器阵列的成员使用。如果不使用单个 ASA 凭据，当您执行数据中心切换时，客户端会出现 Kerberos 身份验证问题，因为辅助数据中心客户端访问服务器阵列成员无法解密 Kerberos 会话票证。有关激活辅助数据中心的详细信息，请参阅数据中心切换。

根据上图中内部 Outlook 客户端所使用的全限定域名吗，需要在用于 ADSite1 和 ADSite2 中的客户端访问服务器阵列的 ASA 凭据上部署以下 SPN：

  • 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

将脱机通讯簿虚拟目录转换为应用程序

脱机通讯簿虚拟目录不是现成的 Web 应用程序，因此不由 Microsoft Exchange 服务主机服务控制。因此，无法通过 ASA 凭据解密对脱机通讯簿虚拟目录进行的 Kerberos 身份验证请求。

若要将脱机通讯簿虚拟目录转换为 Web 应用程序，请在每个客户端访问服务器成员上运行 ConvertOABDir.ps1 脚本。该脚本还会为每个脱机通讯簿虚拟目录创建一个新应用程序池。该脚本位于 Exchange 2010 SP2 脚本目录中，也可以在此处下载该脚本。

部署备用服务帐户凭据

创建 ASA 凭据后，验证是否为所有 Active Directory 站点（其中包含将使用此 ASA 凭据的客户端访问服务器）的所有域控制器复制了该帐户。

然后即可在 Exchange 命令行管理程序中运行 AlternateServiceAccount 凭据脚本。有关详细信息，请参阅在命令行管理程序中使用 RollAlternateserviceAccountCredential.ps1 脚本。脚本运行后，建议您验证是否已正确更新了所有目标服务器。

注释注意：
该脚本仅提供英文版本。

有关对脚本错误进行疑难解答的帮助，请参阅对 RollAlternateServiceAccountCredential.ps1 脚本进行故障排除。

以下 RollAlternateServiceAccountPassword.ps1 脚本的输出示例使用创建为 ASA 凭据的计算机帐户。该帐户名为 contoso/newSharedServiceAccountName。在下例中，该脚本将凭据设置应用于名为 outlook.corp.contoso.com 的客户端访问服务器阵列的每个成员。

若要运行脚本，请使用以下命令。

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

运行脚本后，应得到以下输出。会出现一个提示，要求您批准更改密码。

========== 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>

您还会在事件日志中看到两个事件 ID。一个事件表示脚本开始，另一个事件表示成功完成。下面是成功完成事件的摘录内容。

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

验证 ASA 凭据的部署

在 Exchange 命令行管理程序中，运行以下命令以检查客户端访问服务器上的设置。

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

该命令的结果应如下所示。

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>

如果已多次运行脚本并进行了更改，则“上一个”条目会显示上次进行更改的时间。

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$

将服务主体名称与备用服务帐户凭据相关联

配置 SPN 之前，验证并未在林的其他帐户中配置过目标 SPN。ASA 凭据必须是林中与这些 SPN 相关联的唯一帐户。可以验证林中没有其他帐户有与之关联的 SPN，验证方法是从命令行运行 setspn 命令，并使用 –q 和 –f 参数。下例说明了如何运行该命令。该命令不应返回任何内容。如果返回值，则说明已经有其他帐户与您打算使用的 SPN 相关联。

注释注意：
只有 Windows Server 2008 支持 setspn 命令中的全林重复检查参数 (-f)。 
Setspn -q -f exchangeMDB/outlook.corp.contoso.com

以下命令提供了关于如何在共享 ASA 凭据上设置 SPN 的示例。使用该语法的 setspn 命令必须为您标识的每个目标 SPN 运行一次。

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

设置 SPN 后，验证它们是使用以下命令添加的。

Setspn -L contoso\newSharedServiceAccountName$

验证 Exchange 客户端 Kerberos 身份验证

成功配置 Kerberos 并部署 RollAlternateServiceAccountPasswordl.ps1 脚本后，验证客户端可成功进行身份验证。

验证 Microsoft Exchange 服务主机服务是否正在运行

客户端访问服务器上的 Microsoft Exchange 服务主机服务负责管理 ASA 凭据。如果该服务未运行，则无法进行 Kerberos 身份验证。默认情况下，该服务配置为当计算机启动时自动启动。确保您已在环境中的所有客户端访问服务器上安装了 Exchange Server 2010 SP1 更新汇总 3 或更高版本。

从 Outlook 中验证身份验证

要确保 Outlook 能够连接到启用 Kerberos 身份验证的客户端访问服务器，请执行以下步骤：

  1. 确认 Outlook 已配置为指向正确的负载平衡客户端访问服务器阵列。

  2. 配置电子邮件帐户服务器安全设置，以使用登录网络安全“协商身份验证”。或者，可以配置客户端使用“Kerberos 密码身份验证”。但是，如果 SPN 总是被删除，则在您将身份验证机制改回“协商身份验证”之前，客户端将无法进行身份验证。

  3. 确认未对客户端启用 Outlook Anywhere。如果 Outlook 无法使用 Kerberos 进行身份验证，则它将尝试退回到 Outlook Anywhere，因此应该对此测试禁用 Outlook Anywhere。

  4. 重新启动 Outlook。

  5. 如果您的台式计算机运行的是 Windows 7，可以运行 klist.exe，以了解已授予并使用哪些 Kerberos 票证。如果未运行 Windows 7，可以从 Windows Server 2003 资源工具包获取 klist.exe。

使用 Test-OutlookConnectivity Cmdlet 进行验证

要测试 Kerberos 工作是否正常，使用 Test-OutlookConnectivity cmdlet。这是了解是否可以建立 TCP 连接的最佳方式。默认情况下，该 cmdlet 将使用协商身份验证来进行 TCP 连接。因此，如果配置了 Kerberos，就会使用 Kerberos。可以使用文件 klist.exe 查看计算机中的 Kerberos 票证。这可以从客户端访问服务器本身运行，也可以从自动监视工具（如 SCOM）运行。在使用 Test-OutlookConnectivity cmdlet 时，请确保邮箱数据库的 RPCClientAccessServer 属性设置为客户端访问服务器阵列名称。否则该 cmdlet 不会测试共享 ASA 凭据功能。

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

要确保该连接是使用 Kerberos 建立的，可以查看 klist.exe 以了解是否有与添加的新 SPN 关联的 Kerberos 票证。

从客户端访问服务器验证 Kerberos

要从客户端访问服务器确认 Kerberos 工作正常，可以检查协议日志以验证 Kerberos 成功连接。除其他验证外，您可以使用这些日志来确认 Kerberos 正在使用中。

  • 在客户端访问服务器上，检查通讯簿协议日志。这些日志通常位于以下路径：C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBook Service。

  • 运行脚本后，检查最新的日志文件并查找 Kerberos 一词。如果看到了 Kerberos 流量，则说明已成功建立连接。日志文件中的行应如下所示。

    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,

如果您看到 Kerberos 一词，则表示服务器成功创建了进行 Kerberos 身份验证的连续。有关通讯簿服务日志的详细信息，请参阅了解通讯簿服务。

对身份验证失败进行故障排除

配置 Kerberos 身份验证时，可能会出现一些常见问题。

配置为仅使用 Kerberos 身份验证的 Outlook 客户端无法连接

如果配置为仅使用 Kerberos 身份验证的 Outlook 客户端无法连接，请执行以下故障排除步骤：

  1. 将 Outlook 配置为仅使用 NTLM 身份验证，然后验证连接。如果无法建立连接，请验证客户端访问服务器阵列是否可用或网络连接是否稳定。

    如果 NTLM 连接成功，而 Kerberos 连接失败，请验证没有在除备用服务帐户之外的任何其他帐户上注册 SPN。按照本主题前面介绍的方法使用 setSPN 查询命令，确保在共享备用服务帐户使用的帐户上注册了 Exchange SPN。

  2. 确保在所有客户端访问服务器和 Active Directory 之间对密码进行了协调。为此，在有人值守模式下运行脚本，并使其生成新密码。

  3. 确保客户端访问服务器上正在运行 Microsoft Exchange 通讯簿服务。

  4. 如果仍不能成功进行身份验证，请确保您要通过 Kerberos 访问的虚拟目录启用了集成 Windows 身份验证。可以使用 Get-VirtualDirectory cmdlet 来验证身份验证方法。有关虚拟目录的详细信息，请参阅了解 Outlook Web App 虚拟目录和了解 Exchange Web 服务虚拟目录。

自动发现服务失败

如果发现以下自动发现服务失败，可能是因为自动发现服务请求标头包含大型的 Kerberos 身份验证票证，该身份验证票证导致标头大小超过了 Internet 信息服务 (IIS) 服务器配置的限制。该错误将如下所示。

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""https://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>

要解决此错误，请提高 IIS 头的大小限制。有关详细信息，请参阅 IIS 文档。

ASA 凭据的日常维护

如果您在共享 ASA 凭据上的本地密码必须定期刷新，请参阅在命令行管理程序中使用 RollAlternateserviceAccountCredential.ps1 脚本以了解有关如何设置计划任务以执行常规密码维护的说明。请务必监视计划任务，以确保密码及时滚动并防止发生可能的身份验证中断。

关闭 Kerberos 身份验证

若要恢复客户端访问服务器阵列，使其不使用 Kerberos，请从共享服务帐户中删除 SPN。如果删除了 SPN，则客户端不会尝试进行 Kerberos 身份验证，并且配置为使用协商身份验证的客户端会使用 NTLM。配置为仅使用 Kerberos 的客户端将无法连接。删除了 SPN 之后，您还应删除共享服务帐户。可以通过维护脚本，使用 toEntireForest 参数从所有客户端访问服务器阵列成员清除凭据，或使用 -copy 在服务器参数中指定没有任何 Kerberos 凭据的服务器。此外，最后应重新启动所有客户端计算机，以清除 Kerberos 票证缓存。

 © 2010 Microsoft Corporation。保留所有权利。