Office 365 环境中的自动发现流程 |第 1#3 部分 |第 29 部分#36

基于 Office 365 的环境中的自动发现流程可以被认为是一个令人着迷的过程，因为自动发现客户端找到其自动发现端点，其中包括许多曲折。

Office 365 环境中的自动发现流程 |文章系列

当前的文章是三篇文章系列中的第一篇文章，这些文章致力于详细描述我们可以描述为“仅云”的环境中的自动发现流程。

该系列的其他文章是：

• Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36
• Office 365 环境中的自动发现流程 |第 3 部分#3 |第 31 部分#36

第一篇文章致力于介绍在基于 Office 365 的环境中实现的自动发现流程中的逻辑和相关组件。

在接下来的两篇文章中，我们将回顾使用 Microsoft 基于 Web 的工具 Microsoft 远程连接分析器 (ExRCA) 在基于 Office 365 的环境中实现的自动发现流程。

您可以在文章 - Microsoft 远程连接分析器 (ExRCA) | Microsoft 远程连接分析器 (ExRCA) | 中阅读有关如何使用 Microsoft 远程连接分析器 (ExRCA) 工具的更多信息。自动发现故障排除工具|第 2#4 部分 |第 22 部分#36

基于 Office 365 的环境中自动发现流程的特殊字符

在基于 Office 365 的环境中实施的自动发现流程与在 Exchange 本地环境中实施的“标准”自动发现流程有很大不同。

基于 Office 365 的环境中自动发现流程的主要功能包括：

• 自动发现流程，包括以结构化方式的故障事件。简而言之，自动发现客户端将寻址不存在的自动发现端点”或无法提供所需的自动发现信息。
• 自动发现流程将基于几个节点并“跳转”，直到自动发现客户端到达其最终目的地，这意味着自动发现端点可以提供所需的自动发现信息。
• 包含自动发现流的某些节点不会提供“标准自动发现信息”，而是提供自动发现重定向消息，该消息将自动发现客户端“路由”到其他自动发现端点。

这些信息听起来是不是很大而且不太清楚？

如果答案是“是”那么，欢迎来到俱乐部！

Exchange Online 和“纯云环境”

在 Exchange Online 环境中，自动发现过程的实施方式与在 Exchange 本地环境中实施的“标准”自动发现过程不同。

在 Exchange 本地环境中，自动发现客户端将查找代表特定域的自动发现端点。

例如，在电子邮件地址为 [email protected] 的用户尝试创建新的 Outlook 邮件配置文件的情况下；自动发现过程是通过以下方式实现的-

自动发现端点将查询 DNS，查找名为 - o365info.com 的主机。如果自动发现客户端无法连接指定的主机名，自动发现端点将继续执行步骤 2，其中自动发现客户端尝试使用主机名查找潜在的自动发现端点 -
autodiscover.o365info.com

基本假设是，在基于 Exchange 本地环境的环境中，组织分配面向公众的 Exchange CAS 服务器，该服务器将充当域名的代表 - o365info.com 和FQDN -autodiscover.o365info.com 映射到此面向公众的 Exchange 服务器。

当自动发现客户端设法找到自动发现端点时，自动发现客户端将请求自动发现端点通过提供公共服务器证书来“证明其身份”。

自动发现端点将提供所需的证书，自动发现客户端将验证服务器证书是否包含域名 - o365info.com （在通配符证书的情况下）或主机名 - autodiscover.o365info.com。

在 Exchange Online 环境中，所描述的方案无法实现，原因很简单：

实际上，“云基础设施”（Office 365 和 Exchange Online）无法为每个 Office 365 租户以及在 Office 365 中注册的每个公共域分配专用公共证书。

在 Exchange Online 中，特定的 Exchange 服务器（或 Exchange Online 服务器阵列）可以同时代表一百或一千个不同的域。

自动发现端点（Exchange 服务器）提供包含对特定客户端域的引用的公共证书的概念无法实现！

因此，最大的问题是 - 我们如何解决使自动发现客户端能够访问其 Exchange Online 邮箱的问题？

