使用智能卡登录 Outlook Web Access

移动员工是 IT 组织面临的最为独特的安全挑战。远程用户需要对数据和服务（如电子邮件）进行安全访问。然而遗憾的是，现实中

安全链最为薄弱的环节往往与脆弱的密码、恶意软件（如击键记录器），以及访问您所在组织内部资源的远程计算机上的病毒有关。

提高这种移动环境安全性的其中一种方法是去掉这其中的某一个薄弱环节：密码（虽然允许在访问某个帐户时不使用密码进行身份验证可能会带来麻烦）。用于解决密码相关问题的主要技术便是双重身份验证（或有时为多重身份验证）。双重身份验证在启用访问时不是依赖一种单一的方法（密码），而会使用额外的身份验证方法，包括用户名/密码的组合、物理设备（如智能卡），或生物特征识别码（如指纹）。

如果您有远程用户，通常会稍稍开启您的防火墙以便允许远程用户访问公司网络。标准的防火墙通过提供内部网络和外部网络间网络级的隔离来提供基本的风险缓解（参见图 1）。为增强安全性，只能关闭端口，如若需要与内部网络中的设备进行通信，就将端口映射到正确的位置。这些技术确实提供了足够的网络级保护，但由于攻击技术不断发展成熟，多层网络安全性就变得非常必要了。

图 1 端口被阻止或被映射的标准防火墙 (单击该图像获得较小视图)

图 1 端口被阻止或被映射的标准防火墙 (单击该图像获得较大视图)

既然移动员工最常使用的公司服务是电子邮件和消息传送，因此将您的 Exchange 基础结构进行安全配置就变得比任何时候都重要了。让您的用户通过 Outlook^® Web Access (OWA) 访问电子邮件是为移动员工提供安全服务的一种方法。通过智能卡为 OWA 提供更为安全的双重身份验证是另一个关键步骤。在本文中，我们将进一步说明您在启用自己的使用智能卡的 OWA 部署中应当注意的问题。

在您的网络中使用 Microsoft^® Internet Security and Acceleration (ISA) Server 2006 可以简化向远程用户开放网络这一任务，而且更为安全。ISA Server 2006 包含一些安全增强功能，如启用智能卡的虚拟专用网络 (VPN)、到 Active Directory^® 的轻型目录访问协议 (LDAP) 身份验证，以及 Kerberos 约束委派。ISA Server 与您想象的传统防火墙稍有不同。它不仅通过在网络层提供多层安全性——这可以代替或与标准的防火墙硬件结合使用——而且还提供传统防火墙通常不支持的一些其他安全功能，如应用程序筛选器。不想让某个人在特定托管网站上使用 HTTP POST 方法？想要在 SMTP 消息接触您的 Exchange 服务器之前在其上强制实行 RFC 遵从性？想要在加密的安全套接字层 (SSL) HTTP 数据包进入网络前对其进行检查？ISA Server 可以管理所有这些以及更多的任务，从而确保只有干净的、经筛选的通信可以被转发到您的 DMZ 或内部网络中。

对于标准防火墙来说，SSL 会话是一个大问题。当数据包通过防火墙时，它们会保持加密状态（这意味着 SSL 正常工作）。因此，如果一个应用程序（如 OWA）通过使用 SSL 的硬件或软件防火墙进行发布，那么除了状态数据包检查外，标准防火墙便不能执行其他真正有效的检查了。这种仅仅是打开和映射端口会极大地增加受攻击的机会。由于在边缘处没有进行真正的检查，未经检查和身份验证的数据包便可传送到您的内部网络中。

ISA Server 2006 可以作为 HTTP 客户端的 SSL 终结点，确保只有经过身份验证的通信可以到达已发布的 Exchange 服务器。ISA Server 支持一个名为 SSL 桥接的有用功能。通常数据包是由通过一个标准的 SSL 会话与 ISA Server 进行通信的客户端进行加密的。有了 SSL 桥接功能，ISA Server 就可以本地终止 SSL 加密，检查当前未加密的数据包，对 Active Directory 的用户进行身份验证（如果需要），使用 SSL 对数据包重新进行加密，然后将加密后的数据包传送到相应的 Exchange 服务器上（参见图 2）。使用这种技术，SSL 桥接可以缓解 SSL 会话中隐藏的攻击，而这些攻击对于那些应用程序不敏感的防火墙来说只不过是一些加密的数据 Blob。

