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
，实验成功！
'
本文转自yuelei51CTO博客，原文链接：http://blog.51cto.com/yuelei/75398 ，如需转载请自行联系原作者
