Exchange 本地环境中的自动发现流程 |非Active Directory环境|第 2#3 部分 |第 27 部分#36

在当前文章中，我们回顾了自动发现客户端在“非 Active Directory 环境”中使用的自动发现算法。 ”
自动发现工具箱提供了多种方法，自动发现客户端在尝试定位其自动发现端点时可以使用这些方法。

自动发现之旅的本质

自动发现客户端实现的“自动发现旅程”的主要目的是找到他的自动发现端点。

从技术上讲，自动发现客户端会在多种类型的场景中初始化自动发现进程以及不同类型的自动发现客户端。

因此，我们需要关注各种可能场景的具体示例。

为了演示非 Active Directory 环境中的自动发现过程，我们将在描述为非 Active Directory 环境的环境中查看需要创建新 Outlook 邮件配置文件的客户端的情况。

• 默认情况下，自动发现客户端将尝试通过向 DNS 查询从收件人电子邮件地址获取的特定主机名（根域）来尝试定位其自动发现端点。
• 如果自动发现客户端无法完成与主机的过程，他将尝试使用命名约定自动发现+域名的不同主机名。
• 如果自动发现客户端无法完成与主机的过程，他将尝试请求“重定向”指令到所需的主机。
• 如果自动发现客户端无法完成与主机的过程，他将查询 DNS 服务器，查找包含所需自动发现端点的主机名的 SRV 记录。

在下图中，我们可以看到自动发现客户端“编程”使用的自动发现算法的流程。

是不是感觉布局很复杂，看着图表就开始有点头疼？

好吧，我同意，但同时，我必须通知您，这是自动发现工作流程的“最小化版本”。

当淹没图表时，我删除了许多“部分”，例如相互身份验证过程以及使图表易于理解的其他部分。

例如，关于作为自动发现过程的一部分实现的安全机制，下一节中提供的自动发现流程描述包括对所实现的安全缺陷的非常一般的参考。

如果您想阅读有关自动发现环境中安全主题的更多详细信息，请阅读文章 - 自动发现过程和 Exchange 安全基础结构 |第 20 部分#36

自动发现非 Active Directory 环境中的工作流程 |可选场景

为了演示非 Active Directory 环境中的一些可选自动发现方案，我们使用以下组织基础架构：

该组织的公共域名是 - o365info.com
该公司有一个使用主机名发布的公共网站 - o365info .com

名为 Bob 的外部用户，其电子邮件地址为 [email protected]，需要创建一个新的 Outlook 邮件配置文件，以连接到其托管在 Exchange On-Premise 上的邮箱服务器。

注意：实现的自动发现方法不能基于 Active Directory 自动发现方法，因为自动发现客户端位于外部\公共网络上，并且他无权访问组织 Active Directory。

场景一：使用公有域名的公司网站 |不支持 HTTPS

自动发现客户端（在我们的示例中为 Outlook）将获取收件人电子邮件地址的“正确部分”，并将与 SMTP 域名相关联作为潜在自动发现端点的主机名。

自动发现客户端将联系 DNS 服务器并向 DNS 查询名为 - o365info.com 的主机的 IP 地址

在我们的场景中，DNS 有一个“映射”到该主机名的 IP。

请注意，此 IP 地址将指向公司的公共网站，该网站不是自动发现端点，但自动发现客户端并不知道！

自动发现客户端使用从 DNS 服务器获取的 IP 地址，并尝试检查潜在自动发现端点是否支持使用 HTTPS 协议进行通信。

在这种特定场景中，公司网站不支持 HTTPS（没有公共证书）。

当与主机 o365info.com 主机的 HTTPS 通信测试失败时，自动发现客户端“理解”他需要“继续”使用附加的自动发现方法。

自动发现客户端启动一个新会话，但这一次；自动发现客户端现在将尝试使用主机名寻找潜在的自动发现端点 - autodiscover.o365info.com

在我们的场景中，使用主机名自动发现创建了一条 A 记录，并且映射到该主机名的 IP 地址指向 Exchange On-Premise 服务器。

自动发现客户端检查主机 autodiscover.o365info.com 是否支持 HTTPS。

自动发现端点（面向公共的 Exchange CAS 服务器）批准他可以使用 HTTPS 协议进行通信。

自动发现客户端将要求自动发现端点（面向公共的 Exchange CAS 服务器）通过提供公共证书来证明其身份。

如果服务器证书成功验证，自动发现客户端将其用户凭据发送到自动发现端点。

最后一步是自动发现客户端向自动发现端点询问构建新的 Outlook Anywhere 配置文件所需的自动发现信息。

场景二：使用公有域名的公司网站 | HTTPS 支持

下面的场景有点令人困惑，因为这次我们处理一个映射到“根域名”+支持 HTTPS 的公共网站。

这种情况将导致自动发现客户端“相信”他已经找到了他的自动发现端点，但实际上，他尝试与之通信的主机不是所需的主机。

自动发现客户端将联系 DNS 服务器寻找主机名 - o365info.com

获取 IP 地址后，自动发现客户端会尝试检查主机（潜在自动发现端点）是否支持 HTTPS 通信。

在我们的场景中，公司网站支持 HTTPS 通信并拥有公共证书。

自动发现端点的基本假设是这是“正确的主机”，现在；自动发现客户端将生成自动发现信息的请求。

该请求将被主机 - o365info.com 接受，但该主机不是自动发现端点，并且他不不“理解”“请求自动发现信息”的含义。

自动发现客户端知道他尝试与“错误的主机”进行通信，下一步是 - 继续执行下一个自动发现方法，其中自动发现客户端将尝试使用不同的主机名查找自动发现端点 -