基于 Active Directory 的环境中的自动发现流程 |第 15 部分#36

在下面的文章中，我们将深入了解在基于 Active Directory 的环境中实现的自动发现方法。
在基于 Active Directory 的环境中，Outlook 等自动发现客户端查找可用自动发现端点的过程通过将 Active Directory 寻址为可用自动发现端点（可用 Exchange 服务器）的信息源来执行。

可用的自动发现方法

一般来说，自动发现方法主要有两种：

1. Active Directory 环境中的自动发现
2. 非 Active Directory 环境中的自动发现方法

如果安装 Outlook 客户端的用户桌面配置为域成员，Outlook 将允许通过在查询中寻址本地 Active Directory 来启动自动发现过程。

如果没有找到 Active Directory 的选项，Outlook 客户端将“继续”到下一个自动发现方法（在下一篇文章中 - Exchange 本地环境中的自动发现流程 | 非 Active Directory 环境 | 第 1 部分# 3 | 第 26#36 部分，我们将详细回顾此方法）。

在域环境中创建新的 Outlook 邮件配置文件

本地 Active Directory 环境中自动发现过程最突出的特征之一是我们可以将此过程描述为完全自动化。

在将用户桌面配置为域成员的情况下，需要创建新 Outlook 邮件配置文件的用户的唯一要求是打开 Outlook。

很短的时间后，所有必需的设置将自动“传递”到 Outlook 客户端，用户可以访问他的邮箱并开始阅读他的电子邮件等。

唯一的问题是——这种“魔法”是如何发生的？

答案是，自动发现旨在简化从“自动发现端点”获取所需信息（配置设置）的过程，并且此过程在本地 Active Directory 环境中变得更加简化。

在非 Active Directory 环境中，当用户需要创建新的 Outlook 邮件配置文件时，用户需要提供以下详细信息。

1. 用户电子邮件地址
2. 用户凭证

在 Active Directory 环境中，用户不需要提供任何详细信息，因为在域环境中，该过程基于用户缓存凭据。

1. 凭据（用户名 + 密码）在 Active Directory 环境中，由于用户在登录域时已经提供了凭据，因此这些凭据会自动发送到 Exchange On-Premise 服务器。 （技术术语是缓存凭证或访问令牌）
2. 提供用户电子邮件地址
   在用户登录组织域的情况下，系统会自动从本地 Active Directory 用户帐户“拉取”或“提取”用户电子邮件地址。换句话说：创建新 Outlook 邮件配置文件的用户不需要提供他的电子邮件地址。
3. 从 Exchange 服务器获取所需的配置信息
   Outlook 获取创建新 Outlook 邮件配置文件所需的配置信息的过程也是“自动发生的”。

Outlook 查询本地 Active Directory 并询问 Exchange CAS 服务器列表。
获取现有 Exchange 服务器的名称后，Outlook 将尝试连接列表中的一台 Exchange 服务器。

如前所述，用户需要提供自动实现的 Exchange 服务器的电子邮件和用户凭据。

Exchange 服务器验证用户身份并且 Outlook 验证 Exchange 服务器的身份后，Exchange 使用 Autodiscover.xml 文件向 Outlook 客户端发送所需的配置设置。

本地 Active Directory 作为信息源

Active Directory 最显着的优点之一是，Active Directory 充当她的客户的“公告板”。

提供特定服务的服务器可以在 Active Directory 中注册自己，并通过这样做将 Active Directory 用作信息的“板”。

Active Directory 客户端可以对 Active Directory 进行寻址（使用 LDAP 查询）并询问有关特定服务的信息、提供该服务的主机是谁等。

在我们的场景中，Exchange CAS 服务器将自己在 Active Directory 中注册为可以提供自动发现服务的“实体”。

本地 Active Directory 通过使用名为 SCP（服务连接点）的文件夹为此目的分配专用位置（本地 Active Directory 系统分区的一部分）。

