Exchange 访问控制过程的详细内容

上一次修改主题： 2006-12-04

正如访问 Exchange 对象中所述，Microsoft® Exchange 通过两个步骤来控制对 Exchange 存储中项目的访问权限：

• 初步检查   这些检查简化了访问控制过程。某些类型的用户始终具有对 Exchange 存储中项目的完全访问权限（除公用文件夹中的管理任务以外），因此没有必要进一步检查，用户将被授予对所请求项目的访问权限。此外，如果需要后续访问检查（例如，合法用户请求对公用文件夹的管理性访问权限），初步检查将确定用于后续访问权检查的权限组。
• 对象级访问控制   Exchange 存储中的每个对象（邮箱、文件夹或邮件）都有一组安全描述符。每个安全描述符是包含有关有权访问对象的用户和每个用户的访问类型的信息的一种属性。附加控制用于控制对特殊对象的访问，如公用文件夹树（与单个公用文件夹相反），以及对已启用邮件的公用文件夹的额外属性的访问。

执行初步检查

Exchange 使用一组初步检查，来确定用于对象级访问控制检查的检查（如果有）。

注意：
本部分介绍两个初步检查。Exchange 执行另一个初步检查以确定用户是否正在请求对文件夹或邮件属性的访问权限。但是，有关 Exchange 用于对单个属性实施访问控制的机制的全面讨论不在本书所述范围之内。

确定用户类型

当用户尝试访问 Exchange 存储中的对象时，在检查文件夹或邮件级的访问控制设置之前，Exchange 将首先检查以确定该用户是否是下列用户类型之一：

• 邮箱所有者（仅对于邮箱）   邮箱所有者对其邮箱和邮箱中的所有文件夹和邮件具有完全访问权限。不执行其他检查。
• Exchange 管理员（完全控制）   当使用管理应用程序时，管理员（完全控制）具有对 Exchange 存储中的所有对象的完全访问权限，并且不执行其他检查（请求对公用文件夹执行管理任务时除外 － 请参阅本主题后面的“确定客户端应用程序的类型”部分）。
• Exchange 管理员（仅查看）   当使用管理应用程序时，管理员（仅查看）有权读取 Exchange 存储中的所有对象，并且在授予用户此级别的访问权限之前不执行其他检查。有关管理应用程序的详细信息，请参阅“确定客户端应用程序的类型”。

确定客户端应用程序的类型

当用户请求访问公用文件夹或公用文件夹中的邮件时，Exchange 将检查该用户是否符合前部分所描述的用户类型之一。Exchange 还将检查用户正在运行的应用程序类型。Exchange 执行这些检查，以便确定后续访问检查应该使用控制常规客户端访问的安全信息，还是使用控制管理客户端访问的安全信息。Exchange 分别存储这两种安全信息（如本主题后面的“对象级访问控制解析”部分所述）。

注意：
如果请求访问公用文件夹或公用文件夹中邮件的用户正在运行管理应用程序，但该用户不符合前部分所描述的用户类型之一（例如，非所请求对象的所有者的最终用户），Exchange 将忽略该用户对管理访问权限的请求，而视为该用户正在使用常规客户端应用程序。

如访问 Exchange 对象中所述，Exchange 将在客户端应用程序（如 Microsoft Outlook®）中执行的操作视为客户端操作（需要常规客户端访问权限），即使用户可能认为该操作为“管理”。例如，当用户更改公用文件夹的权限时，如果用户使用 Outlook 更改权限，Exchange 将该操作视为客户端操作（需要常规客户端访问权限）。但是，如果用户使用 Exchange 系统管理器（一种管理应用程序）更改公用文件夹的权限，Exchange 将该操作视为管理（需要管理客户端访问权限）。客户端操作和管理操作之间的差别可防止意外锁定。Outlook 用户（甚至是文件夹所有者）不能修改控制 Exchange 系统管理器访问的权限，从而避免阻止管理员使用 Exchange 系统管理器访问公用文件夹。

• 如果正在开发自定义应用程序，Exchange 需要能够识别其是管理应用程序还是最终用户应用程序。有关详细信息，请参阅在 Microsoft Exchange Software Development Kit (SDK) 的“Exchange Store URLs”中的“Using the Administrative Virtual Root”主题，以及“Using the Administrative Virtual Root”中的“Exchange Management Security”主题（适用于 Exchange 2000 Server 或 Exchange Server 2003）。可以从 Exchange Server MSDN 网站下载或联机查看 Exchange SDK。
• 有关如何建立对象所有权的其他信息，请参阅 Exchange SDK 中的“Access Control”和“Security”主题。