图 2 ISA Server 从应用程序层的角度来看待通信 (单击该图像获得较小视图)

图 2 ISA Server 从应用程序层的角度来看待通信 (单击该图像获得较大视图)

提到 Kerberos 约束委派，到达服务器的经过预先身份验证的通信是十分值得注意的一点。在标准的防火墙中，端口只是简单地映射到 Exchange 服务器，并且由前端服务器自身来执行身份验证任务以防止恶意用户。当需要进行身份验证时，ISA Server 可以直接联系 Active Directory，并代表用户请求获得凭据。如果用户成功通过身份验证，ISA Server 会将消息转发至 Exchange 前端服务器。前端服务器则不再需要对随机的未知用户请求进行身份验证，并可单独用于代理到后端服务器的请求。ISA Server 2006 还可以使用 Kerberos 约束委派来启用到 Windows SharePoint Services 和 Exchange ActiveSync 等技术的基于证书的访问。

Exchange Server 2003 包含对 OWA 登录的前后端服务器之间基于 Kerberos 的身份验证支持。（您是否使用 IPsec 来保护该客户端通信？）Exchange Server 还支持到群集邮箱服务器的 Kerberos 身份验证。

为 OWA 实施基于智能卡的身份验证一直以来都是一项挑战。不过现在 ISA Server 2006 中已有了一个根据 Kerberos 约束委派功能开发的解决方案。该解决方案允许用户通过证书来提交凭据，以便成功通过 OWA 的身份验证。Kerberos 约束委派深受广大用户的欢迎，它是对使用无约束委派、受 Windows^® 2000 支持的 Kerberos 委派的一次改进。Kerberos 的约束功能可以提高安全性，并且限制了使用假冒身份这种更为复杂的攻击的潜在风险。

在启用智能卡的情况下，由于用户无法从外部网络对密钥发行中心 (KDC) 进行可路由的访问，因此 ISA Server 2006 会联系 Active Directory 来对用户进行身份验证。ISA Server 会根据 Active Directory 证书-用户映射来对用户进行身份验证，然后根据用户主体名称 (UPN) 来分别获取相应的 Kerberos 票证。在这种情况下，ISA Server 会通过应用程序级别的筛选和反向代理服务向 Exchange 前端服务器提供 Kerberos 约束委派功能。如果尝试不使用反向代理进行委派，则会增加漏洞攻击的风险，从而影响网络或 Active Directory 域的完整性。

Exchange Server 2003 和 Exchange Server 2007 均允许基本身份验证和集成身份验证。但是您需要对 Exchange Server 2003 进行软件更新，以便启用 OWA 的基于智能卡的身份验证。（有关详细信息，请参阅文章“对 Exchange Server 2003 中支持 Outlook Web Access 智能卡身份验证的新功能的说明”。）您必须拥有一个处于 Windows Server^® 2003 本机功能模式的域，涉及的所有 Exchange Server 2003 服务器必须应用 SP2 或更新的版本，并且必须有一个 ISA Server 2006 服务器作为 OWA 站点的反向代理。

安装软件更新并对 ISA 和 Exchange 服务器进行配置后，便可以使用智能卡对 OWA 会话进行身份验证了。图 3 显示了智能卡验证过程中需要进行的一系列事件。用户先在 Internet Explorer^® 中打开 OWA 站点 (1)。事实上，在启动 OWA 会话时，用户会实际连接到 ISA Server，并且服务器会提示您输入证书而不是用户名和密码。正确的证书存储在智能卡中，用户需要有一个 PIN 才能获取证书。

图 3 使用智能卡对 OWA 进行身份验证 (单击该图像获得较小视图)

图 3 使用智能卡对 OWA 进行身份验证 (单击该图像获得较大视图)

