交换CAS服务器|为 Exchange 客户端提供对其邮箱的访问权限 |第 06 部分#36

在本文中，我想回顾一下 Exchange 邮件客户端和“他的”Exchange CAS 服务器的秘密恋情。
Exchange 客户端与其 Exchange CAS 服务器有着非常不寻常且令人兴奋的关系，并且自动发现基础设施是统一的基础设施的亮点。这两个恋人。

继续我们的浪漫比喻；事实上，Exchange 客户端可以与任何可用的 Exchange CAS 服务器建立这些“关系”。

简而言之，Exchange 客户端完全依赖于充当 CAS 服务器角色的 Exchange 服务器，但 Exchange 客户端并未“绑定”到特定的 Exchange CAS 服务器。

那么 Exchange 客户端和 Exchange CAS 服务器之间的这些“秘密关系”有什么特别之处呢？

在下面的文章中，我们将分析这些关系的章程以及自动发现是如何关联或涉及这些关系的。

什么是 Exchange CAS 服务器？

在现代 Exchange 环境中，每台 Exchange 服务器都“担任”一个特定角色（或几个 Exchange 服务器角色）。

我们不会详细介绍每种“Exchange 服务器角色”的具体章程以及 Exchange 2007、2010 和 Exchange 2013 环境之间的差异比较，而是重点介绍两种 Exchange 服务器角色：Exchange CAS 角色和 Exchange 邮箱角色。

为了能够连接 Exchange 基础结构，Exchange 客户端需要查找并连接 Exchange CAS 服务器。

Exchange 邮件客户端查找或定位“他的 Exchange CAS 服务器”的方式是使用自动发现服务。

因此，自动发现过程占据了 Exchange 基础结构的重要组成部分，因为如果没有正确完成自动发现过程，Exchange 客户端将：

• 无法创建新的 Outlook 邮件配置文件。
• 无法连接到他的邮箱。
• 无法获取有关可用 Exchange Web 服务的信息。
• 无法从错误中恢复并自动响应 Microsoft Exchange 环境中的更改。

Exchange CAS 服务器职责

在讨论“详细信息”或关系之前，让我们先回顾一下 Exchange CAS 服务器的“职责”。

以下屏幕截图取自 Exchange Server 2010 架构海报。在图中，我们可以看到担任CAS角色的Exchange 2010服务器的“职责”的详细描述。

Exchange CAS 服务器为“他的客户端”提供多种类型的服务。
我们可以更夸张地说，如果没有 Exchange CAS 服务器，Exchange 客户端就无法与 Exchange 基础架构通信或连接。

如下图所示，我们可以将 Exchange CAS 服务器“服务”分为四大组。

这些“组”中的每一个对于 Exchange 客户端能够连接和使用 Exchange 基础结构来说都同样重要。

Exchange CAS服务器三大责任三角

Exchange CAS服务器负责三大任务：

1. 为 Exchange 客户端提供对其邮箱的访问权限。
2. 提供 Web 服务\为 Exchange 客户端访问 Web 服务。
3. 为 Exchange 客户端提供信息（自动发现信息）。

本文的其余部分将致力于描述的任务：

• 为 Exchange 客户端提供对其邮箱的访问权限。

下一篇——Exchange CAS服务器作为信息+Web服务提供者 |第 07#36 部分将专门介绍 Exchange CAS 服务器任务，描述如下：

1. 提供 Web 服务\为 Exchange 客户端访问 Web 服务。
2. 为 Exchange 客户端提供信息（自动发现信息）。

为 Exchange 客户端提供对其邮箱的访问权限

在本节中，我们重点关注 Exchange CAS 服务器的工作，即充当 Exchange 客户端与其托管在担任邮箱角色的 Exchange 服务器上的邮箱之间的“代理”或“中介”。

在现代 Exchange 环境中，Exchange 客户端连接其邮箱的唯一方法是通过 Exchange CAS 服务器。

Exchange 客户端（例如 Outlook 客户端）无法直接访问其邮箱，该邮箱托管在具有 Exchange 邮箱服务器角色的 Exchange 服务器上。

Outlook客户端访问用户邮箱的方式是通过具有CAS角色的Exchange服务器。

Exchange邮件客户端的分类

在下一节中，我们将描述用于自动发现客户端的流程。因此，我们将使用某种与 Exchange 客户端相关的一般分类非常重要。

自动发现客户端最突出的示例是 Outlook 客户端。 ActiveSync 客户端和 OWA 客户端也可以视为“自动发现客户端”，但该客户端不太依赖自动发现服务。

我们应该使用的另一个分类是，位于内部专用网络上的 Outlook 客户端实现的不同流程（访问 Active Directory）与公共网络上的 Outlook 客户端执行的自动发现流程或者，在无法访问 Active Directory 的网络中。

交易所CAS服务器和透明度概念|不同的代理场景

Exchange 客户端和 Exchange CAS 服务器之间关系的最基本概念之一是“透明性概念”。

Exchange 客户端不需要了解复杂的 Exchange 基础架构，其中可能包括大量服务器、数十甚至数百台服务器。相反，他们只需要找到 Exchange CAS 服务器。

