自动发现如何工作（对于外部*用户）？

Question 1

此问题很可能是由 Outlook 的自动发现服务，是随时随地展望功能。自动发现向最终用户的 Outlook 客户端提供有关 Exchange 提供的各种服务及其位置的各种信息；这可用于多种目的：

首次运行 Outlook 时自动配置 Outlook 配置文件，仅使用用户的电子邮件地址和密码即可配置 Exchange 帐户，因为其他信息会自动定位和检索。
Outlook 客户端访问的基于 Web 的服务的动态位置，包括外出助理、统一消息功能、Exchange 控制面板 (ECP) 的位置等等。

这是微软的专有实现RFC 6186。不幸的是，他们在 Outlook Anywhere 的设计中并没有真正遵循该 RFC 的建议，但这也许是可以预料到的，因为 Exchange 和 RPC over HTTPS 功能不是传统的 IMAP/SMTP 服务器。

自动发现如何工作（对于外部*用户）？

自动发现与客户端访问服务器上的 Web 服务进行通信（在本例中，所有角色都在 SBS 服务器上），路径为/Autodiscover/Autodiscover.xml，根植于其默认网站。为了找到要通信的服务器的 FQDN，它会删除电子邮件地址的用户部分，只留下域（即 @companyB.com）。它依次尝试使用以下每个 URL 与自动发现进行通信：

https://companyB.com/Autodiscover/Autodiscover.xml
https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

如果这些失败，它将尝试通过禁用 SSL 并尝试在端口 80（HTTP）上进行通信来建立非安全连接，通常是在提示用户确认这是一个可接受的操作之后（在我看来这是一个有缺陷的选项，因为无知的用户通常会批准这一点并冒险通过纯文本发送凭据 - 而不需要安全通信凭据和业务敏感数据的无知系统管理员会对业务连续性构成风险）。

最后，使用 DNS 中的服务记录 (SRV) 进行后续检查，该记录存在于companyB.com命名空间之外的知名位置，可以将 Outlook 重定向到服务器正在监听的正确 URL。

什么情况会出错？

在此过程中可能会出现以下几个问题之一：

没有 DNS 条目

通常，域的根 ( companyB.com) 可能无法解析为 DNS 中的主机记录。不正确的 DNS 配置（或故意决定不公开 Outlook Anywhere 服务）autodiscover.companyB.com也可能意味着该记录不存在。

在这些情况下，没有大问题；Outlook 只是继续使用最后已知的配置与 Exchange 通信，并且可能会在某些基于 Web 的功能方面降级，因为这些功能需要通过自动发现 (例如外出助理) 检索 URL。一种解决方法是使用 Outlook Web Access 来访问此类功能。

新 Outlook 配置文件中的 Exchange 帐户自动配置也不是自动的，需要手动配置 RPC over HTTPS 设置。但是，这不会导致您描述的问题。

SSL 证书错误

Outlook 尝试联系 Exchange Server 时使用的 URL 完全有可能解析为主机，该主机可能是也可能不是客户端访问服务器。如果 Outlook 可以在端口 443 上与该服务器通信，则当然会交换证书以在 Outlook 和远程服务器之间建立安全通道。如果 Outlook 认为正在与之通信的 URL 未在该证书上列出（无论是作为通用名称还是主题备用名称 (SAN)），这将导致 Outlook 显示您在初始帖子中描述的对话框。

发生这种情况的原因有很多，都与 DNS 的配置方式以及 Outlook 检查上述 URL 的方式有关：

如果https://companyB.com/... URL 解析为主机记录，和该地址的 Web 服务器监听 443 端口，和它有一个 SSL 证书不是通用名称或主题备用名称中没有列出companyB.com，则会出现问题。主机是否是 Exchange 服务器并不重要；它可能是托管公司网站的 Web 服务器，但配置不正确。科里吉任何一个：
- 禁用区域根目录的主机记录companyB.com（要求网站或其他服务的访问者输入www.companyB.com，或同等操作）；或者
- 禁用对端口 443 上的机器的访问，导致 Outlook在交换证书并继续之前companyB.com拒绝该URL；companyB.com或者
- 修复证书以companyB.com确保companyB.com在该证书上列出，并且https://companyB.com通过标准浏览器访问的尝试不会失败。

无论是否companyB.com解析为 Exchange Server，上述内容均适用；如果 Outlook 可以与其通信，它稍后会发现该/Autodiscover/Autodiscover.xml路径产生 HTTP 404 错误（不存在）并继续。

如果https://autodiscover.companyB.com/... URL 解析为 Exchange Server（或任何其他服务器），但同样autodiscover.companyB.com未列为通用名称或主题备用名称，您将观察到此行为。可以通过修复证书按上述方法修复此问题，或者正如你正确指出的那样，你可以使用SRV 记录将 Outlook 重定向到以下 URL：是证书上列出的以及 Outlook能与交流。

您可能对此问题的解决方案

