我应该为 Exchange 基础结构使用单一命名空间吗？ |第 1#2 部分 |第 17 部分#36

当前的文章致力于讨论有趣但不太明确的主题——Exchange 基础设施命名空间。

Exchange 服务器体系结构使我们能够对基于各种命名空间的内部 Exchange 客户端和外部 Exchange 客户端使用不同的接口。

我将在本文中尝试回答的主要问题是：

• 使用不同的命名空间是好是坏？
• 基于两个不同命名空间的Exchange环境有何特点？

当阅读文章标题时，结果会弹出很多问题：

1. Exchange 基础设施的“公共命名方案”或“单一名称空间”的含义是什么？
2. 为什么我需要使用单一公共命名方案？
3. 我当前的 Exchange 基础结构是如何配置的？

我认为花时间很重要，因为很快，每个 Exchange 管理员都需要处理以下主题：为 Exchange 基础设施使用一个公共命名方案。

关联之前的问题

问题 1 - Exchange 基础设施的公共命名方案有何含义？

Q2 - 为什么我需要使用一个公共命名方案？
我们无法通过证明一个简短的答案来回答这个问题，但是，尽管存在这个障碍，我会尝试尽快回答这个问题，并且，获得更详细、更全面的答案；您将需要阅读本文的其余部分。

Exchange 基础结构对象通过使用主机名和 URL 地址进行“寻址”。
Exchange 客户端之间的通信和 Exchange 服务器本身之间的通信是通过使用主机名对特定 Exchange 服务器进行寻址来实现的。

Exchange CAS 服务器通过向其客户端提供包含主机名的 URL 地址来向其客户端发布 Exchange Web 服务。

交换架构|以前的命名空间约定与现代的命名空间约定

Exchange 服务器体系结构 包括实现与内部和外部 Exchange 客户端的不同接口的内置功能。

基于三个主要元素的不同界面的实现

1. 通讯协议
2. 认证协议
3. 命名空间

以前的 Exchange 服务器架构与现代 Exchange 架构 |与内部 Exchange 客户端和外部 Exchange 客户端的接口。

在以前的 Exchange 服务器版本（例如 Exchange 2003、2007 和 2010）中，典型的约定是配置 Exchange 服务器，以便对内部 Exchange 客户端和外部 Exchange 客户端使用不同的接口。

此配置背后的主要思想是，内部网络与外部网络相比具有不同的需求和不同的特征，因此，需要将 Exchange 配置为在与内部 Exchange 客户端和外部 Exchange 客户端交互时使用不同的配置设置。

在现代 Exchange 环境（例如 Exchange 2013）中，两种环境（内部网络与公共网络）之间的差异缩小并消失。

换句话说，尽管 Exchange 2013 体系结构能够实现与内部 Exchange 客户端和外部 Exchange 客户端不同的接口，但大多数时候，标准做法是对内部 Exchange 客户端和外部 Exchange 客户端使用相同的接口。外部 Exchange 客户端。

例如：

在以前的 Exchange 服务器版本（Exchange 2003、2007、2010）中，常见配置是对内部 Exchange 客户端和外部 Exchange 客户端使用不同的通信协议和不同的命名空间。

• 与内部 Outlook 客户端的接口是使用 RPC 协议和基于内部域名（例如“本地”域后缀）的内部命名空间来实现的。
• 与外部 Outlook 客户端的接口是使用 RPC/HTTPS 协议 (Outlook Anywhere) 和基于公共域名（例如“com”域后缀）的公共命名空间来实现的。

注意： 将 Exchange Server 2010 定义为“以前的 Exchange 服务器版本”的一部分并不是“科学定义”。很多时候，组织根据现代邮件环境的特征来实施 Exchange 2010 基础结构。

标准约定规定需要区分和分离内部 Exchange 客户端与外部 Exchange 客户端的 Exchange 接口，随着时间的推移，该约定已更改为基于“简化概念”的新约定，其中内部 Exchange 客户端的 Exchange 接口与外部 Exchange 客户端的 Exchange 接口不同。 . 外部 Exchange 客户端配置为相同的接口。

例如，在 Exchange 2013 环境中，与 Outlook 客户端唯一可用的通信协议是 Outlook Anywhere（RPC\HTTPS 或 MAPI\HTTPS）。

换句话说，我们不能为内部 Outlook 客户端和外部 Outlook 客户端设置不同的通信协议。

关于“命名空间”的主题，理论上，Exchange 2013 允许我们对内部 Outlook 客户端使用“内部命名空间”选项，而对外部 Outlook 客户端使用“外部命名空间”选项，但大多数时候我们不会实现此选项。

与“新趋势”相关的另一个因素是，我们“取消”与内部 Exchange 客户端和外部 Exchange 客户端的不同 Exchange 接口，因为目前公共证书不能也不会支持包含非公共或公共域名后缀。

换句话说，即使我们决定在需要续订公共证书时继续使用 Exchange 内部和外部命名空间，我们也不能要求将内部主机名包含在证书中。

注意 - 您可以在文章 - 公共 SAN 证书 | 中阅读有关新公共证书标准的更多信息。已弃用内部服务器名称中的支持 |第 19 部分#36

