轉載自：http://yuelei.blog.51cto.com/202879/75398
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。
一 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，實驗成功！
