发布Exchange的RPC以及RPC Over HTTPS：ISA2006系列之十九

最新推荐文章于 2024-09-25 11:57:12 发布

meander

最新推荐文章于 2024-09-25 11:57:12 发布

阅读量1.2k

点赞数

分类专栏： Microsoft 文章标签： exchange 服务器防火墙 dns服务器邮件服务器 iis

Microsoft 专栏收录该内容

81 篇文章 0 订阅

订阅专栏

发布 Exchange 的 RPC 以及 RPC Over HTTPS

在前几篇博文中，我们介绍了如何使用 OWA ， SMTP/POP3 来发布 Exchange 服务器，今天我们介绍如何利用 RPC 或 RPC Over HTTPS 来发布 Exchange ，这也是 Exchange 发布系列的最后一篇博文， OWA ， SMTP/POP3 ， RPC ， RPC Over HTTPS 已经涵盖了目前发布 Exchange 所使用的全部技术。

实验拓扑和以前一样， Denver 是域控制器， CA 服务器， DNS 服务器， Exchange 服务器， Beijing 是 ISA2006 服务器， Istanbul 是外网测试客户机。

一利用 RPC 发布 Exchange 服务器

以前我们在 Exchange 系列博文中（ [url]http://yuelei.blog.51cto.com/202879/d-3[/url] ）曾经介绍过， Exchange 的最佳客户端是使用 RPC 协议的 Outlook ， Outlook 是微软为 Exchange 量身定做的客户端软件，可以发挥出 Exchange 的所有功能，如果从性能角度考虑， Outlook 应该是 Exchange 客户端的首选。

Outlook 这么好，为什么以前大家经常用 OWA 访问呢？一是 OWA 使用起来相对简单，二是 Outlook 使用的 RPC 协议对防火墙是个很大的考验 . 。 RPC 的特点是什么？我们在 Exchange 系列博文中曾经分析过，基于 RPC 的服务端口并不固定，每次服务启动时把自己的端口号以及 UUID 注册到 135 端口的终点映射器上。客户端要访问 RPC 服务，首先要连接到 RPC 服务器的 135 端口，向终点映射器提交要访问的服务的 UUID ，根据 UUID 查询这个服务本次启动对应的端口号是多少。这么折腾一番后，客户端才明白自已要访问的服务在哪个端口等着自己，这时才赶紧去连接那个端口。

RPC 的这个特性如果用在局域网内，客户机和服务器能直接访问到，本来也算不了什么。问题是如果客户端和服务器之间还隔了一道防火墙，那防火墙就很头疼了，为什么？你想啊，客户端访问 RPC 服务器的端口号不是固定的，防火墙怎么开放端口呢？如果开放 RPC 有可能使用的全部端口，那就要把 1024 以上的端口都打开，那防火墙就成筛子了。如果只开放固定端口，那就要想办法让 RPC 服务器的管理员配合自己，把 RPC 的服务端口限定在一个范围内。但是这么做一方面比较麻烦，另一方面需要牺牲 RPC 的灵活的特性，并不是好的解决方案。因此如果你是防火墙，你是否也会头疼呢？这个问题尤其是对硬件防火墙来说是很难解决的，但是！但是！ ISA 已经彻底解决了这个问题，确切地说， ISA2004 就已经很完美地解决了这个问题。

ISA 解决 RPC 发布的问题其实很简单， ISA 能够听懂 RPC 客户端和 RPC 服务器之间的会话内容， ISA 根据会话内容可以判断出 RPC 客户端要访问的服务端口号是多少，当 RPC 客户端通过 ISA 访问 RPC 服务时， ISA 会动态地，临时地开放相关端口，允许 RPC 客户端访问进去。当 RPC 客户端访问结束后，端口会自动关闭。你看，这个解决方案如何， ISA 号称是应用层防火墙，和它对 RPC 的完美支持也是有关系的。 ISA 对 RPC 的支持可以通过下图来说明。

说了这么半天，无非是和大家介绍一下 RPC 的原理，希望大家理解 ISA 发布 RPC 服务器从操作上看很简单，但实际上对防火墙的过滤器有很高的技术要求。好，让我们通过实例来看看如何发布 Exchange 的 RPC 服务。如下图所示，在 ISA 服务器上选择新建“邮件服务器发布规则”。

为发布规则取个名字。

访问类型属于客户端访问 RPC 服务器。

用 ISA 发布 Exchange 服务器上的 RPC 服务。

填写 RPC 服务器的 IP 地址。

侦听外部网络。

完成 RPC 服务器的发布。这条发布规则看起来似乎只是把 Exchange 服务器的 RPC 服务发布出来了，其实 Exchange 服务器上所有基于 RPC 的服务现在都可以访问了。

