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

当前文章是上一篇文章的延续，其中我们回顾了在非 Active Directory 环境中的自动发现流程中实现的自动发现流程。在本文中，我们将使用 Microsoft 基于 Web 的工具 Microsoft 远程连接分析器 (MRCA) 检查自动发现流程。

为了查看每个步骤以及包含特定自动发现步骤的每个部分，我们将使用功能强大的工具 Microsoft Remote Connectivity Analyzer。

Microsoft 远程连接分析器 (MRCA) 包括许多选项卡和选项。在我们的特定场景中，我们想要测试 Exchange 本地基础设施。为了实施所需的测试，我们将选择 Exchange 服务器选项卡、Microsoft Office Outlook 连接测试，以及Outlook 自动发现选项。

如果您需要了解有关 Microsoft 远程连接分析器 Web 工具的更多详细信息，您可以阅读文章 Microsoft 远程连接分析器 (ExRCA) |自动发现故障排除工具|第 2#4 部分 |第 22 部分#36

场景描述

为了演示使用 Exchange 本地基础架构时在“非 Active Directory 环境”中实施的自动发现工作流程，我们使用以下场景：

John 是一位组织用户，需要访问其托管在 Exchange 本地服务器上的邮箱。

John 物理上位于公共网络上，因此，他无法使用在 Active Directory 环境中实现的自动发现进程。

约翰的电子邮件地址是 - [email protected]
约翰的任务是创建一个新的 Outlook 邮件配置文件，使他能够连接他的邮箱。 Outlook 配置文件基于 Outlook Anywhere 服务。

请注意，该公司有一个使用名为 o365info.com 的主机发布的公共网站

使用 MRCA 分析自动发现过程

在深入了解细节之前，让我们先从自动发现测试结果的高级视图开始。

在下面的屏幕截图中，我们可以看到自动发现过程成功完成。
通过查看自动发现结果报告结构，我们可以看到“第一部分”失败（未成功完成），但第二部分（B部分）成功完成。

注意：自动发现流程在 99% 的情况下将“包含”几个“步骤失败”，但仍然以成功流程结束。

第二部分（B 部分）包括对结果报告中实施和记录的五个自动发现步骤中每一个步骤的“高级”描述（我们将在下一节中详细审查每个步骤）。

分析自动发现过程 |详细描述步骤

步骤1/9：尝试在DNS中解析主机名o365info.com

默认情况下，自动发现客户端将尝试使用从收件人电子邮件地址“提取”的主机名来查找“潜在的自动发现端点”。

自动发现客户端将使用收件人电子邮件地址的“右侧部分”，其中包括 SMTP 域名。
在我们的场景中，收件人电子邮件地址是 - john@o365info。 com
基于此特定电子邮件地址；自动发现客户端将创建一个 DNS 查询，查找名为 - o365info.com 的主机的 IP 地址

DNS 服务器的“答案”取决于特定组织的公共服务器和服务基础设施。

例如，大多数组织都有一个公共网站，并且大多数时候，公共域名被“映射”到网站的公共IP。

在我们的场景中，DNS 使用所请求主机名的公共 IP 地址进行回复。
DNS 服务器提供的 IP 不“属于”Exchange 服务器（自动发现端点），而是此公共 IP分配给标准 Web 服务器的地址。

步骤 1/9：分析 MRCA 连接测试的数据

在MRCA结果页面中，我们可以看到以下信息：

MRCA 测试结果以错误消息开头，表明与名为 - o365info.com 的主机的连接尝试失败。

尝试测试潜在的自动发现 URL https://o365info.com:443/Autodiscover/Autodiscover.xml
测试此潜在的自动发现 URL 失败。

（我们将在下一节中获得有关失败原因的更多详细信息）。

请注意，当我们查看自动发现客户端执行的工作流的详细信息时，我们可以看到某些步骤已成功完成。

例如，自动发现客户端向 DNS 服务器请求主机 o365info.com 的 IP 地址的解析步骤成功完成。