答案是——“重定向”。

使用 CNAME 记录的 DNS 重定向方法

Office 365 和 Exchange Online 环境与 Exchange 本地环境具有不同的特征。
因此，熟悉 Office 365 基础结构的核心逻辑非常重要。

Office 365（使用 Exchange Online 作为邮件基础设施）是一种 SaaS（软件即服务）。
每个 Office 365 订阅者都被描述为“租户”；在 Office 365“大楼”租用私人空间。

在 Exchange 本地环境中，组织使用面向公众的专用 Exchange 服务器，该服务器充当组织公共域名的“代表”。

“云环境”（Office 365）无法提供这种类型的“专用 Exchange 服务器”来代表 Office 365 租户的特定域名。

例如，如果我们需要为具有电子邮件地址的收件人创建新的 Outlook 邮件配置文件 - [email protected]，自动发现客户端 (Outlook)，将始终通过查找名为 - o365info.com
的主机来启动自动发现过程，如果他找不到该主机或与该主机通信，他将尝试寻找自动发现端点命名 - autodiscover.o365info.com

真正的答案是，在 Office 365 环境中，不存在名为 - autodiscover.o365info.com 的“真实服务器”，该服务器具有包含对域名的引用的公共证书 - o365info.com

理论上，自动发现过程应该会失败。

这个问题的答案就是——冒充。

解决方案是——让自动发现客户端“认为”他正在与特定主机通信，而在实践中，他与另一个元素通信，该元素将自己“呈现”为自动发现客户端认为他是的元素。

听起来像是一个阴谋？
是的，有一点

在“纯云环境”（完全托管在云上的邮件基础设施）中，Office 365 订阅者需要通过添加新的 CNAME 记录来更新其公共 DNS。

注意：如果 Office 365 订阅者需要在当前文章中的公共 DNS 服务器中添加和更新一些 DNS 记录，我们仅查看与自动发现服务相关的 DNS 记录。

发挥“魔力”的 DNS 记录是一个简单的 CNAME 记录，它创建的目的是重新检测自动发现客户端对 Office 365“元素”的请求，该元素将冒充他们正在寻找的“真实主机”。

自动发现和 DNS CNAME 记录（DNS 重定向）

CNAME记录的“技巧”实现如下：

在托管组织公共域名的公共 DNS 服务器中，我们创建一个新的 CNAME 记录，该记录将对主机名 - 自动发现的请求重定向到不同的或另一个主机名。

自动发现请求将重定向到的主机名 - autodiscover.o365info.com

注意：DNS CNAME 记录是具有“两部分”的记录：“右侧部分”将包括 DNS 客户端正在查找的主机名，而 CNAME 记录的“左侧部分”将包括包括 DNS 将提供其 IP 地址的主机名。

例如，在托管域名的公共 DNS 服务器中 - o365info.com ，我们将添加一条新的 CNAME 记录，该记录将使 DNS 服务器提供该域名的 IP 地址。将 autodiscover.outlook.com 托管到每个请求 autodiscover.outlook.com IP 地址的 DNS 客户端

例如，当自动发现客户端尝试与名为 - autodiscover.o365info.com 的主机通信时，将从 DNS 返回到自动发现客户端的 IP 地址将“引导” 自动发现客户端到名为 - autodiscover.outlook.com 的 Office 365 主机。

autodiscover.outlook.com 是谁？

autodiscover.outlook.com 是一个“Office 365 元素”，充当自动发现客户端和 Exchange Online 基础结构之间的“逻辑路由器”。

Office 365 用户（其邮箱托管在 Exchange Online 上的用户）的自动发现流程首先与名为 -
autodiscover.outlook.com 的 Office 365 主机进行通信

“autodiscover.outlook.com 组件”将接受自动发现客户端的请求，但是主机 autodiscover 不会提供所需的自动发现信息.outlook.com，发送“重定向消息”作为回复，将自动发现客户端“引导”至其他 Offices 365 自动发现端点。