基于内部和外部命名空间的现有 Exchange 基础架构

在上一节中，我们提到现代 Exchange 环境正在朝着内部 Exchange 客户端与外部 Exchange 客户端的 Exchange 接口整合或统一的方向发展。

然而，实际上，有许多组织仍然使用最近的约定，其中我们使用内部 Exchange 客户端和外部 Exchange 客户端实现两种不同的 Exchange 接口。

在接下来的部分中，我们将回顾此类基础设施的一些示例，其中我们使用两种不同的 Exchange 接口、该环境的特征以及 Exchange 服务器与其客户端之间实现的流程。

在阅读这些信息时，您可能会感觉到我的观点是，使用“分离”的 Exchange 接口的组织应该致力于统一，如果该 Exchange 接口成为一个全球接口。

下一篇文章 - 交换基础设施 |实现单域命名空间方案 |第 2 部分#2 |第 18#36 部分，将处理我们决定对内部 Exchange 客户端与外部 Exchange 客户端使用单个命名空间的场景中的“如何做”部分。

Exchange 基础设施 - 主机名和 FQDN

大多数时候，当我们使用术语“主机名”时，我们指的是另一个术语 - FQDN。

FQDN 是主机的“完整”或“完整”名称，包括两部分：

1.主机名
关于主机名的主题，每当我们安装新服务器时，我们都需要为服务器提供一个唯一的名称，我们可以将其视为服务器主机名。

如果我们想要更准确的话，在基于 Microsoft 的环境中，Exchange 服务器主机名是 NetBIOS 名称。

注意：很多时候，我们会使用 DNS 基础设施将其他主机名“附加”到 Exchange 服务器，但我们稍后会讨论这个问题。

2.域名
默认情况下，Exchange 基础结构从 Active Directory 域名继承其域名。

如果使用私有域名配置 Active Directory，则 Exchange 基础结构也将使用私有域名后缀。

在我们使用“双命名空间”（即私有命名空间和公共命名空间）的场景中，内部 Exchange 客户端将使用 Exchange 服务器的内部 FQDN 和包含内部或私有域名的 Exchange URL 地址来寻址 Exchange 资源。

外部 Exchange 客户端无法使用“私有命名方案”寻址或访问 Exchange 资源，因此，我们需要构建额外的命名空间基础设施，供“公共”或外部 Exchange 邮件客户端使用。

可能的命名空间场景矩阵

为了以清晰的格式安排事物，让我们回顾一下命名空间可能的“组合”。

我们将回顾的这个场景的特点如下：

场景 1 - Active Directory 私有命名空间 | Exchange 双命名空间

在这种情况下，Active Directory 基于私有命名空间，例如 o365info.local

Exchange 命名空间基础结构基于双命名空间基础结构。

• 内部 Exchange 客户端将使用内部\私有命名空间寻址 Exchange 资源 - o365info.local
• 外部 Exchange 客户端将使用内部\私有命名空间寻址 Exchange 资源 - o365info.com

场景 2 - Active Directory 私有命名空间 |交换单一命名空间

在这种情况下，Active Directory 基于私有命名空间，例如 - o365info.local

Exchange 命名空间基础设施基于单一命名空间基础设施，这意味着私有命名空间和公共命名空间将是相同的。

在这种情况下，我们需要更改默认的 Exchange 服务器 FQDN，默认情况下，该服务器使用 Active Directory 私有域名 (o365info.com)

• 内部 Exchange 客户端将使用内部\私有命名空间寻址 Exchange 资源 - o365info.com
• 外部 Exchange 客户端将使用内部\私有命名空间寻址 Exchange 资源 - o365info.com

场景 3 - Active Directory 公共命名空间 |交换单一命名空间

在这种情况下，Active Directory 基于公共命名空间，例如 o365info.com

Exchange 命名空间基础设施基于单一命名空间基础设施，这意味着私有命名空间和公共命名空间将是相同的。

在这种情况下，我们不需要更改默认的 Exchange 服务器 FQDN，默认情况下，该服务器使用 Active Directory 公共域名 (o365info.com)

• 内部 Exchange 客户端将使用内部\私有命名空间寻址 Exchange 资源 - o365info.com
• 外部 Exchange 客户端将使用内部\私有命名空间寻址 Exchange 资源 - o365info.com

问：为什么我应该避免使用“Exchange 双命名空间”选项？

A：该问题的答案的简短版本是 - 由于两个主要原因：

1. 2015年后SAN证书上没有内部服务器名称

如果我们使用 Exchange 双命名方案基础结构，Exchange 公共证书将需要包含内部主机（使用 Active Directory 私有域名的主机）的主机名和公共主机名。

自 2015 年 11 月 1 日起，将不再支持此类配置

注意 - 如果您需要阅读有关此主题的更多信息，请阅读文章 - 公共 SAN 证书 |已弃用内部服务器名称中的支持 |第 19 部分#36

2.因为这是“正确的方式”

答案的“简短版本”是，使用 Exchange 双重命名方案基础设施选项而不是对 Exchange 基础设施使用单一公共命名方案并不是“正确的方法”。