对象级访问控制解析

要理解 Exchange 处理访问控制的方式，有必要检查在 Microsoft® Windows 2000 安全模型（由 Exchange 扩展和修改）中实现的访问控制的基础要素。

如果正在开发自定义应用程序，Exchange 需要能够识别其是管理应用程序还是最终用户应用程序。有关详细信息，请参阅 Exchange SDK 中有关 Properties by Namespace的主题。

有关使用文件夹和邮件的安全描述符的信息，请参阅 Exchange SDK 的“Reference”中的“Application Security Module Reference”。

安全描述符

Exchange 存储中的每个对象（邮箱、文件夹或邮件）都有两种安全描述符：

• Windows NT 安全描述符   Windows 2000 系统中的每个对象都有一个 Microsoft Windows NT® 安全描述符。在 Exchange SDK 中作为“ntsecuritydescriptor”字段（或为作为 ptagNTSD 属性）描述的此安全描述符，适用于用户对对象执行的大多数操作（如读取或编辑邮件）。
• 管理安全描述符   每个 Exchange Server 2003 对象都有一个管理安全描述符。在 Exchange SDK 中作为 admindescriptor 字段（或作为 ptagAdminNTSD 属性）描述的此安全描述符，适用于管理操作（如创建或删除公用文件夹）。

两种安全描述符包含与 Exchange 相关的相同信息：

• 控制信息（有关安全描述符的信息，如是直接创建了安全描述符，还是通过“默认”机制创建）
• 对象所有者
• 对象所有者所属的主要组
• 随机访问控制列表 (DACL)
• 系统访问控制列表 (SACL)

  注意：
  安全描述符可包含附加信息，但 Exchange 2003 不使用该信息。

有关 Windows 2000 中安全描述符的元素的完整说明，请参阅 Microsoft Windows 2000 Resource Kit（Microsoft Windows 2000 资源工具包）的 Distributed Systems Guide（分布式系统指南）卷第十二章中的“Access Control”（访问控制）。

ACL 和 ACE

在 Windows 2000 的 Exchange 存储中，用于安全描述符中的两个访问控制列表 (ACL)，即随机访问控制列表 (DACL) 和系统访问控制列表 (SACL)，都主要由访问控制条目 (ACE) 的列表组成。SACL 中的 ACE 与审核和通知功能有关，而 DACL 中的 ACE 控制可以对安全对象执行任务的用户，以及每个用户可以执行的任务。本书主要介绍 DACL 中的 ACE。

每个 ACE 包含以下信息（为本书简化了此列表）：

• ACE 类型（“授予访问权限”或“拒绝访问权限”）
• 被授予或拒绝访问权限的用户或组的安全 ID (SID)
• 要授予或拒绝的特定权限（以十六进制访问掩码的形式）
• 标志，指定有关如何处理 ACE 的其他信息。可能的标志值包括：
  • OBJECT_INHERIT_ACE   在此容器内对象应继承 ACE。
  • CONTAINER_INHERIT_ACE   在此容器下面创建的容器应继承 ACE。
  • NO_PROPAGATE_INHERIT_ACE   ACE 只会传播到此容器的直接子级，而不能传播到在直接子级下面创建的容器。
  • INHERIT_ONLY_ACE   ACE 不对此对象生效，而仅对在此对象下面创建的对象生效。
  • INHERITED_ACE   已从父对象继承 ACE。

标志 OBJECT_INHERIT_ACE、CONTAINER_INHERIT_ACE 和 INHERIT_ONLY_ACE 对于 Exchange 管理安全性的方式尤其重要。Exchange 使用这些标志来确定 ACE 是否应用于文件夹或邮件，如下所示：

• 文件夹 ACE 执行 CONTAINER_INHERIT_ACE 标志。
• 邮件 ACE 执行 OBJECT_INHERIT_ACE 和 INHERIT_ONLY_ACE 标志。

ACL 中的 ACE 序列