尝试在 DNS 中解析主机名 o365info.com。主机名解析成功。返回的IP地址：104.28.12.85、104.28.13.85

步骤 2/9：测试主机 o365info.com 上的 TCP 端口 443，以确保其正在监听并打开。

自动发现客户端使用在上一步中获取的 IP 地址来寻址潜在的自动发现端点。
自动发现客户端将尝试验证潜在的自动发现端点是否在端口 443 (HTTPS) 上列出。

在我们的场景中，HTTPS 通信测试失败，因为“目标主机”不支持 HTTPS 通信。

步骤 2/9：分析 MRCA 连接测试的数据

在MRCA结果页面中，我们可以看到有关主机o365info.com上测试TCP端口443的以下信息：

指定的端口被阻止、未侦听或未产生预期响应。与远程主机通信时发生网络错误。

步骤3/9：尝试在DNS中解析主机名autodiscover.o365info.com

由于使用主机名 o365info.com 与潜在自动发现端点的通信尝试失败，自动发现客户端将转向下一个方法，其中自动发现客户端将使用以下命名方案 - 自动发现 +

在我们的场景中，收件人电子邮件地址是 - [email protected]
根据此特定电子邮件地址，自动发现客户端将创建一个 DNS 查询，查找名为 - autodiscover.o365info.com 的主机的 IP 地址

步骤 3/9：分析 MRCA 连接测试的数据

在MRCA结果页面中，我们可以看到以下有关尝试解析主机名o365info.com的信息：

尝试在 DNS 中解析主机名 autodiscover.o365info.com。
主机名解析成功。返回的 IP 地址：212.25.80.239

步骤 4/9：测试主机 autodiscover.o365info.com 上的 TCP 端口 443，以确保其正在监听并打开。

自动发现客户端使用在上一步中获取的 IP 地址来寻址潜在的自动发现端点。
自动发现客户端将尝试验证潜在的自动发现端点是否在端口 443 (HTTPS) 上列出。

在我们的场景中，HTTPS 通信测试成功，这意味着目标主机（自动发现端点）支持 HTTPS 通信。

步骤 4/9：分析 MRCA 连接测试的数据

在 MRCA 结果页面中，我们可以看到有关主机 autodiscover.o365info.com 上测试 TCP 端口 443 的以下信息：

正在主机 autodiscover.o365info.com 上测试 TCP 端口 443，以确保其正在监听并打开。端口打开成功。

步骤 5/9：请求潜在自动发现端点提供公共服务器证书

自动发现客户端“假设”目标主机是“潜在的自动发现端点”，可以向他提供所需的自动发现信息。

在自动发现客户端请求所需信息之前，他必须成功完成几个步骤。

自动发现客户端需要“确定”目标主机是可靠\信任的主机。

为了能够信任潜在的自动发现端点，自动发现客户端将要求服务器通过提供有效的公共证书来证明其身份。

步骤 5/9：分析 MRCA 连接测试的数据

在 MRCA 结果页面中，我们可以看到有关自动发现客户端请求潜在自动发现端点提供服务器公共证书的步骤的以下信息：

Microsoft 连接分析器正在尝试从端口 443 上的远程服务器 autodiscover.o365info.com 获取 SSL 证书。
Microsoft 连接分析器已成功获取远程 SSL 证书。

步骤 6/9：测试 SSL 证书以确保其有效

自动发现客户端执行的证书验证测试包括三个不同的部分。

1.验证证书名称
自动发现客户端使用主机名寻址潜在的自动发现端点 - autodiscover.o365info.com

为了能够知道这是“真实主机”，自动发现客户端将检查证书是否包含指定的主机名（autodiscover.o365info.com ）

注意：此描述与服务器使用 SAN 证书的场景相关。
如果潜在的自动发现端点使用通配符证书，客户端将仅验证域名（在在我们的场景中，客户端将验证的域名是 - o365info.com）。

