Outlook通过RPC或RPC over HTTPS访问Exchane邮箱:Exchange2003系列之四

权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 [url]http://yuelei.blog.51cto.com/202879/75398[/url]

Outlook 通过 RPC/RPC Over HTTPS 访问 Exchange 邮箱   我们在前面的文章中已经介绍了 Exchange 邮箱的创建和配置，现在我们来看看如何访问 Exchange 邮箱。访问邮箱我们可以通过以下方式 A  用 Outlook 作客户端软件   通过 RPC/RPC Over HTTPS 访问 B  用 IE 作客户端软件    通过 HTTP/HTTPS 访问 C  用 Outlook Express 作客户端软件   通过 SMTP/POP3 访问 D  用 Outlook Express 作客户端软件   通过 IMAP 访问 E  通过 EXIFS 访问   从性能和安全考虑，用户倾向于采用 Outlook 和 IE 访问邮箱，这两种方式无论是性能还是安全与其他方式相比明显占优。 Outlook 和 IE 再进行对比，显然号称 Exchange 最佳客户端软件的 Outlook 还是更胜一筹。下面我们就来看看如何用 Outlook 通过 RPC/RPC Over HTTPS 访问 Exchange 邮箱。   在完成具体实现方法之前，我们要先了解一下 RPC 协议的特点，然后才能明白为什么很多防火墙管理员对 RPC 很头疼？为什么 RPC 数据包需要封装成 HTTP 格式？   RPC 是远端过程调用的缩写， RPC 协议特点很鲜明。普通的基于 Winsock 的网络服务大多有自己的固定端口，比如 FTP 守护 21 ， HTTP 守护 80 ，但基于 RPC 实现的服务却可以守护随机端口。随机端口？！有没有搞错！客户端程序怎么知道每次随机产生的监听端口是多少？客户端该如何连接服务器呢。为了解决这些问题， RPC 设计成这样的工作方式。首先，每个基于 RPC 的服务都有一个 UUID ， UUID 是一组 128 位长的数字，被用来区分 RPC 服务。 UUID 的定义是国际标准，跨操作系统。例如 Exchange 信息存储服务的 UUID 是 A 4F 1DB00-CA47-B 31F -00DD010662DA 。每次这些基于 RPC 的服务启动时都会选择一个高端端口进行监听，这个端口可以是随机的，然后这些服务会把自己的 UUID 以及自己这次监听的端口存储在终点映射器（ End Point Mapper 简称 EPM ）的一个表中 ， EPM 是专门为 RPC 设计的一个服务，端口是 135 ， EPM 记录了本机有多少个基于 RPC 的服务以及这些服务监听的高端端口各是多少。 现在假设有一个客户机要访问服务器上的 Exchange 信息存储服务，客户机首先要连接服务器的 135 端口，向 EPM 发起一个查询请求，查询请求中描述了自己所请求服务的 UUID ，此例应是 A 4F 1DB00-CA47-B 31F -00DD010662DA ，然后请 EPM 告知这个服务对应的端口是多少。 EPM 查询后告诉客户机，你所请求的这个服务在 6001 端口监听。客户机接到这个答案后，接下来就会去连接 6001 端口，和 Exchange 信息存储服务胜利会师了！ 听了上面的描述，大家就明白了为什么很多防火墙管理员对 RPC 很头疼，就因为 RPC 的动态端口！普通防火墙工作在网络层，传输层的居多，基本上只开放几个固定端口，用来保障网络安全。但如果防火墙后面有 RPC 服务，就麻烦了，为了保证 RPC 服务能被顺利访问，管理员有可能要被迫开放 1024 以上的所有高端端口！但如果开放得这么多，那防火墙也就成筛子了 ….. 所以这个问题直到应用层防火墙问世以后才得以较好解决，例如 ISA 就作得不错，以后我们会给大家介绍，这里就不多说了。 电信部门对 RPC 服务也比较敏感，前两年的冲击波，震荡波等病毒，就是利用了 RPC 的一些漏洞在互联网上大肆传播，危害巨大。电信部门闻风丧胆，唯恐避之不及，干脆采用一刀切的手段，有些运营商把访问 135 端口的数据包直接丢弃，来它个难言之隐，一丢了之。这下运营商省事了，工程师们费事了。所有有时候 Exchange 服务器在内网用 RPC 访问很正常，一放到公网用 RPC 访问就很容易出问题。罪魁祸首其实是后台的运营商，所以工程师们为了应付电信的封锁，想出了给 RPC 包化化妆，封装给 HTTP 包这样的主意。这也是为什么今天我们要尝试用 RPC/RPC Over HTTPS 来访问邮箱的原因。   介绍一下今天的实验环境，如下图所示，由三台虚拟机构成， Florence 是 exchtest.com 的域控制器， CA 服务器， Berlin 是 Exchange ＋ SP2 ， Istanbul 是域内的工作站，安装了 Outlook2003 ，用来作访问邮箱的客户机。三台计算机的操作系统都安装了 Win2003 中文企业版， DNS 服务器是我的物理主机 192.168.2.24 。     一   Outlook 通过 RPC 访问 Exchange 邮箱   这个操作很 easy ，只要在客户机上为 Outlook 创建一个正确的配置文件并注意权限问题就可以了，以访问管理员邮箱为例，具体如下 A   在 Isatnbul 上以 exchtest\administrator 登录，保证登录用户有访问邮箱的权限   B  为 Outlook 创建配置文件，启动 Outlook ，弹出 Outlook 配置向导，点击下一步   Outlook 询问是否将 Outlook Express 的邮件账号升级过来，选择“不升级”，下一步   Outlook 询问是否要配置一个邮箱账号，当然选“是“，下一步   Outlook 询问后台邮件服务器的类型，选择“ Microsoft Exchange Server ”，下一步        接下来我们填写了 Exchange 服务器的完全合格域名 berlin.exchtest.com ，要访问的邮箱是 administrator ，不使用缓存 Exchange 模式，完成配置后登录进入 administrator 的邮箱。   我们如何得知 Outlook 的连接状态呢？ Outlook 和 Exchange 服务器是用 RPC 连接还是 RPC Over HTTPS 呢，这个问题很简单。按住 Ctrl 键，右键单击屏幕右下角的 Outlook 图标，如下图所示，选择“连接状态” 看看连接状态到底是什么样，如下图所示，现在 Outlook 和 exchange 服务器是靠 RPC 连接的。   提示：如果 Outlook 的配置文件有误，导致无法进入邮箱，可利用控制面板－邮件－显示配置文件，删除当前的配置文件。然后重新启动 Outlook ， Outlook 会提示你创建新的配置文件。   二   Outlook 通过 RPC Over  HTTPS 访问邮箱 这种邮箱访问方式意味着要将 Outlook 发出的 RPC 数据包封装成 HTTP 格式，然后用 SSL 进行加密，服务器收到加密数据后，先对数据进行解密，再将 HTTP 包还原成 RPC 格式。要达到这个目标，需要以下步骤： A  Exchange 服务器安装“ HTTP 代理上的 RPC ” B  对“ HTTP 代理上的 RPC 进行配置” C  创建 CA 服务器 D  Exchange 服务器申请证书 E  配置 IIS 的身份验证方式 F  配置客户机上的 Outlook   我们从第一步开始 A  Exchange 服务器安装“ HTTP 代理上的 RPC ” 这是最基本的一步，目的是让 Exchange 服务器有能力对封装在 HTTP 包内的 RPC 数据包进行解封装，将其还原为 RPC 数据包。我们在 Exchange 服务器上，打开控制面板－添加或删除程序－添加 / 删除 Windows 组件，找到网络服务组件，点击详细信息，选择安装“ HTTP 代理上的 RPC ”，如下图所示   安装了“ HTTP 代理上的 RPC ”后，在 IIS 的默认 web 站点中多出一个虚拟目录 RPC ，如下图所示， RPC 虚拟目录中有一个 Rpcproxy.dll 的动态链接库。客户机将 RPC 包封装为 HTTP 格式，然后加密后发送到服务器的 RPC 虚拟目录下（这个虚拟目录的名称是约定好的，不能改变），对 HTTP 包进行解封装的工作主要 Rpcproxy.dll 来完成。   B  对“ HTTP 代理上的 RPC ” 进行配置 “ HTTP 代理上的 RPC ”需要进行什么配置呢，主要是 RPC 端口。“ HTTP 代理上的 RPC ”可以将封装在 HTTP 包内的 RPC 数据解封装出来，但对 HTTP 包内的 RPC 数据包有端口限制，默认情况下，只允许 RPC 数据包的端口范围在 100-5000 。那 Exchange 服务器使用的 RPC 服务端口在不在这个范围内呢？很遗憾，不在。 Exchange 服务器使用的 RPC 服务使用的常用端口有 6001 ， 6002 ， 6004 等，都超出了 100-5000 的范围，所以我们要对“ HTTP 代理上的 RPC ”进行配置，让它将 RPC 端口扩大一些，在本例中，我们将其更改为 100-7000 。 我们可以通过注册表，也可以通过 win2003 Resource  kit 中的 Rpccfg.exe 进行修改，我们演示一下如何用注册表进行修改，在 Exchange 服务器上运行 Regedit.exe ，定位到 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy\ValidPorts] ，如下图所示：将键值从原来的 BERLIN ： 100-5000 修改为 BERLIN.EXCHTEST.COM ： 100-7000 。 100-7000 大家都理解了，计算机名为什么也要修改呢，这个参数取决于客户机访问服务器时用哪种方式描述服务器，是用 NETBIOS 名称例如 [url]HTTP://Berlin[/url] ，还是完全合格域名例如 [url]HTTP://Berlin.Exchtest.com[/url] ，再或者干脆用 IP 地址。考虑到访问者有可能来源于广域网上，我们决定用完全合格域名来表示。 提醒一下，一旦决定客户机访问服务器是用完全合格域名的方式，那接下来 Exchange 服务器申请证书时，证书名称也要用完全合格域名。   顺便介绍一下，我们怎么知道自己机器上的 RPC 服务使用了哪些端口呢？微软的 Resource Kit 工具集中提供了一个 Rpcdump.exe 的工具，我们把它拷贝到 Exchange 服务器上，执行 Rpcdump /v /i ，在输出的结果中可以看到本机注册的 RPC 服务的 UUID 以及端口号，如下图所示：   C  创建 CA 服务器 RPC Over HTTPS 意味着 RPC 包被封装成 HTTP 格式后，还要利用 SSL 进行加密处理，这样就需要 web 服务器提供证书， web 服务器的证书从何而来？ CA 服务器，所以我们需要在域内部署 CA 服务器。在我们的实验环境中，我们使用 Florence 承担这个角色，在 Florence 上，先确认 IIS 组件已经安装，然后打开控制面板－添加或删除程序－添加 / 删除 Windows 组件，勾选“证书服务”， Windows 弹出窗口警告一旦安装证书服务，计算机名以及计算机角色都不能再进行更改。如下图所示： 接下来选择 CA 服务器类型，由于我们部署的是域中的第一台证书服务器，因此选择了“企业根”类型，由于和 Active Directory 的集成，企业根比独立根更方便。     接下来输入 CA 的公用名称，在此我们输入 ITETCA ，下一步后需要配置证书数据库的路径，使用默认设置，完成 CA 服务器的安装。 注意： CA 服务器安装完成后， Berlin 和 Istanbul 最好使用 Gpupdate/force 来刷新一下组策略，确保 Florence 已经成为了被信任的证书颁发机构。   D  Exchange 服务器申请证书 域内有了 CA 服务器， Exchange 服务器就可以申请证书了，打开管理工具中的 Internet 信息服务（ IIS ）管理器，右键点击默认网站，选择属性－目录安全性，如下图所示。点击服务器证书     选择新建证书，准备进行证书申请 选择“立即将证书请求发送到联机证书颁发机构”，这是创建企业根 CA 的好处，在线申请很方便     输入证书名称以及密钥长度，使用默认设置就可以了 单位及部门信息也不重要，描述性的，随意填写     证书公用名称，这是关键，要用完全合格域名，和刚才修改注册表时所规定的计算机名要保持一致，客户机访问 Exchange 服务器时也要使用这个计算机名。如果客户机访问服务器使用的格式是 [url]Https://berlin[/url] ，客户机会被提示证书的名称和访问的站点不一致。 接下来填写证书中的地理信息参数， SSL 端口（用默认值 443 ，不要改），选择证书颁发机构，完成申请后默认网站会立即收到颁发的证书。查看一下证书，如下图所示。至此， Exchange 服务器证书申请完成。   E  配置 IIS 的身份验证方式 接下来选择 IIS 的身份验证方式，客户机的 Outlook 把 RPC 封装成 HTTP 后，经过 SSL 加密后传到 Exchange 服务器默认网站的 RPC 虚拟目录，由于 Outlook 的访问目标是邮箱，因此 RPC 虚拟目录默认采用的匿名验证方式是肯定不行的。那我们选择哪种验证方式呢？建议最好选择“基本”验证方式，毕竟基本验证是工业标准，不用考虑兼容性问题。那有人要问了，基本验证是采用明文方式传输数据，就不怕安全性方面有问题吗？不用担心，基本验证不能保护数据安全，但 SSL 可以，别忘了 RPC 封装成 HTTP 后还要用 SSL 加密！ 打开管理工具－ Internet 信息服务（ IIS ）管理器－默认网站－ RPC －属性－目录安全性，如下图，在身份验证和访问控制上选择“编辑”   去掉“启用匿名访问”和“集成 Windows 验证”，勾选“基本身份验证，” 确定结束     F  配置客户机上的 Outlook 最后，我们应该来更改 Outlook 配置了，我们要让 Outlook 把 RPC 包封装成 HTTP 格式。在 Istanbul 上，打开控制面板－邮件－电子邮件账号，如下图所示，选择“查看或更改现有电子邮件账户”   这是我们刚刚在 Outlook 中创建的电子邮件账号，选择“更改” 不用更改现有的参数，选择“其他设置”     选择“连接”标签，勾选“使用 HTTP 连接到我的 Exchange 邮箱”，点击“ Exchange 代理服务器设置” Exchange 代理服务器处填写 Exchange 服务器的完全合格域名 berlin.exchtest.com ，这个名称和我们申请证书的公用名称以及配置 Exchange 服务器注册表时填写的 RPC 服务器名应该完全一样 。选择无论是在快速网络还是在低速网络， Outlook 都优先使用 HTTP 传送数据，如果不能使用 HTTP 进行传输再尝试使用 RPC 。身份验证方式从 NTLM 更改为基本身份验证，和 RPC 虚拟目录的验证方式一致。 更改完 Outlook 的设置后，启动 Outlook ，出现身份验证窗口，输入用户名和口令，登录进入邮箱 查看 Outlook 的连接状态，如下图所示，连接使用的是 HTTPS ，实验成功！ 本文出自 “ 岳雷的微软网络课堂” 博客，请务必保留此出处 [url]http://yuelei.blog.51cto.com/202879/75398[/url] 本文出自 51CTO.COM技术博客