与标准 Windows NT 安全描述符（“标准”Windows NT 安全描述符由 Active Directory® 目录服务和 Windows 2000 文件系统中的对象使用）使用的 DACL 中的 ACE 序列相比，用于 Exchange 存储中对象的某些 Windows NT 安全描述符使用不同的 DACL 中的 ACE 序列。

对于“应用程序”公用文件夹层次结构，Exchange 支持用于对 ACE 排序的标准 Windows 2000 规则。

但是，基于 MAPI 的客户端（如 Outlook）使用基于 MAPI 的 ACL 格式代替 Windows 2000 格式。为支持这些客户端，Exchange 针对邮箱安全描述符和默认“公用文件夹”层次结构（也称为 MAPI 层次结构）中的文件夹使用一套特殊的规则。由于格式特殊，Windows 将评估用户是否可以通过模拟 Exchange 5.5 的访问控制行为的方式（取决于基于 MAPI 的权限）进行访问。该格式称为 Exchange 规范 ACL 格式（也称为 Exchange 规范安全描述符格式）。

下列规则控制 Exchange 规范 ACL 中 ACE 的序列：

• 每个 ACL 包含应用于文件夹的 ACE 和应用于这些文件夹内的邮件的 ACE。文件夹和邮件 ACE 可混合存在于 ACL 中。
• 对于每个“授予”ACE，应必须存在同一安全主体的一个相应的“拒绝”ACE（除非没有授予或拒绝任何权限）。“授予”ACE 必须位于“拒绝”ACE 之前。
• 用户的所有 ACE 必须位于组的所有 ACE 之前（对应于 Exchange 5.5 通讯组列表）。Everyone 组和 Anonymous 组的 ACE 必须位于序列的最后位置。
• 通讯组的所有“授予”ACE 必须位于这些组的相应“拒绝”ACE 之前。

下表显示 Exchange 规范 ACL 中的 ACE 序列的示例。

Exchange 规范 ACL 中信息的序列示例

由于 ACL 采用此格式，Exchange 可将安全描述符信息转换为 MAPI 客户端（如 Outlook）期待的 MAPI 权限。

当用户对 Outlook 中的邮箱设置权限，或对 Exchange 系统管理器中的邮箱或 MAPI 公用文件夹设置权限时，用户界面将列出与 Exchange 5.5 所用一致的 MAPI 权限和角色。下图显示在 Exchange 系统管理器中出现的对话框。如果正在使用 Outlook，此信息将出现在文件夹的“属性”对话框的“权限”选项卡中。

由于应用程序公用文件夹面向 HTTP 或网络新闻传输协议 (NNTP) 客户端（例如，Outlook Web Access）的访问，因此它们不进行此 MAPI 权限的转换。如下图所示，列出的权限为常规 Windows 2000 权限。有关应用程序公用文件夹（也称为常规用途公用文件夹）的详细信息，请参阅 Exchange Server 2003 管理指南。

注意：
仅使用由 Outlook 提供的“权限”对话框和由 Exchange 系统管理器提供的“客户端权限”对话框修改 MAPI 权限。当使用 Outlook 或 Exchange 系统管理器用户界面编辑 MAPI 权限时，Exchange 会将 MAPI 权限反向转换以存储修改的安全描述符，并保留 Exchange 规范 ACL 格式。但是，如果使用 Windows 文件系统（例如，使用由 Exchange 2000 Server 中的可安装文件系统提供的 M:\ 驱动器）编辑权限，系统将以常规 Windows ACL 格式存储安全描述符。这表示 ACE 将有不同的序列，并且 Exchange 不能再将安全描述符转换为 MAPI 权限。有关此问题的详细信息，请参阅 Microsoft 知识库文章 270905，“无法通过 Exchange 系统管理器公用文件夹上设置客户端权限”。

邮件的默认 ACL

如前所述，每个文件夹安全描述符包含只适用于邮件的 ACE。这些 ACE 统一称作默认邮件 ACL，它们可在不具有自己的安全描述符信息的文件夹中为邮件提供安全性。

当用户打开其中一个邮件时，该邮件将从文件夹安全描述符中动态继承邮件 ACE。如果文件夹安全描述符更改，则文件夹中打开的所有新邮件将立即继承安全描述符更改。已打开的邮件在被保存之前仍保留其原始安全描述符。