证书验证 (2) 由证书吊销列表 (CRL) 或在线证书状态协议 (OCSP) 请求来处理，这根据 ISA Server 的配置和安装的其他软件而定。ISA Server 会向域控制器 (DC) 发送一个验证用户凭据的请求。如果请求失败，ISA Server 会向用户提供一个错误页面，并且没有请求会到达 Exchange 前端服务器。

凭据经验证后，会生成 Kerberos 票证并会将请求传送至使用集成身份验证的 Exchange 前端服务器 (3)。Exchange 前端服务器收到请求后，会对 Kerberos 票证进行验证并会找到用户的后端邮箱服务器 (4)。

前端服务器会通过 Kerberos 约束委派为相应的后端服务器请求一个 Kerberos 票证，并会将邮箱请求代理到使用集成身份验证的后端服务器 (5)。后端服务器会处理请求 (6)，并会将邮箱数据返回给 Exchange 前端服务器 (7)。OWA 页的 HTML 数据将被传送至 ISA Server (8)，然后数据会返回至客户端机器 (9)。

先前提到的知识库文章对 Exchange Server 2003 软件更新进行了说明，并包含指导您完成使用 ISA Server 2006 和 Exchange Server 2003 启用 Kerberos 约束委派这个过程的信息。

软件更新后启用的主要操作是使从 Exchange 前端服务器到各自的后端服务器的 Kerberos 约束委派过程自动化。由于 ISA Server 不是 Exchange 组织的一部分，因此该项更新不会将从 ISA Server 到前端服务器的 Kerberos 约束委派过程自动化。这种 ISA Server 实例到 Exchange 前端服务器之间的委派需一一手动启用。

软件更新会在 Exchange 系统管理器 (ESM) 中添加一个新的选项卡，该选项卡可让您将某个 Exchange 前端服务器指定为 KCD-FE（参见图 4），这样便可以让该服务器在每个 Exchange 后端服务器的委派选项卡上进行填充。

图 4 启用 Kerberos 约束委派

这个新的 UI 还可让您在管理组属性中指定用哪个凭据来填充 msDS-AllowedToDelegateTo (A2D2) 属性，如图 5 所示。该属性用于进行 Kerberos 约束委派。

图 5 设置控制委派的帐户

根据最低权限原则，您可以使用一个标准的用户帐户，并授予它通过组策略对象 (GPO) 来委派用户和计算机的能力。为帐户授予这个提升的权限后，该帐户便可作为一个服务帐户，使每个管理组的 Kerberos 约束委派过程自动化。

请务必采用正确的步骤，以确保恶意用户无法破坏 Kerberos 约束委派服务帐户。即使帐户不是一个域管理员，利用 Kerberos 委派对其进行访问也可导致受到复杂的攻击。由于帐户具有建立新的 Kerberos 关联的功能，因此使用时应非常小心。为确保帐户的安全性和完整性，应采取必要的措施，如长而复杂的密码、增强审核、帐户停用技术等。

Exchange 软件更新还使 ESM 接口有关集成身份验证方面发生了重大变化。先前在 Exchange Server 2003 中，当某个服务器被指定为前端服务器后，用于启用 HTTP 虚拟目录（HTTP 虚拟服务器下）的集成 Windows 身份验证的选项就会变灰（参见图 6）。

图 6a 更新使得可以使用集成身份验证

图 6b 更新使得可以使用集成身份验证

发生这种情况的原因是，由于技术方面的问题（如代理服务器会中断 NTLM 会话、使用 Kerberos 身份验证的用户需要连接到 Active Directory，以及 Internet 用户通常不属于该域），Exchange 前端服务器不支持集成身份验证。上面提到的知识库文章中所描述的更新取消了这些限制。安装了更新后，您只需转到虚拟目录，然后选中“集成 Windows 身份验证”复选框，将其作为验证用户凭据的机制。选中该复选框后，它会在 Active Directory 中的虚拟目录对象上设置一个名为 msexchAuthenticationFlags 的属性（使用 Microsoft 管理控制台的 Adsiedit.msc 插件可以看到该属性）。

