我们在前面的文章中已经介绍了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
4F1DB00-CA47-B
31F-00DD010662DA。每次这些基于RPC的服务启动时都会选择一个高端端口进行监听,这个端口可以是随机的,然后这些服务会把自己的UUID以及自己这次监听的端口存储在终点映射器(End Point Mapper 简称EPM)的一个表中 ,EPM是专门为RPC设计的一个服务,端口是135,EPM记录了本机有多少个基于RPC的服务以及这些服务监听的高端端口各是多少。现在假设有一个客户机要访问服务器上的Exchange信息存储服务,客户机首先要连接服务器的135端口,向EPM发起一个查询请求,查询请求中描述了自己所请求服务的UUID,此例应是A
4F1DB00-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,实验成功!