在这种情况下，典型的解决方法是执行后者；在新的 DNS 提供商中创建 SRV 记录，以确保 Outlook 重定向到autodiscover.companyA.com，这将成功运行（除了任何其他问题），因为它在证书上列为 SAN。要使其正常工作，您需要：

_autodiscover._tcp.companyB.com按照配置SRV 记录文档。
autodiscover.companyB.com如果存在，请删除主机记录，以防止 Outlook 解析此问题并尝试以这种方式达到自动发现。
还要解决上述 HTTPS 访问的任何问题https://companyB.com，因为 Outlook 将枚举从用户电子邮件地址派生的 URL前转向 SRV 记录方法。

*自动发现如何工作（针对内部、加入域的客户端）？

我添加这一点仅仅是为了完整性，因为这是这些证书提示发生的另一个常见原因。

在加入域的客户端上，当它位于 Exchange 环境本地（即在内部 LAN 上）时，不使用上述技术。相反，Outlook 直接与 Active Directory 中的服务连接点（在 Exchange 客户端访问设置中列出）进行通信，该连接点列出了 Outlook 可以找到自动发现服务的 URL。

在这些情况下出现证书警告是很常见的，因为：

为此目的配置的默认 URL 指的是内部的Exchange 的 URL，通常与公共 URL 不同。
.localSSL 证书可能不列出内部 URL。目前，您的证书会列出内部 URL，但对于使用类似非全球 gTLD 域名后缀的Active Directory 域，这可能会成为未来的问题，因为ICANN 的决定禁止在 2016 年后为此类域名颁发 SSL 证书。
内部地址可能无法解析到正确的服务器。

在这种情况下，可以通过运行以下方法解决此问题：更正记录的 URL，使其指向正确的外部地址（在证书中列出）。Set-ClientAccessServercmdlet 和-AutodiscoverServiceInternalUri交换机。执行此操作的各方通常还会配置水平分割 DNS，要么是因为他们的网络配置要求他们这样做，要么是为了在上游解析器/连接中断时保持解析的连续性。

Answer

此问题很可能是由 Outlook 的自动发现服务，是随时随地展望功能。自动发现向最终用户的 Outlook 客户端提供有关 Exchange 提供的各种服务及其位置的各种信息；这可用于多种目的：

首次运行 Outlook 时自动配置 Outlook 配置文件，仅使用用户的电子邮件地址和密码即可配置 Exchange 帐户，因为其他信息会自动定位和检索。
Outlook 客户端访问的基于 Web 的服务的动态位置，包括外出助理、统一消息功能、Exchange 控制面板 (ECP) 的位置等等。

这是微软的专有实现RFC 6186。不幸的是，他们在 Outlook Anywhere 的设计中并没有真正遵循该 RFC 的建议，但这也许是可以预料到的，因为 Exchange 和 RPC over HTTPS 功能不是传统的 IMAP/SMTP 服务器。

自动发现如何工作（对于外部*用户）？

自动发现与客户端访问服务器上的 Web 服务进行通信（在本例中，所有角色都在 SBS 服务器上），路径为/Autodiscover/Autodiscover.xml，根植于其默认网站。为了找到要通信的服务器的 FQDN，它会删除电子邮件地址的用户部分，只留下域（即 @companyB.com）。它依次尝试使用以下每个 URL 与自动发现进行通信：

https://companyB.com/Autodiscover/Autodiscover.xml
https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

如果这些失败，它将尝试通过禁用 SSL 并尝试在端口 80（HTTP）上进行通信来建立非安全连接，通常是在提示用户确认这是一个可接受的操作之后（在我看来这是一个有缺陷的选项，因为无知的用户通常会批准这一点并冒险通过纯文本发送凭据 - 而不需要安全通信凭据和业务敏感数据的无知系统管理员会对业务连续性构成风险）。

最后，使用 DNS 中的服务记录 (SRV) 进行后续检查，该记录存在于companyB.com命名空间之外的知名位置，可以将 Outlook 重定向到服务器正在监听的正确 URL。

什么情况会出错？

在此过程中可能会出现以下几个问题之一：

没有 DNS 条目

通常，域的根 ( companyB.com) 可能无法解析为 DNS 中的主机记录。不正确的 DNS 配置（或故意决定不公开 Outlook Anywhere 服务）autodiscover.companyB.com也可能意味着该记录不存在。

在这些情况下，没有大问题；Outlook 只是继续使用最后已知的配置与 Exchange 通信，并且可能会在某些基于 Web 的功能方面降级，因为这些功能需要通过自动发现 (例如外出助理) 检索 URL。一种解决方法是使用 Outlook Web Access 来访问此类功能。

新 Outlook 配置文件中的 Exchange 帐户自动配置也不是自动的，需要手动配置 RPC over HTTPS 设置。但是，这不会导致您描述的问题。

SSL 证书错误

