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
是
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
。
![](../attachment/200805/200805061210083264234.jpg)
一
Outlook
通过
RPC
访问
Exchange
邮箱
这个操作很
easy
,只要在客户机上为
Outlook
创建一个正确的配置文件并注意权限问题就可以了,以访问管理员邮箱为例,具体如下
A
在
Isatnbul
上以
exchtest\administrator
登录,保证登录用户有访问邮箱的权限
![](../attachment/200805/200805061210080405156.jpg)
B
为
Outlook
创建配置文件,启动
Outlook
,弹出
Outlook
配置向导,点击下一步
![](../attachment/200805/200805061210083587234.jpg)
Outlook
询问是否将
Outlook Express
的邮件账号升级过来,选择“不升级”,下一步
![](../attachment/200805/200805061210083600234.jpg)
Outlook
询问是否要配置一个邮箱账号,当然选“是“,下一步
![](../attachment/200805/200805061210083613968.jpg)
Outlook
询问后台邮件服务器的类型,选择“
Microsoft Exchange Server
”,下一步
![](../attachment/200805/200805061210083624171.jpg)
接下来我们填写了
Exchange
服务器的完全合格域名
berlin.exchtest.com
,要访问的邮箱是
administrator
,不使用缓存
Exchange
模式,完成配置后登录进入
administrator
的邮箱。
![](../attachment/200805/200805061210083636453.jpg)
![](../attachment/200805/200805061210080588234.jpg)
我们如何得知
Outlook
的连接状态呢?
Outlook
和
Exchange
服务器是用
RPC
连接还是
RPC Over HTTPS
呢,这个问题很简单。按住
Ctrl
键,右键单击屏幕右下角的
Outlook
图标,如下图所示,选择“连接状态”
![](../attachment/200805/200805061210080634578.jpg)
看看连接状态到底是什么样,如下图所示,现在
Outlook
和
exchange
服务器是靠
RPC
连接的。
![](../attachment/200805/200805061210083690203.jpg)
提示:如果
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
”,如下图所示
![](../attachment/200805/200805061210081074718.jpg)
安装了“
HTTP
代理上的
RPC
”后,在
IIS
的默认
web
站点中多出一个虚拟目录
RPC
,如下图所示,
RPC
虚拟目录中有一个
Rpcproxy.dll
的动态链接库。客户机将
RPC
包封装为
HTTP
格式,然后加密后发送到服务器的
RPC
虚拟目录下(这个虚拟目录的名称是约定好的,不能改变),对
HTTP
包进行解封装的工作主要
Rpcproxy.dll
来完成。
![](../attachment/200805/200805061210083745531.jpg)
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
服务器申请证书时,证书名称也要用完全合格域名。
![](../attachment/200805/200805061210081127718.jpg)
顺便介绍一下,我们怎么知道自己机器上的
RPC
服务使用了哪些端口呢?微软的
Resource Kit
工具集中提供了一个
Rpcdump.exe
的工具,我们把它拷贝到
Exchange
服务器上,执行
Rpcdump /v /i
,在输出的结果中可以看到本机注册的
RPC
服务的
UUID
以及端口号,如下图所示:
![](../attachment/200805/200805061210081216156.jpg)
![](../attachment/200805/200805061210081227671.jpg)
C
创建
CA
服务器
RPC Over HTTPS
意味着
RPC
包被封装成
HTTP
格式后,还要利用
SSL
进行加密处理,这样就需要
web
服务器提供证书,
web
服务器的证书从何而来?
CA
服务器,所以我们需要在域内部署
CA
服务器。在我们的实验环境中,我们使用
Florence
承担这个角色,在
Florence
上,先确认
IIS
组件已经安装,然后打开控制面板-添加或删除程序-添加
/
删除
Windows
组件,勾选“证书服务”,
Windows
弹出窗口警告一旦安装证书服务,计算机名以及计算机角色都不能再进行更改。如下图所示:
![](../attachment/200805/200805061210081240515.jpg)
接下来选择
CA
服务器类型,由于我们部署的是域中的第一台证书服务器,因此选择了“企业根”类型,由于和
Active Directory
的集成,企业根比独立根更方便。
![](../attachment/200805/200805061210081253140.jpg)
接下来输入
CA
的公用名称,在此我们输入
ITETCA
,下一步后需要配置证书数据库的路径,使用默认设置,完成
CA
服务器的安装。
![](../attachment/200805/200805061210081269140.jpg)
![](../attachment/200805/200805061210081281468.jpg)
注意:
CA
服务器安装完成后,
Berlin
和
Istanbul
最好使用
Gpupdate/force
来刷新一下组策略,确保
Florence
已经成为了被信任的证书颁发机构。
![](../attachment/200805/200805061210081296406.jpg)
![](../attachment/200805/200805061210081308796.jpg)
D Exchange
服务器申请证书
域内有了
CA
服务器,
Exchange
服务器就可以申请证书了,打开管理工具中的
Internet
信息服务(
IIS
)管理器,右键点击默认网站,选择属性-目录安全性,如下图所示。点击服务器证书
![](../attachment/200805/200805061210081322828.jpg)
![](../attachment/200805/200805061210081336531.jpg)
选择新建证书,准备进行证书申请
![](../attachment/200805/200805061210081362609.jpg)
选择“立即将证书请求发送到联机证书颁发机构”,这是创建企业根
CA
的好处,在线申请很方便
![](../attachment/200805/200805061210081377828.jpg)
输入证书名称以及密钥长度,使用默认设置就可以了
![](../attachment/200805/200805061210081388937.jpg)
单位及部门信息也不重要,描述性的,随意填写
![](../attachment/200805/200805061210081403875.jpg)
证书公用名称,这是关键,要用完全合格域名,和刚才修改注册表时所规定的计算机名要保持一致,客户机访问
Exchange
服务器时也要使用这个计算机名。如果客户机访问服务器使用的格式是
[url]Https://berlin[/url]
,客户机会被提示证书的名称和访问的站点不一致。
![](../attachment/200805/200805061210081417015.jpg)
接下来填写证书中的地理信息参数,
SSL
端口(用默认值
443
,不要改),选择证书颁发机构,完成申请后默认网站会立即收到颁发的证书。查看一下证书,如下图所示。至此,
Exchange
服务器证书申请完成。
![](../attachment/200805/200805061210081450359.jpg)
E
配置
IIS
的身份验证方式
接下来选择
IIS
的身份验证方式,客户机的
Outlook
把
RPC
封装成
HTTP
后,经过
SSL
加密后传到
Exchange
服务器默认网站的
RPC
虚拟目录,由于
Outlook
的访问目标是邮箱,因此
RPC
虚拟目录默认采用的匿名验证方式是肯定不行的。那我们选择哪种验证方式呢?建议最好选择“基本”验证方式,毕竟基本验证是工业标准,不用考虑兼容性问题。那有人要问了,基本验证是采用明文方式传输数据,就不怕安全性方面有问题吗?不用担心,基本验证不能保护数据安全,但
SSL
可以,别忘了
RPC
封装成
HTTP
后还要用
SSL
加密!
打开管理工具-
Internet
信息服务(
IIS
)管理器-默认网站-
RPC
-属性-目录安全性,如下图,在身份验证和访问控制上选择“编辑”
![](../attachment/200805/200805061210083831390.jpg)
去掉“启用匿名访问”和“集成
Windows
验证”,勾选“基本身份验证,”
确定结束
![](../attachment/200805/200805061210082795906.jpg)
F
配置客户机上的
Outlook
最后,我们应该来更改
Outlook
配置了,我们要让
Outlook
把
RPC
包封装成
HTTP
格式。在
Istanbul
上,打开控制面板-邮件-电子邮件账号,如下图所示,选择“查看或更改现有电子邮件账户”
![](../attachment/200805/200805061210083880140.jpg)
这是我们刚刚在
Outlook
中创建的电子邮件账号,选择“更改”
![](../attachment/200805/200805061210083952781.jpg)
不用更改现有的参数,选择“其他设置”
![](../attachment/200805/200805061210083967359.jpg)
选择“连接”标签,勾选“使用
HTTP
连接到我的
Exchange
邮箱”,点击“
Exchange
代理服务器设置”
![](../attachment/200805/200805061210082861046.jpg)
Exchange
代理服务器处填写
Exchange
服务器的完全合格域名
berlin.exchtest.com
,这个名称和我们申请证书的公用名称以及配置
Exchange
服务器注册表时填写的
RPC
服务器名应该完全一样
。选择无论是在快速网络还是在低速网络,
Outlook
都优先使用
HTTP
传送数据,如果不能使用
HTTP
进行传输再尝试使用
RPC
。身份验证方式从
NTLM
更改为基本身份验证,和
RPC
虚拟目录的验证方式一致。
![](../attachment/200805/200805061210082882031.jpg)
更改完
Outlook
的设置后,启动
Outlook
,出现身份验证窗口,输入用户名和口令,登录进入邮箱
![](../attachment/200805/200805061210082894250.jpg)
![](../attachment/200805/200805061210082904906.jpg)
查看
Outlook
的连接状态,如下图所示,连接使用的是
HTTPS
,实验成功!
![](../attachment/200805/200805061210084013187.jpg)