RPC over HTTP 驗證和安全性
上次修改主題的時間： 2005-05-18
使用 RPC over HTTP 之驗證及安全性的優點如下所示：
- 除了您已經允許的 Microsoft® Office Outlook® Web Access、Microsoft Exchange ActiveSync® 或 Outlook Mobile Access 網際網路連接埠外，無須允許其他連接埠。
- 您必須使用安全通訊端層 (SSL)。
- Outlook 必須傳送已驗證的要求。
- RPC Proxy 伺服器與 Exchange 伺服器會驗證使用 RPC over HTTP 的 Outlook 要求。
- 您不會公開端點對應程式。
- 用戶端電腦只能存取指定的 Exchange 伺服器上的指定 Exchange 服務。
HTTP 驗證
RPC Proxy 伺服器上的網際網路資訊服務 (IIS) 控制 HTTP 工作階段驗證。當您設定 RPC Proxy 伺服器時，您必須設定 RPC 虛擬目錄使用基本驗證、NTLM 驗證，或是兩種驗證同時使用。Outlook 可以在 HTTP 工作階段傳送基本驗證或 NTLM 驗證，視您如何設定 Outlook 設定檔而定。RPC Proxy 伺服器網際網路伺服器 API (ISAPI) 不接受匿名驗證的連線。
.gif "note") 附註： |
|---|
| 當您使用 Exchange Server 2003 Server Pack 1 (SP1) 中的 Exchange 系統管理員來設定 RPC over HTTP 時，Exchange 系統管理員會自動為您設定 RPC 虛擬目錄上的驗證設定。 |
| 附註： |
|---|
| NTLM 驗證也稱為整合式 Windows 驗證。 |
您在 Outlook 設定檔上設定的驗證機制只用於傳送至 RPC Proxy 伺服器的 HTTP 工作階段。當 Outlook 利用 RPC over HTTP 存取 Exchange 伺服器時，Outlook 與 Exchange 伺服器之間的驗證機制都是使用 NTLM。強烈建議您對傳送至 RPC Proxy 伺服器的 HTTP 工作階段使用 SSL 加密，特別是當您對 HTTP 工作階段使用基本驗證時。若您使用 SSL 加密，可防止您的使用者名稱與密碼以純文字傳送。Outlook 不允許您在未使用 SSL 加密連線至 RPC Proxy 伺服器時，使用基本驗證。
如果您的防火牆會檢查並以任何方式修改 HTTP 流量，那您可能必須使用基本驗證，而非 NTLM 驗證。如果 RPC Proxy 伺服器不信任驗證資訊，NTLM 驗證將會失敗。例如，您的防火牆可能會終止來自網際網路的工作階段，並建立傳送至 RPC Proxy 伺服器的新工作階段，而非傳送未修改的 HTTPS (SSL) 工作階段至 Exchange 伺服器。這個程序也稱為反向 Proxying 或是網頁發佈。特定防火牆，如 Microsoft Internet Security and Acceleration (ISA) Server 2004，可以成功地反向 Proxy 或網頁發佈工作階段，同時仍允許 NTLM 驗證順利進行。
| 附註： |
|---|
| ISA Server 2000 則無法在反向 Proxy 或網頁發佈工作階段時，仍允許 NTLM 驗證順利進行。 |
基本驗證不會受到反向 Proxy 或網頁發佈的影響，不論使用何種防火牆均可運作。然而，若您使用基本驗證，每次啟動 Outlook 工作階段時，都必須鍵入您的網域、使用者名稱與密碼。
基本驗證與 NTLM 驗證
下表說明基本驗證與 NTLM 驗證之間的部份差異。
| 基本驗證 | NTLM 驗證 |
|---|---|
用戶端電腦以純文字傳送使用者名稱及密碼。 當您使用基本驗證時，永遠都要使用 SSL。 Outlook 不允許您只選取基本驗證而不選取 SSL。 RPC Proxy 伺服器也需要 SSL。 |
用戶端電腦會傳送登入要求至伺服器。 伺服器會以隨機產生的權杖或挑戰，來回應用戶端電腦。 用戶端電腦會將目前登入的使用者編譯保護密碼及挑戰予以雜湊處理，並將所產生的回應傳送至伺服器。 伺服器接收到以挑戰雜湊處理的回應之後，會和其所知的正確回應加以比較 (伺服器會將取得的一份原始權杖，對從本身使用者帳戶資料庫中取出的使用者密碼雜湊，進行雜湊處理)。 如果收到的回應符合預期的回應，使用者便會成功通過主機驗證。 |
基本驗證適用於反向 Proxy 防火牆。 |
NTLM 驗證可能不適用於部份反向 Proxy 防火牆。 如果防火牆檢查流量並加以修改，NTLM 驗證可能會失效。 |
基本驗證需要使用者輸入網域、使用者名稱及密碼。 |
NTLM 可以使用目前的 Microsoft Windows® 作業系統登入資訊。 |
RPC over HTTP 使用目前 Windows 作業系統登入資訊的需求
RPC over HTTP 如要使用目前的 Windows 作業系統登入資訊，必須符合以下需求：
- 使用者以正確的網域認證登入用戶端電腦。
- 使用者在 Outlook 設定檔中選擇 NTLM 驗證。
- 防火牆允許 NTLM 驗證。如果防火牆僅在沒有修改 (連接埠過濾) 的情況下，將 SSL 工作階段傳遞至 Exchange 伺服器，或者防火牆是進階防火牆 (如 ISA Server 2004)，則有可能發生此一情形。ISA Server 2004 能在反向 Proxy 網頁發佈 Exchange 伺服器時，仍允許 NTLM 驗證順利進行。
- 使用者自動與連線一併傳送 NTLM 驗證資訊。如果下列條件之一為真，則可能發生此一情形：
- 您將 Outlook 設定為透過 SSL 執行相互驗證。這是建議的方法。
- 用戶端電腦的 LmCompatibilityLevel 設定為 2 或 3。
如需有關設定 LmCompatibilityLevel 的詳細資訊，請參閱 Microsoft 知識庫文件 820281＜You must provide Windows account credentials when you connect to Exchange Server 2003 by using the Outlook 2003 RPC over HTTP feature＞(當您利用 Outlook 2003 RPC over HTTP 功能連線至 Exchange Server 2003 時，必須提供 Windows 帳戶憑證)(https://go.microsoft.com/fwlink/?linkid=3052&kbid=820281)。
RPC 驗證
RPC 要求 Exchange 伺服器驗證永遠使用 NTLM 驗證。
SSL
用戶端電腦必須信任用於 SSL 的憑證。如要讓用戶端電腦信任用於 SSL 的憑證，下列條件必須為真：
- 憑證名稱必須符合正在存取的網站。
- 憑證尚未過期。
- 用戶端電腦信任發行該憑證的憑證授權單位。
若您已順利設定 Outlook Web Access、Exchange ActiveSync 或其他 Web 服務來使用您的前端 Exchange 伺服器，則憑證會符合這些需求。
您可以利用 Microsoft Internet Explorer 找出 RPC 虛擬目錄的位置，以驗證憑證是否正確。如果憑證無效，Internet Explorer 會發出警告。
SSL 卸載
當 RPC Proxy 伺服器之前的防火牆結束 SSL 工作階段，並建立新的非 SSL 工作階段至前端伺服器時，就會發生 SSL 卸載的情形。應特別考量的是，它並不會建立新的 SSL 工作階段。
若您使用 SSL 卸載，您必須設定登錄機碼，讓 RPC Proxy 伺服器知道它可以接受非 SSL 工作階段。如需如何設定此登錄機碼的詳細資訊，請參閱＜如何設定 RPC Proxy 伺服器以便在不同的伺服器進行 SSL 卸載＞。