Outlook 尝试联系 Exchange Server 时使用的 URL 完全有可能解析为主机，该主机可能是也可能不是客户端访问服务器。如果 Outlook 可以在端口 443 上与该服务器通信，则当然会交换证书以在 Outlook 和远程服务器之间建立安全通道。如果 Outlook 认为正在与之通信的 URL 未在该证书上列出（无论是作为通用名称还是主题备用名称 (SAN)），这将导致 Outlook 显示您在初始帖子中描述的对话框。

发生这种情况的原因有很多，都与 DNS 的配置方式以及 Outlook 检查上述 URL 的方式有关：

如果https://companyB.com/... URL 解析为主机记录，和该地址的 Web 服务器监听 443 端口，和它有一个 SSL 证书不是通用名称或主题备用名称中没有列出companyB.com，则会出现问题。主机是否是 Exchange 服务器并不重要；它可能是托管公司网站的 Web 服务器，但配置不正确。科里吉任何一个：
- 禁用区域根目录的主机记录companyB.com（要求网站或其他服务的访问者输入www.companyB.com，或同等操作）；或者
- 禁用对端口 443 上的机器的访问，导致 Outlook在交换证书并继续之前companyB.com拒绝该URL；companyB.com或者
- 修复证书以companyB.com确保companyB.com在该证书上列出，并且https://companyB.com通过标准浏览器访问的尝试不会失败。

无论是否companyB.com解析为 Exchange Server，上述内容均适用；如果 Outlook 可以与其通信，它稍后会发现该/Autodiscover/Autodiscover.xml路径产生 HTTP 404 错误（不存在）并继续。

如果https://autodiscover.companyB.com/... URL 解析为 Exchange Server（或任何其他服务器），但同样autodiscover.companyB.com未列为通用名称或主题备用名称，您将观察到此行为。可以通过修复证书按上述方法修复此问题，或者正如你正确指出的那样，你可以使用SRV 记录将 Outlook 重定向到以下 URL：是证书上列出的以及 Outlook能与交流。

您可能对此问题的解决方案

在这种情况下，典型的解决方法是执行后者；在新的 DNS 提供商中创建 SRV 记录，以确保 Outlook 重定向到autodiscover.companyA.com，这将成功运行（除了任何其他问题），因为它在证书上列为 SAN。要使其正常工作，您需要：

_autodiscover._tcp.companyB.com按照配置SRV 记录文档。
autodiscover.companyB.com如果存在，请删除主机记录，以防止 Outlook 解析此问题并尝试以这种方式达到自动发现。
还要解决上述 HTTPS 访问的任何问题https://companyB.com，因为 Outlook 将枚举从用户电子邮件地址派生的 URL前转向 SRV 记录方法。

*自动发现如何工作（针对内部、加入域的客户端）？

我添加这一点仅仅是为了完整性，因为这是这些证书提示发生的另一个常见原因。

在加入域的客户端上，当它位于 Exchange 环境本地（即在内部 LAN 上）时，不使用上述技术。相反，Outlook 直接与 Active Directory 中的服务连接点（在 Exchange 客户端访问设置中列出）进行通信，该连接点列出了 Outlook 可以找到自动发现服务的 URL。

在这些情况下出现证书警告是很常见的，因为：

为此目的配置的默认 URL 指的是内部的Exchange 的 URL，通常与公共 URL 不同。
.localSSL 证书可能不列出内部 URL。目前，您的证书会列出内部 URL，但对于使用类似非全球 gTLD 域名后缀的Active Directory 域，这可能会成为未来的问题，因为ICANN 的决定禁止在 2016 年后为此类域名颁发 SSL 证书。
内部地址可能无法解析到正确的服务器。

在这种情况下，可以通过运行以下方法解决此问题：更正记录的 URL，使其指向正确的外部地址（在证书中列出）。Set-ClientAccessServercmdlet 和-AutodiscoverServiceInternalUri交换机。执行此操作的各方通常还会配置水平分割 DNS，要么是因为他们的网络配置要求他们这样做，要么是为了在上游解析器/连接中断时保持解析的连续性。

Question 2

您需要在域 B 和 C 中创建一个与证书中的一个名称 (autodiscover.companyA.com) 匹配的 SRV 记录。这会告诉 Outlook 该名称处理域 B 和 C 的自动发现。

请阅读 DNS 部分中的 SRV 记录：

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/

Answer

您需要在域 B 和 C 中创建一个与证书中的一个名称 (autodiscover.companyA.com) 匹配的 SRV 记录。这会告诉 Outlook 该名称处理域 B 和 C 的自动发现。

请阅读 DNS 部分中的 SRV 记录：

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/

自动发现如何工作（对于外部*用户）？

答案1

自动发现如何工作（对于外部*用户）？

什么情况会出错？

没有 DNS 条目

SSL 证书错误

您可能对此问题的解决方案

*自动发现如何工作（针对内部、加入域的客户端）？

答案2

相关内容