Exchange CAS 服务器是“站在中间”的元素，将 Exchange 客户端和托管用户邮箱的 Exchange 邮箱服务器分开。

Exchange 客户端不需要知道：

1. 托管其邮箱的 Exchange 邮箱服务器的名称
2.托管其邮箱的 Exchange 邮箱服务器的物理位置

使用“中间人”（也称为 Exchange CAS 服务器）概念的显着优点是，定位和连接托管用户邮箱的 Exchange 邮箱服务器的“任务”对 Exchange 客户端是隐藏的。

这种“透明”的概念使得 Exchange 基础设施能够提供多种类型的服务和解决方案。

例如：

场景1：外部邮件客户端

在外部邮件客户端需要访问其邮箱的情况下，无需“公开”托管用户邮箱的内部 Exchange 邮箱服务器。

相反，我们需要做的就是将至少一台 Exchange CAS 服务器配置为面向公共的 Exchange CAS 服务器。

面向公众的 Exchange CAS 服务器接受外部 Exchange 邮件客户端请求，并且 Exchange CAS 服务器“知道”如何定位和连接托管用户邮箱的特定内部 Exchange 邮箱服务器。

场景 2：Exchange 邮箱服务器冗余

如果组织实施集群机制，将用户的邮箱数据库复制到不同的 Exchange 站点，以防“原始邮件”被删除。 （主动）Exchange 邮箱服务器不可用，Exchange CAS 服务器“知道”如何将 Exchange 客户端连接到“其他”Exchange 邮箱存储。

在下图中，我们可以看到不同类型的可能场景的示例，其中 Exchange CAS 服务器需要“服务”Exchange 客户端的请求。

外部与内部 Outlook 客户端使用不同的自动发现机制

当 Outlook 客户端尝试查找并连接其 Exchange CAS 服务器时，内部 Outlook 客户端实现的自动发现过程与外部 Outlook 客户端实现的自动发现过程不同。

此外，Exchange CAS 服务器向内部 Outlook 客户端提供的自动发现信息不同于 Exchange CAS 服务器向外部 Outlook 邮件客户端等提供的信息。

在下一节中，我们将回顾一些自动发现常见场景以及 Exchange 客户端与其 Exchange CAS 服务器之间实现的“关系”的不同特征。

为了能够简化描述，我们以邮件客户端是Outlook的场景为例。

场景 1：内部 Outlook Exchange 客户端 |同一 Active Directory 站点上的 Exchange 邮箱服务器

该场景的章程如下：

内部网络中的用户尝试创建新的 Outlook 邮件配置文件。

当用户激活新建 Outlook 邮件配置文件向导时，将执行以下流程：

1. Outlook 将通过查询本地 Active Directory 来查找可用 Exchange CAS 服务器的名称。
2. Active Directory 使用现有 Exchange CAS 服务器的专用名称或“内部名称”回复可用 Exchange CAS 服务器列表。
3. 使用列表中显示的 Exchange CAS 服务器名称，Outlook 将随机选择其中一个名称并尝试向 Exchange CAS 服务器提交连接请求。
4. Exchange CAS 服务器将查询 Active Directory，查找托管特定用户邮箱的 Exchange 邮箱服务器的名称。
5. Exchange CAS 服务器识别“Exchange 客户端”（Outlook 邮件客户端）的两个章程：
   邮件客户端是 - MAPI 邮件客户端 + 邮件客户端是“内部邮件客户端”。
6. CAS 交换服务器将生成自动发现响应，其中包括与 Outlook 邮件客户端相关的信息以及“信息部分”。
   将提供的信息包括可用 Exchange Web 服务的 URL 地址。自动发现响应中列出的 URL 地址将包括：
   内部主机名 + 外部主机名（内部和外部 URL 地址）。内部 URL 地址不会暴露给公共网络中的主机，并且只能由内部邮件客户端使用。
7. Exchange CAS 服务器将连接“目标 Exchange 邮箱服务器”，并启动将信息从 Exchange 邮箱服务器（邮箱内容）“代理”到内部 Outlook 邮件客户端的过程，反之亦然。

场景 2：外部 Exchange Outlook 客户端

当 Exchange 邮件客户端位于公共网络中时，外部邮件客户端可用于到达其“内部邮箱”（内部 Exchange 基础结构）的唯一方式是通过配置为 -Public Faceing Exchange CAS 的 Exchange CAS 服务器服务器。

在此方案中，将使用已知名称和公共 IP 地址发布 Exchange CAS 服务器。为了能够获得所需的服务，Exchange 邮件客户端需要识别并创建与“面向公众的 Exchange CAS 服务器”的加密通信通道（安全通道）。 ”

Exchange 客户端访问其位于内部 Exchange 邮箱服务器上的“内部邮箱”的请求只能通过“面向公众的 Exchange CAS 服务器”的中介来实现。

Exchange CAS 服务器将接受 Exchange 客户端请求并实现“代理机制”，其中 Exchange CAS 服务器将自己作为其“代表”的邮件客户端“呈现”给内部 Exchange 服务器。 ”

