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

核心提示： 现在假设有一个客户机要访问服务器上的Exchange信息存储服务，客户机首先要连接服务器的135端口，Outlook通过RPC或RPC over HTTPS访问Exchane邮箱:Exchange2003系列之四(2)，向EPM发起一个查询请求，查询请求中描述了自己所请求服务的UUID，用来作访

现在假设有一个客户机要访问服务器上的Exchange信息存储服务，客户机首先要连接服务器的135端口，向EPM发起一个查询请求，查询请求中描述了自己所请求服务的UUID，此例应是A4F1DB00-CA47-B31F-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。