Office 365 Outlook 自动发现使用反向代理 - 糟糕的方法？

Question 1

Office 365 和 Exchange Online 环境与 Exchange 本地环境具有不同的特点。在 Exchange 本地环境中，组织使用专用的面向公众的 Exchange 服务器，该服务器作为组织公共域名的“代表”。而“云环境”（Office 365）无法提供这种类型的“专用 Exchange 服务器”，该服务器将代表 Office 365 租户的特定域名。请参阅此文章： https://o365info.com/autodiscover-flow-in-an-office-365-environment-part-1-of-3-part-29-of-36/

Answer

Office 365 和 Exchange Online 环境与 Exchange 本地环境具有不同的特点。在 Exchange 本地环境中，组织使用专用的面向公众的 Exchange 服务器，该服务器作为组织公共域名的“代表”。而“云环境”（Office 365）无法提供这种类型的“专用 Exchange 服务器”，该服务器将代表 Office 365 租户的特定域名。请参阅此文章： https://o365info.com/autodiscover-flow-in-an-office-365-environment-part-1-of-3-part-29-of-36/

Question 2

是的，添加反向代理可以正常工作，并防止尝试未加密的连接http://autodiscover.example.com:80/Autodiscover/Autodiscover.xml。但是，A71 注意到，Outlook 还遵循阶段 #1 和 #2 中 HTTPS URI 的 HTTP 重定向，而省略了纯 HTTP 阶段 #3。

从安全角度来看，重定向可能更好，因为 Office 365 的自动发现需要身份验证。使用反向代理，此身份验证将不必要地通过 Web 服务器进行。

此外，由于始终首先请求来自域顶级 Web 服务器的 URI，因此受损的内容管理系统（CMS）可能会劫持这些并窃取用户密码。因此，在 Web 服务器级别配置此项可防止任何 Web 应用程序获取这些请求。

因此，Office 365 自动发现变得更快、更安全。

阿帕奇：

# Office 365 Autodiscover Redirect
Redirect permanent "/Autodiscover/" "https://autodiscover-s.outlook.com/Autodiscover/"

Nginx的：

# Office 365 Autodiscover Redirect
location /Autodiscover/ {
    return 301 https://autodiscover-s.outlook.com$request_uri;
}

Answer