使用双命名空间的原因是因为历史原因不再有效或与现代环境不再相关。

使用 Exchange 双命名方案基础设施选项会使事情变得复杂，使需要记住两种不同命名约定的 Exchange 客户端变得困难，使解决“Exchange 问题”等变得困难。

Microsoft Active Directory 和私有域名

“本地 Active Directory”由域名表示。

我们用作 Active Directory 域名的域名可以视为“私有域名”或“公共域名”。

从技术上讲，Active Directory“不关心”我们使用私有域名还是公共域名。

如前所述，默认的 Exchange 域命名空间基础结构是基于 Active Directory 域名基础结构构建的。

如果结果是 Exchange 基础结构必须使用两个域名基础结构，许多组织都会为 Active Directory 使用私有域名。

Q1：私有域名的含义是什么？

A2：私有域名的“技术实现”是使用以“local”为后缀的域名。

“本地”域名后缀是保留后缀，无法购买带有“本地”后缀的域名。

“公共域名”一词用于我们从 GoDaddy 等公共提供商处购买域名的情况。

问题2：为什么Active Directory要使用私有域名？

A2：在过去的好日子里，一般概念是使用 Active Directory 的私有域名是首选方法，因为这是一种良好的安全实践。

我一直认为这只是安全人员的胡言乱语，因为我从来没有设法理解这个假设的原因，也没有人能为我提供这个假设的真正解释。

这种使用私有域名作为 Active Directory 域名的“理论”基于错误的假设。人们的想法是，使用“私有域名”是必要的或强制性的，以保护私有发起网络免受“公共网络”中存在的风险和危害，从而损害私有组织资源。

我使用术语“mambo jumbo”来描述“使用私有域名”保护内部网络资源的理论，因为这根本不正确。

内部资源使用私有IP方案（私有互联网地址分配）。因此，内部资源无法直接与使用公共 IP 地址的“外部资源”进行通信。

唯一可能的方法是通过“代理”，例如保护内部网络的防火墙，并基于“防火墙”规则，根据管理员想要/需要向公共网络公开的内容“公开”特定的网络主机（服务器）。

如果我们想寻找更多心理学家对“私人Active Directory域阴谋论”的解释，那就是，在过去，基本假设是组织的网络是一个孤立的地方，永远不需要暴露给“外部网络”或驻留在公共网络上的外部用户。

这种假设在今天看来有点激进，因为现在的情况恰恰相反——大多数组织用户使用公共网络，并且必须每小时访问“内部网络资源”，例如 Exchange CAS 服务器。

豺狼先生和海德先生的综合症

那么我的观点是什么？

我的观点是，因为许多甚至大多数组织都遵循这种“私有域缺失假设”，所以结果相当混乱。

使用 Active Directory 私有域命名方案的组织必须管理两个独立的命名基础设施。

“私有命名方案”将仅由内部网络客户端使用，而公共命名方案将仅由公共客户端使用。

我什至可以将这种情况比作一个患有人格分裂病的人！

我们使用私有域名与使用“外部\公共”域名并行的趋势即将结束，因为新标准或公共证书不再支持使用具有私有域名的主机名，例如作为本地域名后缀。

Exchange 基础架构上的公开可用与私有 Active Directory 基础架构的比较。

如前所述，与 Active Directory 相比，Active Directory 仅服务于内部客户端，不会向公共客户端“暴露自己”，而 Exchange 基础设施则相反。

• Exchange 基础设施必须将自己“暴露”给位于公共网络上的外部 Exchange 客户端
• 公共网络基础设施必须使用公共主机名

在下图中，我们可以看到面向公众的 Exchange CAS 服务器需要运行的“两个世界”的示例。

问：如果Active Directory使用私有域名，Exchange如何为外部客户端提供服务？

A：有两种可能的“解决方案”：

选项 1：维护两个不同的域名方案

在这种情况下，Exchange 基础结构还将使用 Active Directory 私有域命名空间与内部 Exchange 客户端进行通信。

Exchange 基础结构将使用公共域名方案与外部邮件客户端进行通信。

在这种情况下，Exchange基础设施同时“链接”到两个不同的域名。

例如，在我们使用 Exchange CAS 服务器的场景中，该服务器还将为外部邮件客户端（面向公共的 Exchange CAS 服务器）提供服务，内部 Exchange 客户端将使用名为 - ex01.o365info.local

外部 Exchange 客户端将使用名为 - mail.o365info.com 的主机对面向公众的 Exchange CAS 服务器进行寻址

方案2：使用“统一域名方案”的交换基础设施

在这种情况下，Exchange 基础结构将仅使用内部+外部邮件客户端均采用的公共域名方案。

Exchange 基础结构将仅“附加”或“链接”到公共域名，而不是 Active Directory 专用域名。

例如，在我们使用同时为外部邮件客户端（面向公众的 Exchange CAS 服务器）提供服务的 Exchange CAS 服务器的场景中，内部 Exchange 客户端将使用主机名 - mail.o365info.com

邮件客户端“不关心”其他主机名，这些主机名存在于面向公众的 Exchange CAS 服务器提供的证书中 (ex01.o365info.lcoal)