通过 OWA 来检查邮件的用户可能知道他们的 Exchange 后端服务器的名称，并且当他们位于公司内部网络时可以使用集成身份验证连接到这些后端服务器。使用集成身份验证的用户体验的不同之处在于，由于您已经登录到网络中，系统便不会提示您输入用户名和密码了，因为 Internet Explorer 会自动对您进行身份验证并登录到网站中。这一点对于位于公司网络的用户来说是非常棒的，但外部用户（OWA 用户更常见的是外部用户）通常在从网络外部访问 Exchange 前端服务器时不会登录到某个域中。（知识库文章“IIS 如何验证浏览器客户端”中对这个过程进行了详细的说明。）

在 Exchange Server 中，更新会对“委派”选项卡进行填充，以便使用 Active Directory 中的 A2D2 属性，而不是服务主体名称 (SPN)。如果您使用 Adsiedit.msc 来查看 Exchange 计算机对象，您就会注意到两个截然不同的属性：A2D2 属性，它是 Kerberos 约束委派列表；SPN 属性，它是 Kerberos 定位器和帐户规范点。虽然确实是这两个属性同时促成了 Kerberos 约束委派，但您只需通过图形界面修改 A2D2 属性即可。

Windows 可以使用内置的 HOST SPN 作为别名来寻找其他服务。这意味着 Kerberos 约束委派无需使用 setspn.exe 来进行 Exchange 前端到后端的委派。（虽然使用这个解决方案可以在 SPN 属性列表中明确指定 HTTP/Servername，但这会引起更多由管理员造成的错误，并且这也不是 Kerberos 约束委派运行所必需的。）Kerberos 约束委派会在 Active Directory 中查找 A2D2 属性。当未对该属性进行填充（或填充的 SPN 值出错）时，Kerberos 约束委派将不会在各自的服务器间进行。但是在一个 Exchange 群集中，只需将来自前端的 A2D2 属性指向群集节点计算机帐户便可让委派顺利进行。

正如前面提到的，Windows Server 2003 域包含的 Exchange 2003 服务器必须处于 Windows Server 2003 本机功能模式。在未达到这一级别的域功能前，Kerberos 约束委派将不能使用。如果您的域仍处于混合模式，但您安装了前面提到的软件更新，那么委派看似是可以进行的，但 SPN 注册实际上是失败的。Kerberos 约束委派还是一项域功能，而不是林级功能。这意味着，对于 Exchange Server 2003 来说，ISA Server 以及 Exchange 前端和后端服务器必须是同一域中的成员（虽然不同域中的用户仍然可以通过 Kerberos 约束委派的身份验证）。非域成员的 ISA Server 实例，或是其他域中的 ISA Server 实例将不作为该解决方案的一部分运行。

IIS Admin 不可用于针对 OWA 的任何类型的身份验证更改。即使 OWA 是在 IIS 下运行，并且会像任何其他网站一样响应元数据库中的变化，但 Exchange 和目录服务到元数据库 (DS2MB) 进程使事情变得有点复杂。DS2MB 进程会将 Active Directory 中的更改复制到 IIS 元数据库中，这种复制是单向的，它会覆盖先前直接对 IIS 进行的所有更改。该进程造成的影响是，如果管理员直接对 IIS 元数据库进行更改（如设置集成身份验证），该解决方案看似可以正常运行，但是一旦下一次 DS2MB 复制循环开始，解决方案就将被破坏。

ESM 中为 HTTP 虚拟目录启用集成 Windows 身份验证的选项是可用的，因为 ESM 可以直接对 Active Directory 进行编辑，然后将所做的更改复制到 IIS 元数据库中。请记住，虽然停止系统助理服务会停止 DS2MB 进程，以便让您对 IIS 元数据库进行更改而不被覆盖，但我们不建议采用这种方法。系统助理下次启动时，会轮询 Active Directory 中的更改，然后解决方案将自动被停用。

