OWA 客户端协议连接流程在 Exchange 2013/2007 中共存3/4 |18#23

本文是四篇文章系列中的第三篇文章，主题为“Exchange 2013/2007 共存环境和邮件客户端协议连接流程”。

在本文中，我们将回顾以下客户端协议连接流：
OWA Exchange 2013/2007 共存环境中的 Exchange 2007 客户端。

为了能够了解 Exchange 2013/2007 共存环境中不同的“Exchange 客户端”连接协议流，我们将回顾 Exchange 2007 客户端和 Exchange CAS 2013 服务器之间存在的五种类型的“关系”：

• 自动发现客户端 - 协议连接流程（第 2#4 部分）
• Outlook 客户端 - 协议连接流程（第 2#4 部分）
• OWA 客户端 - 协议连接流程（第 3#4 部分）
• ActiveSync 客户端 - 协议连接流程（第 4#4 部分）
• Exchange Web 服务客户端 - 协议连接流程（第 4#4 部分）

本节专门介绍 Exchange 2013/2007 共存环境中的 OWA 客户端协议连接流。

当阅读不同 OWA 客户端协议连接场景的描述以及每个场景的详细信息时，您可能会感到有点头疼。

没关系，尽管存在“轻微头痛”的风险，但我认为值得付出努力，以便能够理解 Exchange 2013/2007 共存环境中 OWA 客户端协议连接流的概念和逻辑。

OWA 邮件客户端区别于其他 Exchange 客户端的两个关键功能

OWA 邮件客户端的客户端协议连接流程有两个不同于其他邮件客户端（例如 Outlook 或 ActiveSync 邮件客户端）的主要特征。

1. Exchange 2013/2007 共存环境
   与大多数客户端协议连接流程（其中 Exchange CAS 2013 代理邮件客户端向其“旧版 Exchange CAS 服务器”发出请求）相比，在 Exchange 2007 OWA 客户端场景中，Exchange CAS 2013将不代理 2007 OWA 客户端连接请求，而是向 2007 OWA 客户端发送重定向命令。
2. 手动指定 Exchange 服务器的主机名
   邮件客户端（例如 Outlook 和 ActiveSync）将使用 Exchange 自动发现服务来查找为其提供服务的 Exchange 服务器名称。对于 OWA 邮件客户端，不同之处在于用户需要手动键入包含 Exchange 服务器名称的 FQDN 的 URL 地址。在多个面向公众的 Exchange 站点的情况下，来自区域面向公众的 Exchange 站点的 OWA 邮件客户端可以选择使用“主命名空间”作为 Exchange 服务器名称，或使用“区域命名空间”作为 Exchange 服务器名称。我们将在面向多个公众的 Exchange 站点环境中的 OWA 客户端协议连接流部分中更详细地讨论此方案

OWA 邮件客户端 - 手动指定 Exchange 服务器的主机名

OWA 客户端与其他 Exchange 邮件客户端（例如 Outlook 或 Mobile (ActiveSync) 客户端）之间的主要区别在于，大多数时候，OWA 客户端将手动键入 Exchange 服务器的 URL 地址，而不是获取“Exchange 服务器的名称”。自动发现过程中的“服务器”。换句话说，OWA 客户端需要知道自己的 Exchange 服务器名称，而其他 Exchange 客户端则使用自动发现过程来“为其定位”所需的 Exchange 服务器名称。

对于“区域 OWA 用户”，例如：其邮箱位于“区域 Exchange 站点”（我们场景中的马德里站点）上的 OWA 用户，需要访问其邮箱的 OWA 用户可以使用以下命名之一Exchange 服务器主机名的约定选项：

1. 使用主命名空间 - 在我们的场景中，代表“面向纽约公众的 Exchange CAS”的“主命名空间”是：mail.o365info.com
   如果“马德里 OWA 用户”使用主命名空间作为 Exchange 服务器名称（OWA URL），“面向纽约公众的 Exchange CAS”识别出该用户是“马德里 OWA 用户”，并将其重定向到“面向马德里公众的 Exchange”中科院”。
2. 使用区域命名空间 - 在“马德里 OWA 用户”场景中，OWA 用户可以使用区域命名空间作为 Exchange 服务器名称（OWA URL）。例如：europe.mail.o365info.com。在这种情况下，OWA马德里用户将直接访问“他的Exchange服务器”。

