轉載自：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，實驗成功！

轉載於:https://blog.51cto.com/microbear/306750