“委派”选项卡显示了“仅使用 Kerberos”选项和“使用任意的身份验证协议”选项。既然我们讨论的解决方案是使用 Kerberos 约束委派的，那么我们就不难知道应该选择“仅使用 Kerberos”，但是许多 IT 组织的情况是不适用这种一般逻辑的。因此，我们应选择“使用任意的身份验证协议”这个选项（如图 7 所示），因为请求并不是作为 Kerberos 请求，而是作为 HTTP 请求进入的，它有一个与之相对应的证书映射到 Active Directory 帐户。

图 7 更正智能卡的身份验证设置

在此例中，ISA Server 是通过 SSL 来请求用户 PKI 证书的。传入的请求不是 Kerberos 票证，因此为了让 Kerberos 约束委派顺利进行，就必须进行转换。因此，指定“仅使用 Kerberos”这种设置将会破坏 ISA Server 上的通信链。但是请注意，“仅使用 Kerberos”选项在 Exchange 前端到后端服务器的委派中是适用的，因为前端服务器只会接收来自 ISA Server 的 Kerberos 票证。

\Exchange 和 \Public 虚拟目录是唯一包含专用用户和公共文件夹信息的位置。Exchange 中的 SSL 配置对于 Kerberos 约束委派或双重身份验证来说都不是新的事物，它是对采用基本身份验证凭据的 OWA 的标准 SSL 启用的一次继承。您应按照文中描述的方法在 OWA 上启用 SSL，因为错误地强制启用 SSL 会破坏 OWA，同时也会使 ESM 出现问题。

实施该解决方案时，先以标准方式部署 ISA Server 和 Exchange 可以让工作变得更加简单。请不要实施整个 Kerberos 约束委派解决方案并配置所有设置（特别是在部署中还没有 ISA Server 时）。这样会使得当处理过程中的某个组件或步骤出现故障时的故障排除过程变得更为复杂。而以标准方式（使用用户名和密码，但不使用基于表单的身份验证）部署 ISA Server 和 Exchange 可以让工作变得更加简单，可确保安装可以正常工作，然后转换为 Kerberos 约束委派和证书身份验证。

一般来说，基于表单的身份验证不能与启用智能卡的 OWA 一同使用。基于表单的身份验证需要用户通过标准的 Outlook 表单提交用户名和密码。但是使用基于智能卡的双重身份验证，用户将只拥有一个智能卡而没有密码。因此基于表单的身份验证就不具有任何通过仅接受或提交证书来进行身份验证的方法。在通信链中的任何一处（例如在 ISA Server 后的某个前端服务器上）使用基于表单的身份验证都将破坏启用智能卡的 OWA 配置。如果您启用基于表单的身份验证，Exchange 虚拟目录将被强制设置为“基本”身份验证，同时 IIS 元数据库也将被设置为“基本”身份验证。

如果您的用户既有用户名/密码又有智能卡，则您可以在 ISA Web 侦听器上启用回退身份验证，当用户在收到提示输入基于证书的凭据的信息后点击 ESC 按钮时，系统将提示输入标准的用户名/密码凭据，即使在 Exchange 服务器上的 ISA Server 后启用了集成身份验证也如此。此外，ISA Server 可让 SSL 会话超时，该功能与基于表单的身份验证类似。

支持用智能卡来为 OWA 进行身份验证是 Exchange Server 2003 和 Exchange Server 2007 中的一项深受广大用户欢迎的新增功能。有了这种使用证书登录 OWA 的能力，用户就不再需要为记住那些又长又复杂的密码而担心，而管理员现在也有了有效的工具来防止击键记录器和其他形式的恶意软件，避免了它们从受感染的系统中找到用户凭据的风险。有关详细信息，请参见侧栏上的“资源”。

为使用智能卡的双重身份验证正确配置 ISA Server，通过在已发布的 OWA 应用程序上实施应用程序级的筛选，可以进一步增强总体的安全性。此外，ISA Server 2006 内置了对通过简单的发布向导来发布 Exchange Server 2003 和 Exchange Server 2007 的支持，因此对于正在转为使用 Exchange Server 2007 的组织来说，先前对 ISA Server 所做的投资依然有效。