注意：“区域 OWA 邮件客户端”场景和重定向过程并非唯一或仅与 Exchange 2007 OWA 客户端相关，而是与以下场景中涉及的任何 Exchange OWA 客户端相关：多个面向公众的 Exchange 站点和区域命名空间。

Exchange 2013/2007 共存环境中 Exchange 2007 OWA 邮件客户端的各个章程

为 Exchange 2007 OWA 邮件客户端（其邮箱托管在 Exchange 2007 邮箱服务器上的 Exchange 用户）提供服务的过程与“其他邮件协议”不同，因为 Exchange 2013“不支持不知道”如何代理 OWA 邮件客户端请求。
相反，Exchange CAS 2013 会将“Exchange 2007 OWA 邮件客户端”重定向到其 Exchange 2007 CAS 服务器。

这是使用“遗留命名空间”的主要原因。 Exchange 2013 CAS 服务器将发送到“Exchange 2007 OWA 邮件客户端浏览器”的“重定向消息”包括能够“服务”Exchange 2007 OWA 邮件客户端请求的 Exchange 2007 CAS 服务器的 URL 地址。

Exchange 2013 CAS 服务器提供的 URL 包括指向 Exchange 2007 CAS 服务器的 FQDN（“旧命名空间”）。

静默重定向和 SSO 的概念

在前面的部分中，我们回顾了 Exchange 2013 CAS 将 Exchange 2007 客户端重定向到其“目标 Exchange CAS 服务器”的两种不同场景。

Exchange 2013 CAS CU2 使用的重定向方法包括与以下过程相关的两个主要改进： 重定向 OWA 邮件客户端。

2013 CAS CU2 的改进包括：

1. 静默重定向
2. 单点登录

旧版本的 Exchange CAS 服务器和 OWA 重定向方法

尽管 Exchange 2013 CU2 服务器版本以改进的方式实现了“OWA 重定向”过程，但需要强调的是，“OWA 重定向方法”并不是新的 Exchange 方法，并且 OWA 重定向方法已包含在以前版本的 Exchange 中服务器（据我所知，自 Exchange 2007 服务器版本以来）。

在以前版本的 Exchange 服务器中，Exchange 服务器实现的用于“将 OWA 客户端重定向到其 Exchange 服务器”的 OWA 重定向方法可以被描述为“被动”。

“OWA重定向”是通过显示“消息窗口”来实现的，该消息由Exchange服务器发送到OWA客户端。

“重定向信息”以“可点击链接”的形式呈现给 OWA 用户。

我将这种方法描述为：“被动重定向”，因为 Exchange 服务器的唯一职责是显示一条带有 OWA 客户端链接的消息。

用户的责任是：

• “了解”消息中显示的链接是指向“正确的 Exchange 服务器”的链接
• 他需要单击将他重定向到他的 Exchange CAS 服务器的链接。

除了用户要求“明白”需要点击链接外，OWA用户还有一次体验，可以用“双重登录”来形容。

其含义是：OWA 用户必须再次向“新目标 Exchange 服务器”（“目标”Exchange 2007 CAS）重新提供其用户凭据。

Exchange 2013 CAS 服务器版本 CU2 和 OWA 重定向方法

Exchange 2013 CAS服务器版本CU2，包括显着改善“Exchange OWA客户端”体验的两大功能：

• 无提示重定向（主动重定向） - Exchange 2013 CAS 服务器知道如何向 Exchange 2007 OWA 浏览器发送重定向“命令”，该命令会将 OWA 会话重定向到“新 URL 地址”（Exchange 的旧 URL 地址） 2007 CAS 服务器）。
• SSO - Exchange 2013 CAS 服务器知道如何将 OWA 用户凭据“传输”或“转发”（代理）到“目标”Exchange 2007 CAS 服务器。

Exchange CAS 2013 用于重定向 OWA 客户端的方法被描述为：“静默”，因为 OWA 用户在整个过程中不参与。 OWA 用户“看到”的唯一一件事是浏览器上的短暂刷新（来自目标 Exchange 服务器的 OWA 登录页面中的 Exchange 2013 CAS OWA 登录页面的重定向过程）。

“Exchange 2007 OWA 客户端”不知道复杂的重定向过程。从“Exchange 2007 OWA 客户端”的角度来看，这个过程是透明的。