autodiscover.o365info.com 单个主机或逻辑组件。从理论上讲，将自动发现端点重定向到其所需的 Exchange Online 服务器的 Office 365 对象是名为 autodiscover.o365info.com 的单个主机。

实际上，autodiscover.outlook.com只是一个逻辑对象，由分散在世界各地的数十甚至数百台服务器代表。

当自动发现客户端尝试获取主机名的 IP 地址 - autodiscover.outlook.com 时，自动发现客户端将获取的答案（IP 地址 + 主机名）取决于他的地理位置。

例如，实际位于欧洲的自动发现客户端将获得与实际位于美国的自动发现客户端不同的准确信息。

我们可以通过使用简单的 ping 命令来演示此过程。
在下面的屏幕截图中，我们可以看到对名为 - autodiscover.o365info 的主机执行 ping 命令的结果。 com

我们从 DNS 服务器获得的“答案”将我们指向名为 -
autodiscover-emeaeast.outlook.com 的不同主机

如果您想知道为什么我们看到主机名 -
autodiscover-emeaeast.outlook.com 而不是我们谈论的主机名 - autodiscover.outlook.com，答案可能是因为 Office 365 DNS 基础设施基于“GeoDNS”。

当使用 GeoDNS 选项时，DNS 服务器会识别 DNS 客户端的 IP 地址并推断出 DNS 客户端的地理位置。

根据此信息，DNS 服务器提供适合 DNS 客户端地理位置的答案（IP 地址和主机名）。
在我们的示例中，我的物理位置被视为“EMEA”（欧洲、中东和非洲），因此，使用的 Office 365 自动发现组件是物理位于 EMEA 的主机。

HTTP 和 HTTPS 重定向方法

在 Office 365 环境中为自动发现服务实现的另一种重定向方法是 - HTTP 重定向 和 HTTPS 重定向 方法。