2.验证证书信任
服务器提供的公共证书，由 CA（证书颁发机构）创建。
自动发现客户端还需要验证向服务器提供其证书的 CA 证书。

3.验证证书日期是否有效
自动发现客户端需要验证服务器证书日期是否有效。

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

步骤 6/9：分析 MRCA 连接测试的数据

1.验证证书名称

在 MRCA 结果页面中，我们可以看到有关自动发现端点名称验证测试的以下信息：

证书名称已成功验证。
在证书使用者备用名称条目中找到主机名 autodiscover.o365info.com。

2.验证证书信任

在MRCA结果页面中，我们可以看到有关证书信任的验证测试的以下信息：

正在验证证书信任。该证书是受信任的，并且所有证书都存在于链中。 Microsoft 连接分析器正在尝试为证书 CN=mail.o365info.com、OU=Domain Control Validated、O=mail.o365info.com 构建证书链。
已成功构建一个或多个证书链。

3.验证证书日期是否有效

在MRCA结果页面中，我们可以看到以下有关证书数据验证测试的信息：

测试证书日期以确认证书有效。日期验证通过。证书尚未过期。
证书有效。 NotBefore=1/26/2013 11:22:11 PM，NotAfter=1/26/2015 11:22:11 PM

步骤 7/9：检查客户端证书身份验证的 IIS 配置

自动发现客户端检查目标主机（自动发现端点）是否需要客户端证书。客户端证书是客户端通过提供证书来证明其身份的一种方法。

客户端证书的使用非常罕见，大多数时候，客户端用于“证明其身份”的方式是提供用户凭据。

步骤 7/9：分析 MRCA 连接测试的数据

在MRCA结果页面，我们可以看到客户端证书认证测试的以下信息：

检查客户端证书身份验证的 IIS 配置。未检测到客户端证书身份验证。未配置接受/要求客户端证书。

步骤 8/9：提供用户凭据

证书验证测试成功完成并且自动发现客户端可以“信任”目标主机后，自动发现客户端还需要证明其身份。

自动发现客户端将通过提供用户凭据“（用户名+密码）来识别自己的身份。

注意：“提供用户凭据”部分不会出现在 MRCA 结果中。

步骤 9/9：尝试向潜在的自动发现 URL 发送自动发现 POST 请求

这是自动发现之旅的最后一步。

成功编译所有步骤后，自动发现客户端完成其任务 - 获取自动发现文件。

自动发现端点将生成针对需要信息的特定自动发现客户端（在我们的场景中为 John）“定制”的自动发现响应。

步骤 9/9：分析 MRCA 连接测试的数据

在 MRCA 结果页面中，我们可以看到有关 Exchange CAS 服务器发送到客户端的自动发现响应的以下信息：

尝试向潜在的自动发现 URL 发送自动发现 POST 请求。
Microsoft Connectivity Analyzer 通过发送自动发现 POST 成功检索自动发现设置。
Microsoft Connectivity Analyzer 正在尝试从 URL https 检索 XML 自动发现响应用户 [email protected] 的://autodiscover.o365info.com:443/Autodiscover/Autodiscover.xml。已成功检索自动发现 XML 响应。

自动发现 Exchange 提供商

Exchange CAS 服务器包括几个 Outlook 提供程序。
自动发现将包括每个提供程序的专用部分。

在我们的示例中，我们截取了包含 EXCH 提供商信息的部分的屏幕截图 - EXCH

如果您需要有关 Exchange CAS 服务器自动发现提供程序的更多详细信息，请阅读文章 - 自动发现服务器响应的内容 |第 11 部分#36

在下面的屏幕截图中，我们可以看到自动发现响应包含提供自动发现服务的 Exchange CAS 服务器的“私有”或“隐藏名称” - EX01.o365info.local
自动发现响应包含有关每个可用 Exchange Web 服务的详细信息。

在以下示例中，我们可以看到有关可用服务的信息： https://ex01.o365info.local/ews/exchange.asmx

关于自动回复（外出）服务：https://ex01.o365info.local/ews/exchange.asmx