注意：虽然我们在 Exchange 2007 OWA 客户端上下文中提到了 Exchange 2013 CAS 方法：静默重定向 + SSO，但该方法在任何类型的 Exchange OWA 客户端中都可以在多个公共场景中实现。面向交换站点。

问题1：OWA客户端静默重定向过程实际上是如何实现的？

A1：“OWA重定向过程”，是通过Exchange CAS 2013和客户端浏览器的“配合”来实现的。 Exchange CAS 2013 发送包含“新 URL 地址”的 HTTP 重定向命令。客户端浏览器接受重定向命令并寻址“目标URL地址”

OWA 连接流程 | Exchange 2007 客户端 |应用场景

场景 1：外部 2007 OWA 客户端 |用户邮箱位于纽约站点。

场景章程：一个外部Exchange 2007 OWA客户端，需要访问他的邮箱。

• Exchange 用户类型：Exchange 2007 客户端（邮箱托管在 Exchange 2007 邮箱服务器上的 Exchange 用户）。
• Exchange 邮箱服务器位置：托管用户邮箱的 Exchange 2007 邮箱服务器位于纽约站点。
• 纽约站点包括两个公共 Exchange CAS 服务器：Exchange 2013 CAS 和 Exchange 2007 CAS。

OWA协议连接流程，将实现如下：

1. 在“New York Exchange 2007 OWA 客户端”中，键入以下 URL 地址 https://mail.o365info.com/owa
   OWA 客户端使用的 URL 地址，包括 FQDN：mail.o365info.com，它指向位于纽约站点的面向公众的 CAS2013 服务器（编号 1）。
2. 外部 OWA 客户端提供其用户凭据。

3. CAS2013 使用用户凭据并执行 Active Directory 查找。 CAS2013 确定：

   • 用户邮箱版本为：2007
4. 本地站点包括面向公众的 Exchange 2007CAS 服务器
5. 面向公众的 Exchange 2007 CAS 服务器的 URL 地址是：https://legacy.mail.o365info.com/owa

6. Exchange CAS2013 将实施两种不同的程序：

   1. 启动静默重定向过程 - “面向公众的 Exchange 2013 纽约”将重定向命令发送到“外部 Exchange 2007 OWA 客户端浏览器”，其中包括“面向公众的 Exchange 2007 CAS 服务器”的 FQDN：legacy.mail.o365info.com（编号2）。
7. 启动 SSO 流程 - “纽约面向公众的 Exchange 2013”通过将 Exchange 2007 OWA 用户凭据转发（代理）到“面向公众的 Exchange 2007 CAS 服务器”（编号8 ）来实现 SSO 流程）。

场景 2：Exchange 2007 OWA 客户端 |用户邮箱位于洛杉矶站点。

场景包机：一个外部的Exchange 2007 Outlook客户端，需要访问他的邮箱。

注意：为了简化步骤的描述，我们将仅涉及“外部 OWA 2007 客户端”，但同样的逻辑和流程也适用于“内部 OWA 客户端”。

• Exchange 用户类型：Exchange 2007 客户端（邮箱托管在 Exchange 2007 邮箱服务器上的 Exchange 用户）。
• Exchange 2007 用户邮箱托管在洛杉矶站点上（Exchange 2007 邮箱服务器位于洛杉矶站点）。
• 托管用户邮箱的 Exchange 2007 邮箱服务器和面向公众的 Exchange 2013 CAS 服务器不位于同一 Active Directory 站点。
• 纽约站点有一个“本地”Exchange 2007 CAS。

在这种情况下，将保持相同的逻辑。 Exchange CAS 2013 服务器将 Exchange 2007 OWA 客户端重定向到面向公众的 Exchange 2007 CAS 服务器。
“纽约面向公众的 Exchange 2007 CAS 服务器”对用户进行身份验证，执行 Active Directory 查找并确定用户邮箱的位置在洛杉矶站点。

• “面向纽约公众的 Exchange 2007 CAS 服务器”将把请求代理到“内部洛杉矶 Exchange 2007 CAS 服务器”（编号 3）。
• “洛杉矶 Exchange 2007 CAS 服务器”会将请求代理到“洛杉矶 Exchange 2007 邮箱服务器”（编号4）。

多个面向公众的 Exchange 站点环境中的 OWA 客户端协议连接流

在下一节中，我们将回顾外部 OWA 马德里用户尝试访问其邮箱并使用主命名空间作为 URL 地址的 OWA 客户端协议连接流程。

