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

 

 

我们在前面的文章中已经介绍了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是A4F1DB00-CA47-B31F-00DD010662DA。每次这些基于RPC的服务启动时都会选择一个高端端口进行监听，这个端口可以是随机的，然后这些服务会把自己的UUID以及自己这次监听的端口存储在终点映射器（End Point Mapper 简称EPM）的一个表中 ，EPM是专门为RPC设计的一个服务，端口是135，EPM记录了本机有多少个基于RPC的服务以及这些服务监听的高端端口各是多少。

现在假设有一个客户机要访问服务器上的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。

一 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名称例如HTTP://Berlin，还是完全合格域名例如HTTP://Berlin.Exchtest.com，再或者干脆用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服务器时也要使用这个计算机名。如果客户机访问服务器使用的格式是 Https://berlin，客户机会被提示证书的名称和访问的站点不一致。

接下来填写证书中的地理信息参数，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，实验成功！