在上一节中，我们提到向 DNS 服务器查询潜在自动发现端点的自动发现客户端将被“重定向”到另一个主机名
(autodiscover.outlook.com）。

自动发现客户端“认为”这是可以为他提供所需信息的“元素”，但这种“假设”是错误的。

当自动发现客户端尝试连接到名为 - autodiscover.outlook.com 的自动发现端点时，最终结果将是一个额外的重定向，该重定向由 HTTP 协议实现为 额外的自动发现端点。

如果您认为这就是“故事的结局”，您将会失望！
（或者更准确地说，自动发现客户端将会失望）。

在HTTP重定向阶段之后，当自动发现客户端尝试寻址“新主机”（潜在的自动发现端点）时，结果是额外的重定向，但这一次，重定向方法基于HTTPS协议。

Office 365 环境中自动发现客户端的自动发现“旅程”

我将 Office 365 中的自动发现客户端的自动发现工作流程描述为一次“旅程”，因为就像童话故事一样，王子历经千辛万苦才到达公主身边，而自动发现客户端也需要历经千辛万苦。

注意 - 我们不会详细介绍自动发现客户端需要通过的每个“步骤”，因为在下一篇文章 Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30#36 部分，我们彻底回顾了每个步骤。

在下图中，我们可以看到自动发现客户端在途中会遇到的“元素”的“高级视图”。

我必须将 DNS 服务器放置在图的顶部，因为每次自动发现客户端重定向到“下一个跃点”时，自动发现客户端都需要创建一个 DNS 查询，询问出现在中的主机名的 IP 地址。重定向消息。

对 Office 365 环境中的自动发现流程的额外审查

仅当应用两个规则时，才能进行自动发现端点“准备好”向自动发现客户端提供所需信息（自动发现响应）的过程：

规则 1 - 相互身份验证
服务器必须向自动发现客户端证明其身份，以便自动发现客户端可以确定服务器（自动发现端点）是“可靠的信息源”。

自动发现客户端必须通过提供其用户凭据来向自动发现端点证明其身份。

规则 2 - 安全的沟通渠道

在自动发现端点和自动发现客户端之间的通信通道上传输的数据必须加密。

我们需要了解这个“强制性规则”，才能理解 Office 365 环境中的“奇怪的自动发现流程”。

在下一节中，我将回答以下问题：“在 Office 365 环境中实施如此复杂的自动发现基础设施需要什么？”

第一阶段

如前所述，在我们的场景中，自动发现客户端会查找名为 - autodiscover.o365info.com 的主机

DNS 的响应将为自动发现客户端提供主机 autodiscover.outlook.com 的 IP 地址

自动发现客户端将尝试与该主机进行通信（使用 HTTPS）。

主机 - autodiscover.outlook.com 无法使用 HTTPS 进行通信，因为他不是“真正的”自动发现端点，并且他没有包含主机名的服务器证书- autodiscover.o365info.com

由于 HTTPS 通信测试失败，自动发现客户端将创建一个新的 HTTP 请求，请求“重定向”到所需的自动发现端点，该端点可以使用 HTTPS 协议提供必要的自动发现服务。

autodiscover.outlook.com
的“HTTP 重定向答案”包含名为 - autodiscover-s.outlook 的自动发现端点的名称。 com

注意：“新自动发现端点”名称中的“S”代表安全性

第二阶段

自动发现客户端尝试使用 HTTPS 协议与“新自动发现端点”(autodiscover-s.outlook.com) 进行通信。

好消息是主机 autodiscover.outlook.com 可以使用 HTTPS 进行通信，但不太好的消息是 autodiscover.outlook。 com 公共证书仅包含属于“outlook.com”域的主机名的“授权”。

自动发现客户端期望在服务器证书中找到主机名 - autodiscover.o365info.com ，但此期望无法实现，因为在 Office 365 环境中，没有提供任何机制每个 Office 365 租户公共域名的专用公共证书。

所以现在我们遇到了一个“问题”。

自动发现客户端无法完成该过程，因为他在服务器证书中找不到主机名 autodiscover.o365info.com ，从技术上讲，自动发现过程应该失败。

好消息是，自动发现方法有一个名为 -HTTPS 重定向 的“技巧”。

自动发现端点 - autodiscover.outlook.com 无法满足自动发现客户端的条件，但因为
autodiscover.outlook.com 可以通过向客户端提供证书来证明其身份，自动发现客户端可以“信任”主机
autodiscover.outlook.com 并将其视为可靠的主机信息来源。

autodiscover.outlook.com 向自动发现客户端提供的信息不是自动发现信息（自动发现配置设置），而是包含到其他自动发现端点的重定向。

“附加自动发现端点”是能够向自动发现客户端提供所需自动发现信息的 Exchange Online CAS 服务器。

在我们的特定场景中，autodiscover.outlook.com（XML 重定向消息）提供的信息包括以下主机的名称 - pod5149.outlook.com

注意：在我们的场景中，Exchange Online CAS 服务器的名称是 - pod51049.outlook.com
从技术上讲，该名称可以并且将会根据 Office 365 数据中心等许多因素进行更改其中托管 Office 365 租户、可用的 Exchange Online CAS 服务器等。

第三阶段

自动发现客户端愿意接受重定向信息并尝试与自动发现端点通信 - pod51049.outlook.com

好消息是，现在自动发现过程可以完成。

pod51049.outlook.com 提供的公共证书是一个通配符证书，其中包含对 outlook.com 域名。

自动发现客户端将获取 pod51049.outlook.com 证书，验证该证书是否由受信任的 CA 提供，验证主机名或域名（在我们的场景中outlook.com) 出现在公共证书中。

这是自动发现客户端的一个“标志”，表明他现在可以通过提供 Office 365 用户凭据安全地向“服务器”提供自己的身份。

相互身份验证过程完成后，将创建安全通信链接，并且“服务器”(pod5149.outlook.com) 向自动发现客户端提供所需的 autodiscover.xml文件。

当前文章系列的下一篇文章

Office 365 环境中的自动发现流程 |第 2#3 部分 |第 30 部分#36