当 OWA 马德里用户使用主命名空间 (https://mail.o365info.com/owa) 时，主机名将解析为“纽约”的 IP 地址面向公众的 Exchange CAS 服务器”。

当“面向纽约公众的 Exchange CAS 服务器”识别出用户被视为“马德里用户”并且该 OWA 客户端应访问“他的面向公众的 Exchange CAS 服务器”时，“面向纽约公众的 Exchange CAS 服务器”将执行一种方法描述为：静默重定向+SSO。

注意：静默重定向和 SSO 方法不仅与 Exchange 2007 OWA 客户端方案相关，还与任何其他类型的外部 OWA 客户端（例如 Exchange 2013 OWA 客户端）相关。

外部 OWA 场景

在下一节中，我们将演示 OWA 流程场景，其中“OWA 马德里用户”（其邮箱托管在马德里站点的用户）将使用主命名空间作为 URL 地址：https:// mail.o365info.com/owa

在下图中，我们可以看到 Exchange 公共基础设施包括两个面向公众的 Exchange 站点：纽约站点和马德里站点。每个 Exchange 站点都有一个面向公众的 Exchange CAS 服务器。

• “纽约面向公众的交易所 CAS”的公共名称是：mail.o365info.com
• “马德里面向公众的 Exchange CAS”的公共名称是：europe.mail.o365info.com

“地区 OWA 用户”（我们场景中的马德里用户）可以选择使用可选 URL 地址之一。

面向马德里公众的 Exchange CAS 服务器由专用命名空间（区域命名空间）表示：europe.mail.o365info.com

如果外部 OWA 马德里用户熟悉“马德里区域命名空间”，他可以使用 URL 地址：https://europe.mail.o365info.com/owa

OWA 马德里用户可以使用的附加选项是：使用主命名空间，这将“引导他”到“面向纽约公众的 Exchange CAS”。

在这种情况下，OWA 马德里用户可以使用 URL 地址：https://mail.o365info.com/owa

当“纽约面向公众的交易所 CAS”收到“OWA 马德里用户”的连接请求时，他将实施一种被描述为“静默重定向”的方法，该方法将 OWA 马德里用户重定向到“他的马德里面向公众的交易所” CAS 服务器”。

场景3：OWA客户端|位于马德里网站的用户邮箱 |区域命名空间 |目标站点=面向公众

场景包机：一个外部的Exchange OWA 2007客户端，需要访问他的邮箱。

• Exchange 2007 用户邮箱托管在马德里站点上（Exchange 2007 邮箱服务器位于马德里站点）。
• “马德里交换站点”被视为： 面向公众的交换站点。
• 外部 OWA 用户使用主命名空间作为 Exchange 服务器的 URL 地址 (https://mail.o365info.com/owa)。
• “分配”给马德里站点的区域命名空间是：europe.mail.o365info.com

在当前场景中，“OWA 马德里用户”使用 URL 地址：https://mail.o365info.com/owa 访问他的邮箱。

OWA协议连接流程将实现如下：

1. 马德里 Exchange 2007 OWA 客户端，键入以下 URL 地址 https://mail.o365info.com/owa
   FQDN：邮件。 o365info.com 指向“面向纽约公众的 Exchange CAS 服务器”（编号1）。
2. 外部 OWA 客户端提供其用户凭据。

3. CAS2013 使用用户凭据并执行 Active Directory 查找。 CAS2013 确定：

   • 用户邮箱版本为：2007
4. 托管用户邮箱的 Exchange 2007 邮箱服务器位于马德里站点
5. 远程站点（马德里站点）是面向公众的 Exchange 站点
6. “面向马德里公众的 Exchange CAS 服务器”的“OWA 地址”为：https://europe.mail.o365info.com/owa

7. Exchange CAS2013 将实施两种不同的程序：

   1. 启动静默重定向过程 - “纽约面向公众的 Exchange 2013”向“马德里 Exchange 2007 OWA 客户端浏览器”发送重定向命令，其中包括“欧洲 Exchange 2007 面向公众的 Exchange CAS”的 FQDN：europe.mail.o365info.com（编号2）。
8. 启动 SSO 流程 - “纽约面向公众的 Exchange 2013”通过将 Exchange 2007 用户凭据转发（代理）到“欧洲 Exchange 2007 面向公众的 Exchange CAS”（编号8 ）来实施 SSO 流程）。