在外网的 Istanbul 上测试一下，启动 Outlook 2003 ，如下图所示，选择“下一步”。

Outlook 询问是否需要升级电子邮件账号，选择“不升级”，准备创建一个 Outlook 配置文件。

选择配置一个电子邮件账号。

后台邮件服务器的类型是 Exchange 服务器。

Exchange 服务器的域名是 denver.contoso.com ，不使用缓存模式，要访问的邮箱是 administrator 。

终于完成了 Outlook 的配置文件。

创建完配置文件后， Outlook 登录进入了管理员邮箱，如下图所示，这说明发布 Exchange 的 RPC 服务成功了。

二利用 RPC Over HTTPS 发布 Exchange 服务器

RPC 发布成功之后，我们就要来考虑一下 RPC Over HTTPS 了， RPC Over HTTPS 我们在 Exchange 系列博文中已经介绍过了，它主要就是考虑到电信部门可能会在公网上封锁 RPC 协议，因此把 RPC 协议封装成 HTTP 或 HTTPS 格式，这样就可以躲过电信的封杀，等封装后的数据包到达 RPC 服务器后，由 RPC 服务器再进行解封装操作，这样就借助 HTTP 的伪装完成了 RPC 数据的传递。

发布 RPC Over HTTPS 并不复杂，其实就是把 Exchange 服务器上的一个 RPC 虚拟目录发布出来。麻烦的是要搭建 RPC Over HTTPS 的环境，做这个实验要有点耐心，我们慢慢来吧。

1）安装 ”HTTP 代理上的 RPC”

首先我们需要让 Exchange 服务器在收到封装成 HTTP 格式的 RPC 数据包后，具有解封装能力，这个功能可以通过安装一个组件“ HTTP 代理上的 RPC ”来完成。组件的安装方式是，在 Exchange 服务器上依次点击开始－设置－控制面板－添加或删除程序－添加／删除 Windows 组件，如下图所示，选择“网络服务”，点击“详细信息”。

在网络服务的子组件中选择“ HTTP 代理上的 RPC ”，如下图所示。

安装完组件后，检查 IIS ，发现 IIS 的默认站点中多了一个 RPC 虚拟目录，虚拟目录中有一个 rpcproxy.dll 的动态链接库，其实就是这个文件具有解封装的功能，客户端也会把封装好的 RPC 数据按照约定发到 Exchange 的 RPC 虚拟目录下。

2）配置“ HTTP 代理上的 RPC ”

Exchange 服务器上安装了“ HTTP 代理上的 RPC ”后，我们还需要对这个组件进行简单的配置，主要是配置端口。默认情况下，“ HTTP 代理 RPC ”代理的 RPC 协议端口范围在 100 － 5000 ，但 Exchange 使用的 RPC 服务端口范围超过了 6000 ，因此我们需要对此进行一番设置。在 Exchange 服务器上运行 Regedit ，在注册表中定位到下列键值 [HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Rpc/RpcProxy/ValidPorts] ，如下图所示，我们把 ValidPorts 的键值改为 denver.contoso.com:100-7000 。 100-7000 是扩大了端口范围，计算机名设置为 denver.contoso.com 是为了和用户访问 Exchange 服务器的域名相匹配。值得注意的是，改完之后无需重启即可生效。

3） IIS 支持 HTTPS

把 RPC 数据包封装成 HTTP 格式后，再利用 SSL 对数据进行加密保护就更安全了，因此我们需要在 Exchange 服务器的 IIS 中申请证书，用以满足客户端进行 HTTPS 访问的需求。好在前面的 OWA 发布实验中我们已经申请过证书了，如下图所示， IIS 中已经有一个颁发给 denver.contoso.com 的服务器证书，这样 Exchange 就可以支持客户端用 HTTP 封装 RPC 后再用 SSL 进行加密了。

上次做 Exchange 的 OWA 发布时，我们把 Exchange 服务器证书导出给了 ISA 服务器，而且 ISA 服务器在侦听器中使用了 Exchange 的证书，如下图所示，这些我们在后续操作中都会用到。

4）配置 RPC 虚拟目录的身份验证

接下来需要配置 RPC 虚拟目录的验证方式，考虑到互联网上用户使用操作系统的多样性，我们准备使用兼容性最好的基本验证方式，虽然基本验证不对用户名和口令进行任何加密保护，但好在 HTTPS 可以帮我们解决这个问题。如下图所示，在 Exchange 的 IIS 管理器中查看 RPC 虚拟目录属性，切换到目录属性的“目录安全性”标签，点击身份验证和访问控制处的“编辑”。