当Exchange CAS服务器从用户邮箱获取所需数据时，Exchange CAS服务器会将数据发送回外部邮件客户端。

注意：在许多情况下，Exchange CAS 服务器不会将“公开”中继到外部客户端，而是由防火墙服务器（例如 ISA\TMG）充当接受外部客户端的“公共实体”。 Exchange 客户端通信请求并将这些请求“转发”到 Exchange CAS 服务器。

当用户激活新建 Outlook 邮件配置文件向导时，将执行以下流程：

1. Outlook 将通过“生成”Exchange CAS 服务器名称来查找可用的 Exchange CAS 服务器的名称。 Outlook 将使用收件人电子邮件地址的 SMTP 域名作为 Exchange CAS 服务器（面向公众的 Exchange CAS 服务器）的“可能名称”。
2. Outlook 尝试向自动发现端点（即面向公众的 Exchange CAS 服务器）提交连接请求。
3. 面向公众的 Exchange CAS 服务器将查询 Active Directory，查找托管特定用户邮箱的 Exchange 邮箱服务器的名称。
4. Exchange CAS 服务器识别“Exchange 客户端”（Outlook 邮件客户端）的两个章程：
   邮件客户端是 - MAPI 邮件客户端 + 邮件客户端是“外部邮件客户端”
5. Exchange CAS 服务器将生成自动发现响应，其中包括与 Outlook 邮件客户端相关的信息，并包括“信息部分”。
   提供的信息包括 - 可用 Exchange Web 服务的公共 URL 地址。自动发现响应中列出的 URL 地址将包括：
   仅外部\公共主机名。
6. 面向公众的 Exchange CAS 服务器将连接“目标 Exchange 邮箱服务器”，并启动将信息从 Exchange 邮箱服务器（邮箱内容）代理到外部 Outlook 邮件客户端的过程，反之亦然。

场景 3：外部 Exchange 客户端 |两个 Exchange 站点
两个面向公众的 Exchange CAS 服务器

Exchange CAS 服务器能够提供的另一项有趣的服务被描述为：重定向。

在 Exchange 企业环境中，例如在全球拥有多个站点的大公司，典型的场景是多个 Exchange 站点的情况。

如果有多个 Exchange 站点，组织可以决定实施以下情况之一：

选项 1：仅“公开”特定的 Exchange CAS 服务器，该服务器将充当全球所有 Exchange 客户端的“焦点”或网关（这是上一节中描述的场景，该场景描述为- 代理服务）

选项 2：为每个公司站点发布多个面向公众的 Exchange CAS 服务器或面向公众的 Exchange CAS 服务器。

在多个 Exchange 站点 + 各种面向公众的 Exchange CAS 服务器的方案中，有两种主要方案用于管理外部邮件客户端查找所需 Exchange CAS 服务器的方式。

配置单个面向公众的 Exchange CAS 服务器是重点。

在此方案中，虽然 Exchange 基础结构包括多个“面向公众的 Exchange CAS 服务器”，但只有一个“面向公众的 Exchange CAS 服务器”将映射到公共域名的自动发现记录。

在我们的示例中，我们有两个物理 Active Directory 和 Exchange 站点：纽约站点和洛杉矶站点。

公共域名为 o365info.com ，自动发现记录 - autodiscover.o365info.com 映射到公共 IP 地址使用公共 IP 地址的“纽约面向公众的 Exchange CAS 服务器”：212.25.80.239

在我们的场景中，名为 Bob 的用户使用电子邮件地址 - [email protected] 需要连接他的 Exchange 邮箱，该邮箱托管在洛杉矶的 Exchange 邮箱服务器上天使的网站。

当 Outlook 客户端启动自动发现过程时，他将找到并连接“纽约站点面向公众的 Exchange CAS 服务器”。 ”

“纽约站点面向公众的 Exchange CAS 服务器”知道

• Bob的邮箱位于另一个Exchange站点（洛杉矶天使的站点）
• 洛杉矶天使网站上有一个面向公众的 Exchange CAS 服务器，可以为外部邮件客户端请求提供服务。

由于此信息，“纽约站点面向公众的 Exchange CAS 服务器”将不会自行为 Exchange 客户端提供服务，而是将“重定向指令”发送到外部 Outlook Exchange 客户端。

重定向指令包括“洛杉矶站点 Public faces Exchange CAS 服务器”的名称 (FQDN)。

外部 Exchange 客户端重新开始该过程，但这一次，Exchange Outlook 客户端尝试连接“洛杉矶站点面向公众的 Exchange CAS 服务器”。

鉴于用户提供了正确的凭据，并且“洛杉矶站点面向公众的 Exchange CAS 服务器”具有所需的公共证书，“洛杉矶站点面向公众的 Exchange CAS 服务器”将找到托管 Bob 邮箱的 Exchange 邮箱服务器，并在内部 Los Angeles Exchange 邮箱服务器和外部 Exchange 客户端 (Bob) 之间来回代理连接请求。