在下图中，我们可以看到此过程的示例。
每次安装新的 Exchange On-Premise 时，Exchange On-Premise 都会访问 Active Directory 并“报告其自身情况”。 ”

术语“自动发现客户端”可以翻译为自动发现客户端，例如 Outlook，需要找到自动发现端点以创建新的 Outlook 邮件配置文件和用于其他目的，但同时，“自动发现客户端”可以是“其他 Exchange 服务器。 ”

例如，Active Directory 站点 A 中的 Exchange 服务器需要获取 Active Directory 站点 B 中的 Exchange CAS 服务器“表示”的信息。

SCP（服务连接点）的物理位置

为了能够找到 SCP 的“物理路径”，我们可以使用安装在每个 DC 服务器上的站点和服务工具。

在“查看”选项卡中启用“查看服务节点”选项后，我们可以看到本地 Active Directory 配置分区的物理路径。

SCP 对象可以在 AD 中的以下路径中找到：
CN=exchangeserver,CN=Autodiscover,CN=Protocols,CN=exchangeserver,CN=Servers,CN=Exchange 管理组 ( FYDIBOHF23SPDLT)、CN=管理组、CN=组织名称、CN=Microsoft Exchange、CN=服务、CN=配置、DC=域、DC=com

每个 Exchange CAS 服务器都有“自动发现文件夹”，自动发现文件夹充当自动发现端点对象（特定的 Exchange CAS 服务器）的容器。

为了能够查看特定自动发现端点（在我们的示例中为 ex01）的属性，我们可以右键单击 Exchange CAS 服务器名称并选择菜单属性。

名为 - ServiceBindingInformation 的属性

名为 -Keywords 的属性包含特定 Exchange CAS 服务器的 Active Directory 站点名称。

创建新的 Outlook 邮件配置文件 |神奇背后的过程！

在下面的部分中，我们将分析Active Directory环境中自动发现的过程。

由于自动发现方法是在 Active Directory 环境中实现的，因此“创建新的 Outlook 邮件配置文件”任务是一项非常简单的任务，任何用户都可以在几秒钟内完成部署。

真正的魔力在于，在幕后，“简单的任务”被“翻译”得过于复杂和智能的基础设施，有助于使这个过程显得“简单而容易”。

任务描述

一个组织用户，得到一个新的桌面，用户双击Outlook图标，几秒钟后，Outlook配置文件成功完成，用户可以看到他的邮件，发送和接收邮件等。

在下一节中，我们将回顾导致上述结果的事件顺序

阶段 1 - 查询本地 Active Directory

自动发现客户端与Active Directory之间的通信通过LDAP协议实现。

第1步 - 客户端查询本地Active Directory

自动发现客户端 (Outlook) 创建 LDAP 查询并对本地 Active Directory 进行寻址，请求现有自动发现端点的 URL 地址列表。
换句话说 - 可用 Exchange CAS 服务器的列表

第 2 步 - Active Directory 查看 SCP 分区，查找名为 - ServiceBindingInformation 的属性值

Active Directory SCP 包含不同或专用的 ServiceBindingInformation

Exchange CAS 服务器自动发现 URL 使用以下格式实现：
https://cas_server.domain/Autodiscover/Autodiscover.xml

Exchange CAS 服务器名称是内部 Exchange 服务器名称（FQDN - 完全限定域名）

在我们的示例中，在 Active Directory SCP 上注册的 Exchange CAS 服务器的内部 FQDN 是 - ex01.0365info.com ，自动发现 URL 将为：
https://ex01.0365info.com/autodiscover/autodiscover.xml

Active Directory“返回”给自动发现客户端的附加信息描述为 - 关键字

“关键字”包含有关 Exchange CAS 服务器 Active Directory 站点名称的信息。
（Exchange CAS 服务器所在的 Active Directory 站点名称）。

当自动发现客户端 (Outlook) 从 Active Directory 获取列表时，自动发现客户端将首选寻址 Exchange CAS 服务器，该服务器具有与自动发现客户端所属的 Active Directory 站点相同的 Active Directory 站点值。