Exchange 在数据库的附件（或嵌入邮件）中记录安全描述符，但不使用它。相反，Exchange 存储将对所有附加邮件使用最外部邮件的安全描述符。存储将保留附件上的安全性，以便客户端能够向其他用户发送消息以进行调试。此外，如果用户将附加邮件复制到顶层文件夹，其安全描述符将立即生效。

共存的 Exchange 2003 服务器和 Exchange 5.5 服务器的特殊注意事项

如果部署同时包括 Exchange 2003 服务器和 Exchange 5.5 服务器，则在管理权限（尤其是公用文件夹权限）时，其复杂性将增加一个级别。有关 Exchange 如何在 Exchange 2003 服务器与 Exchange 5.5 服务器之间传递访问控制信息的更详细说明，请参阅 Public Folder Permissions in a Mixed Mode Microsoft Exchange Organization（混合模式 Microsoft Exchange 组织中的公用文件夹权限）。与管理公用文件夹权限相关的要点如下：

• 在 Exchange 5.5 服务器上具有邮箱的任何用户或组必须先在 Active Directory 中拥有帐户，才能在 Exchange 2003 服务器和 Exchange 5.5 服务器之间复制任何数据。

  • 如果用户或组只有 Active Directory 帐户（而不是 Windows NT 4.0 帐户），则该 Active Directory 帐户是“已启用”帐户。
  • 如果用户或组具有 Windows NT 4.0 帐户，则该 Active Directory 帐户是“禁用”帐户。通过 Active Directory 迁移工具创建的此帐户，是将 Active Directory SID 与现有的 Windows NT 4.0 帐户关联的占位符。

    重要提示：
    如果计划在一段时间内在 Windows NT 4.0 中维护用户帐户，然后将这些帐户完全迁移到 Active Directory，则需要创建具有 SID 历史记录的禁用帐户。Active Directory 迁移工具可以将 Windows NT 4.0 SID 迁移到 Active Directory 中新禁用帐户的 sidHistory 属性中。如果日后启用这些帐户，Exchange 可以使用 SID 历史记录来确定在 ACE 中新启用的帐户已替换 Windows NT 4.0 帐户的位置。有关此过程的详细信息，请参阅 Microsoft 知识库文章 316047，“XADM：解决在启用 ADC 所生成的帐户时出现的问题”。

  Exchange 5.5 使用基于 MAPI 的权限，通过 Exchange 目录中用户和组的可分辨名称识别这些用户和组，并使用称为 ptagACLData 的属性存储访问控制信息。Exchange 2003 将访问控制信息复制到 Exchange 5.5 服务器时，将执行下列操作：

  1. 将用户和组的 Active Directory 安全标识符 (SID) 转换为 Exchange 目录中的可分辨名称。
  2. 将 Windows 2000 权限转换为 MAPI 权限。
  3. 将经过转换的访问控制信息存储在 ptagACLData 中。
  4. 将 ptagNTSD、ptagAdminNTSD 和 ptagACLData 复制到 Exchange 5.5 服务器。
     当 Exchange 2003 服务器收到由 Exchange 5.5 服务器复制的数据时，将执行下列操作：
  5. 丢弃 ptagNTSD 和 ptagAdminNTSD 的传入值。此步骤可保护这些属性，避免接收它们在受 Exchange 5.5 控制时可能已发生的任何更改。
  6. 从 ptagACLData 中提取用户和组的可分辨名称，并将其转换为 Active Directory SID。
  7. 从 ptagACLData 中提取权限，并将其转换为 Windows 2000 权限。
  8. 将经过转换的访问控制信息存储在 ptagNTSD 中。ptagAdminNTSD 的原始值则保留不变。
  9. 除非在步骤 b 或步骤 c 的转换过程中出现了问题，否则将丢弃 ptagACLData 的值。如果出现转换问题，则 Exchange 2003 会保留 ptagACLData 的值。

• Exchange 5.5 将权限应用于文件夹。无法像在 Exchange 2003 中一样将权限（项目级权限）明确指定给各个邮件。如果要将文件夹及其内容从 Exchange 5.5 复制到 Exchange 2003，请不要尝试明确设置邮件权限。Exchange 2003 管理权限是为了确保邮件的安全，但是，如果在此情况下尝试更改邮件权限，这些更改将在下一个复制循环中丢失。