在这种方法中，自动发现客户端更愿意联系特定的 Exchange CAS 服务器而不是其他 Exchange CAS 服务器，描述为 - 站点关联性

阶段2 - 查询本地DNS服务器

步骤 3 - 自动发现客户端需要获取 Exchange CAS 服务器的内部 IP 地址。自动发现客户端连接内部 DNS 服务器。在我们的示例中，查找名为 - ex01.o365info.lcoal 的主机的 IP 地址

第 4 步 - DNS 服务器回复（应答）DNS 查询并发送指定主机名的内部 IP 地址（在我们的示例中为 192.168.1.10）。

第 3 阶段 - 相互验证过程

在此阶段，客户端（Outlook）和“服务器”（Exchange CAS 服务器）需要相互识别。

第 5 步 - Outlook 要求 Exchange CAS 服务器通过提供证书来证明其身份。

第 6 步 - Exchange CAS 服务器将其证书发送给客户端，客户端验证 Exchange CAS 服务器证书。

注意 - 如果您想了解有关自动发现过程、证书和安全通信链接的更多详细信息，请阅读文章 - 自动发现过程和 Exchange 安全基础结构 |第 20 部分#36

第 7 步 - 如果 Exchange 证书“正常”，则客户端将其“身份”（用户凭据）发送到 Exchange CAS 服务器。

第8步 - 如果用户凭据正确，则相互身份验证和识别过程完成。

阶段 4 - 使用 RPC 或 HTTP/S 与 Exchange CAS 服务器通信

步骤 9 - 邮件客户端 (Outlook) 向自动发现端点（Exchange CAS 服务器）请求自动发现信息（Autodiscover.xml 文件）

第10步 - Exchange服务器根据Outlook版本软件“生成”配置文件，并将其保存到名为 - Autodiscover.xml的文件中

步骤 11 - Outlook 客户端获取配置文件并创建一个新的 Outlook 邮件配置文件，其中包含所有必需的配置设置。

在 Active Directory 环境中自动发现图表表示

在下图中，我们可以看到与自动发现过程相关的客户端“决策表”的表示。

我们不会详细介绍图中的所有细节，但我将仅回顾并强调 Active Directory 环境中自动发现过程的某些部分。

步骤 1 - 自动发现方法完全依赖于应在 Active Directory 的 SCP 分区中注册的信息。

换句话说，Active Directory 是“信息源权威”，用于向自动发现客户端提供有关可用自动发现端点的信息。

第 2 步 - 如果 Exchange 组织包含多个 Exchange CAS 服务器，自动发现客户端的答案将包含“可选自动发现端点”列表。

自动发现客户端将需要实现某种方法来为他选择最“合适”的自动发现端点。

这种方法被描述为“站点亲和力”。自动发现客户端将“更喜欢”与他位于同一 Active Directory 中的自动发现端点。

注意：术语“与他位于同一 Active Directory 站点”并不准确，因为在某些情况下，我们可以将特定的 Exchange CAS 服务器“注册”为“属于”的 Exchange 服务器特定的 Active Directory，而 Exchange CAS 服务器物理位置位于 Active Directory 站点。

步骤 3 和步骤 4.1 - 如果自动发现客户端获取可用自动发现端点的列表，则客户端将尝试与“第一个自动发现端点”通信，并且如果自动发现端点不可用，“移动”到列表中的下一个自动发现端点，依此类推。

步骤 5.1、5.2、5.3 和步骤 6 是在开始自动发现端点向其自动发现客户端提供所需信息的阶段之前需要成功完成的步骤。

自动发现端点必须确保自动发现端点可以信任，反之亦然 - 自动发现端点必须识别自动发现客户端。

第 7 步 - 自动发现端点（Exchange CAS 服务器）生成所需信息（自动发现响应）并将其发送到自动发现客户端 (Outlook)。

第 8 步 - 这是“幸福的结局阶段”，其中 Outlook 客户端“获取”信息并使用它来创建新的 Outlook 邮件配置文件。