通訊
使用智慧卡登入 Outlook Web Access
Victor Akinnagbe and Ted Dressel and Jason Opdycke
摘要:
- 雙重關卡驗證
- Kerberos 限制委派
- ISA Server 和 Exchange 的組態
行動員工為 IT 組織帶來更特殊的安全性挑戰。遠端使用者需要針對類似電子郵件等資料和服務，進行安全的存取。但不幸的是，在現實中，
安全性鏈結最脆弱的環節，涉及在存取貴組織內部資源的遠端電腦上，有容易破解的密碼、惡意程式 (例如按鍵記錄程式)，以及病毒。
在這種行動環境下增加安全性的方式之一，是移除其中最脆弱的一環：密碼 (不過允許無密碼驗證即存取帳戶的方式確實有些令人困擾)。要解決密碼相關問題的主要技巧，是採用名為雙重關卡驗證的方法 (或者有時候為多重關卡驗證)。雙重關卡驗證並非仰賴「密碼」這個單一方法來存取，而是採取其他驗證方法，包括使用者名稱/密碼組合、實體裝置 (如智慧卡)，或是人體辨識法 (如指紋)。
若您有遠端使用者，一般而言就必須開放防火牆，以允許由遠端存取企業網路。標準防火牆可藉由隔離網路層級的內、外網路，讓您略為降低風險 (請參閱 [圖 1])。如需更高的安全性，則可以直接關閉通訊埠。如果內部網路的裝置需要進行通訊，則會將通訊埠轉送到正確的位置。這些技巧的確可提供實質的網路層級保護，但現在的攻擊愈來愈複雜，因此需要多重層級的網路安全性。
圖 1** 標準防火牆的通訊埠受阻擋或轉送 **(按影像可放大)
由於行動員工最常用的企業服務，通常是電子郵件和訊息服務，因此 Exchange 基礎架構的安全設定，就成為非常重要的課題。讓使用者透過 Outlook® Web Access (OWA) 存取電子郵件，是為行動員工提供安全服務的一種方式。透過智慧卡為 OWA 提供更安全的雙重關卡驗證，則是另一項要素。我們將在本文中深入探討您啟用個人的智慧卡式 OWA 部署時，需要注意哪些組態與安裝相關事項。
比防火牆更好用
在網路上部署 Microsoft® Internet Security and Acceleration (ISA) Server 2006，可以用更安全的方式，簡化為遠端使用者開放網路的作業。ISA Server 2006 包括強化安全性功能，如智慧卡式虛擬私人網路 (VPN)、Active Directory® 的 Lightweight Directory Access Protocol (LDAP) 驗證，以及 Kerberos 限制委派。ISA Server 與您傳統印象中的防火牆不太一樣。它提供的多重安全層級不僅在網路層級運作 (可以取代或搭配標準防火牆硬體使用)，還能提供傳統防火牆通常無法支援的額外安全性功能，例如應用程式篩選器。不想讓其他人使用 HTTP POST 方法進入特定主控網站嗎？想要先強制 RFC 與 SMTP 訊息相容，才能接觸您的 Exchange 伺服器嗎?希望先檢查加密的 Secure Sockets Layer (SSL) HTTP 封包，再放到網路上？ISA Server 可管理上述所有工作，並且確保只有乾淨、篩選過的流量，才能轉送到您的 DMZ 或內部網路。
SSL 工作階段對於標準防火牆而言是一大問題。當封包經由防火牆傳送時，仍維持加密狀態 (也就表示 SSL 運作正常)。因此，若像 OWA 這樣的應用程式使用 SSL 穿過硬體或軟體防火牆發行，實際上標準防火牆除了可以設定狀況的封包檢查外，就無法執行任何有意義的檢查。直接開啟和轉送通訊埠，可能會暴露出可受攻擊的面。既然在邊緣無法真正進行檢查，未檢查和未驗證的封包就可能會傳送到您的內部網路。
ISA Server 2006 可做為 HTTP 用戶端的 SSL 結束點，確保只有經過驗證的流量，才能送達發佈的 Exchange server。ISA Server 支援名為 SSL 橋接的功能。一般而言，封包是由用戶端加密，而該用戶端是經由標準 SSL 工作階段與 SIA Server 進行通訊。有了 SSL 橋接，ISA Server 可於本機終止 SSL 加密、檢查目前未加密的封包、驗證 Active Directory 使用者 (若有必要)、使用 SSL 重新加密封包，以及將加密封包傳送到適當的 Exchange server (請參閱 [圖 2])。利用這項技巧，SSL 橋接可減少隱身在 SSL 工作階段中的攻擊，因為這些攻擊對於無法感知應用程式的防火牆而言，只是已加密的資料 Blob。
圖 2** ISA Server 採取應用程式層級檢視流量 **(按影像可放大)
討論 Kerberos 限制委派時，就免不了要談到送達伺服器的預先驗證流量。在標準防火牆中，僅會將通訊埠轉送至 Exchange Server，前端伺服器本身需要負責針對可能為惡意的使用者，執行驗證工作。需要驗證時，ISA Server 可以直接連絡 Active Directory，並以使用者的身分提出認證要求。若使用者成功通過驗證，ISA Server 會將訊息轉寄到 Exchange 前端伺服器。前端伺服器不再需要隨機驗證不明使用者要求，同時可以專門用於後端伺服器連線要求的 Proxy。ISA Server 2006 亦可使用 Kerberos 限制委派，以啟用認證方式來存取如 Windows SharePoint Service 和 Exchange ActiveSync 等技術。
Exchange Server 2003 包括 OWA 登入的前端與後端伺服器之間的 Kerberos 驗證支援 (您正在使用 IPsec 來保護該用戶端流量，不是嗎？)Exchange Server 亦支援叢集郵件信箱伺服器的 Kerberos 驗證。
啟用智慧卡驗證
為 OWA 執行智慧卡式驗證，曾經是個難題。然而，目前在 ISA Server 2006 上，已經針對 Kerberos 限制委派功能發展出解決方案。這個解決方案可允許使用者透過認證來提交憑證，以便成功為 OWA 驗證。Kerberos 限制委派在使用不限制委派的 Windows® 2000 中，扮演改善 Kerberos 委派支援的角色。Kerberos 的限制功能較為安全，並可限制使用模擬進行複雜攻擊的潛在風險。
在使用智慧卡的情況下，ISA Server 2006 會連絡 Active Directory 來驗證使用者，因為使用者無法從外部網路進行 Key Distribution Center (KDC) 的路由式存取。ISA Server 會依照 Active Directory 的認證與使用者對應，來驗證使用者，接著根據使用者主要名稱 (UPN) 取得其 Kerberos 票證。在這種情況下，ISA Server 是經由應用程式層級的篩選和反向 Proxy 服務，為 Exchange 前端伺服器提供 Kerberos 限制委派功能。若嘗試在沒有反向 Proxy 的情況下進行委派，遭入侵的風險會影響網路或 Active Directory 網域的完整性。
Exchange Server 2003 和 Exchange Server 2007 都允許基本與整合式驗證。但是您需要為 Exchange Server 2003 套用軟體更新，OWA 的智慧卡驗證才能運作 (如需詳細資訊，請參閱文件 "在 Exchange Server 2003 中，支援新的 Outlook Web Access 智慧卡驗證功能的說明")。您在 Windows Server® 2003 原生功能模式中必須備有網域，所有相關 Exchange Server 2003 伺服器都必須套用 SP2 或以上的版本，且必須將 ISA Server 2006 伺服器當做 OWA 站台的反向 Proxy。
安裝軟體更新，並且設定 ISA 及 Exchange server 之後，使用者即可使用智慧卡驗證 OWA 工作階段。[圖 3] 顯示智慧卡驗證所需的事件流程。一開始，使用者要先在 Internet Explorer® 中開啟 OWA 站台 (1)。事實上，使用者會連接到 ISA Server，其中會出現提示要求提供認證，而非使用者名稱和密碼，才能啟動 OWA 工作階段。適當的認證儲存在智慧卡中，而使用者必須有 PIN 才能使用。
圖 3** 使用智慧卡驗證 OWA **(按影像可放大)
憑證確認 (2) 是經由憑證撤銷清單 (CRL) 或者線上憑證狀態通訊協定 (OCSP) 要求處理，並依據 ISA Server 及其他已安裝軟體的組態為主。ISA Server 會要求網域控制站 (DC) 確認使用者的身分。若要求失敗，ISA Server 會向使用者顯示錯誤訊息頁面，同時不會將任何要求傳送到 Exchange 前端伺服器。
認證的驗證工作完成後，即會產生 Kerberos 票證，並且會使用整合式驗證 (3) 將要求傳送到 Exchange 前端伺服器。Exchange 前端伺服器接收到要求時，會確認 Kerberos 票證並找出使用者的後端電子郵件伺服器 (4)。
前端伺服器會透過 Kerberos 限制委派，為適當的後端伺服器要求 Kerberos 票證，然後使用整合式驗證 (5)，將郵件信箱要求連線 Proxy 到後端伺服器。該要求將由後端伺服器 (6) 服務，然後再把郵件信箱資料傳回 Exchange 前端伺服器 (7)。OWA 頁面的 HTML 資料會傳遞到 ISA Server (8)，接著再傳遞回用戶端電腦 (9)。
設定 Exchange 環境
先前所提到的知識庫文件中，描述了 Exchange Server 2003 的軟體更新，並且包括各種資訊，可利用 ISA Server 2006 和 Exchange Server 2003 協助您逐步完成 Kerberos 限制委派啟用程序。
軟體更新可發揮的主要動作，是將 Kerberos 限制委派的程序自動化，從 Exchange 前端伺服器自動送到對應的後端伺服器。更新並不會將 Kerberos 限制委派從 ISA Server 到前端伺服器的程序自動化，因為 ISA Server 並非 Exchange 組織的一部分。該委派必須以手動方式啟用，從各個 ISA Server 執行個體到每個 Exchange 前端伺服器。
軟體更新會在 Exchange System Manager (ESM) 中加入新的索引標籤，讓您可以將某 Exchange 前端伺服器指定為 KCD-FE (請參閱 [圖 4])，因而允許該伺服器顯示在其對應 Exchange 後端伺服器的委派索引標籤中。
圖 4** 啟用 Kerberos 限制委派 **
新的 UI 亦可讓您在管理群組的屬性中，指定要將哪些認證顯示於 msDS-AllowedToDelegateTo (A2D2) 屬性中，如 [圖 5] 所示。這是負責 Kerberos 限制委派的屬性。
圖 5** 設定控制委派的帳戶 **
為了達到最少權限的限制原則，您可以使用標準使用者帳戶，並核准其經由群組原則物件 (GPO) 委派使用者和電腦。該帳戶獲得此更高的權限之後，即可視為服務帳戶，以自動化其對應之管理群組的 Kerberos 限制委派程序。
請確認您採取正確的步驟，以確保惡意使用者不會危害到 Kerberos 限制委派服務帳戶。即使該帳戶並非網域管理員，存取時仍可能利用 Kerberos 委派，導致複雜的攻擊。由於該帳戶有能力建立新的 Kerberos 關聯，因此應小心使用。採取必要的預防措施，以確保帳戶的安全性和完整性：使用長而複雜的密碼、增加稽核動作、帳戶停用技巧等。
Exchange 軟體更新亦對於 ESM 介面有極重要的整合性驗證相關變更。過去在 Exchange Server 2003 版本中，伺服器委派為前端伺服器時，啟用 HTTP 虛擬目錄中整合 Windows 驗證的選項 (位於 HTTP 虛擬伺服器項目下)，是無法使用的灰色 (請參閱 [圖 6])。
圖 6a** 更新啟用了整合式驗證 **
圖 6b** 更新啟用了整合式驗證 **
這是由於 Exchange 前端伺服器因技術問題而不支援整合式驗證，其中的問題包括如 Proxy 伺服器中斷了 NTLM 工作階段、使用者部署 Kerberos 驗證時需要連接到 Active Directory，以及網際網路使用者通常不屬於該網域。在前述知識庫文件中描述的更新，去除了這些限制。安裝更新之後，即可輕鬆到虛擬目錄中核取 Windows 整合式驗證的方塊，以做為確認使用者身分的機制。核取此項目後，會在 Active Directory 的虛擬目錄物件上，設定名為 msexchAuthenticationFlags 的屬性 (只要在 Microsoft Management Console 使用 Adsiedit.msc 嵌入式管理單元，就可以看到)。
透過 OWA 檢查郵件的使用者或許知道其 Exchange 後端伺服器的名稱，並可於企業內部網路中，利用整合式驗證來進行連結。使用者在使用整合式驗證的不同之處，在於只要登入網路，就不會再提示您輸入使用者名稱和密碼，因為 Internet Explorer 會自動驗證讓您進入網站。這點對於企業網路內部的使用者十分好用，但對於外部使用者 (而且 OWA 使用者大多屬於外部使用者) 而言，通常會從網路外部進入 Exchange 前端伺服器，所以通常不會登入網域中 (此程序在知識庫文件 "IIS 如何驗證瀏覽器用戶端" 中有詳細說明)。
在 Exchange Server 中，更新會產生 [委派] 索引標籤，並於 Active Directory 中使用 A2D2 屬性來取代服務主要名稱 (SPN) 屬性。若您使用 Adsiedit.msc 來查看 Exchange 電腦物件，應該會發現兩個完全不同的屬性：A2D2 屬性是 Kerberos 限制委派清單；而 SPN 屬性則是 Kerberos 定位程式和帳戶規格點。雖然同時使用兩種屬性，的確可以啟用 Kerberos 限制委派，但您只應透過圖形介面來修改 A2D2 屬性。
Windows 可以使用內建 HOST SPN，做為找出其他服務的別名。這表示 Kerberos 限制委派不一定需要使用 setspn.exe 就能完成 Exchange 前端到後端指派 (雖然明確指定 SPN 屬性清單中的 HTTP/Servername 適用此解決方案，但仍有太多的管理員錯誤空間，而且 Kerberos 限制委派不需要它們也能運作)。Kerberos 限制委派正在 Active Directory 中尋找 A2D2 屬性。未產生此屬性時 (或者產生時有錯誤的 SPN 值)，Kerberos 限制委派無法在對應的伺服器之間運作。不過在 Exchange 叢集上，來自前端伺服器的 A2D2 屬性僅需要指向叢集節點電腦帳戶，就能正常運作。
如先前所述，包含 Exchange 2003 伺服器的 Windows Server 2003 網域，必須採用 Windows Server 2003 原生功能模式。除非已經達到網域功能層級，否則 Kerberos 限制委派無法使用。若您的網域仍為混合模式，而且您已經安裝過先前討論的軟體更新，則會看似正常運作，但 SPN 註冊最後仍會失敗。Kerberos 限制委派也是網域功能，而非樹系層級功能。這表示對於 Exchange Server 2003、ISA Server 和 Exchange 前端和後端伺服器而言，必須是同網域的成員 (雖然來自不同網域的使用者仍可通過 Kerberos 限制委派驗證)。非網域成員或者是其他網或成員的 ISA Server 例項，無法在此解決方案中使用。
設定 OWA 站台
IIS Admin 不應該用來做任何的 OWA 驗證變更。雖然 OWA 在 IIS 下執行，且和其他網站一樣可以回應 Metabase 的變更，但 Exchange 的 Directory Services to Metabase (DS2MB) 處理程序較為複雜。DS2MB 處理程序會以單向程序從 Active Directory 複寫變更到 IIS Metabase，其中會直接複寫所有變更到 IIS。此處理程序的影響，是當系統管理員直接在 IIS Metabase 上執行變更時 (例如設定整合式驗證)，解決方案的運作會看似正常，但是只要下一個 DS2MB 複寫週期開始，就會立刻失敗。
為 HTTP 虛擬目錄啟用整合式 Windows 驗證的選項提供於 ESM 中，因為 ESM 可直接將編輯內容反應至 Active Directory，因而使得變更複寫到 IIS Metabase。請記住，雖然在停止 System Attendant 服務時也會停止 DS2MB 處理程序，這樣可以讓您變更 IIS Metabase 而不直接複寫，但是我們不建議這麼做。因為下次啟動 System Attendant 時，會從 Active Directory 中找出變更，而解決方案就會自動停用。
[委派] 索引標籤會顯示選項，讓您選擇 [只使用 Kerberos] 或者 [使用任何驗證通訊協定]。若以基本邏輯來判斷，應該都會選擇 [只使用 Kerberos]，因為我們所討論的解決方案使用的是 Kerberos 限制委派，但這是眾多 IT 案例中無法套用正常邏輯的個案之一。相反的，您應該選擇 [使用任何驗證通訊協定] 選項 (如 [圖 7] 所示)，因為傳入的要求並非 Kerberos 要求，而是有認證對應到 Active Directory 帳戶的 HTTP 要求。
圖 7** 適用於智慧卡的正確驗證設定 **
在此案例中，ISA Server 會要求使用者透過 SSL 提供 PKI 認證。傳入的要求並非 Kerberos 票證，所以必須進行轉換，才能讓 Kerberos 限制委派正確運作。因此，若設定為限使用 Kerberos，則會破壞 ISA Server 的通訊鏈結。不過要注意的是，限使用 Kerberos 選項可以用在 Exchange 前端到後端伺服器委派，因為前端伺服器只會從 ISA Server 接收到 Kerberos 票證。
\Exchange 和 \Public 虛擬目錄是唯一應包括私人使用者和公開資料夾資訊的位置。Exchange 的 SSL 組態對於 Kerberos 限制委派或雙重關卡驗證而言並不陌生，而是來自於標準 SSL 為啟用具基本驗證認證的 OWA 延用至今。您應該遵循記錄方法來啟用 OWA 的 SSL，因為以錯誤方式強制 SSL 會破壞 OWA，而且同時會導致 ESM 發生問題。
其他組態細節
在執行此解決方案時，若先以標準方式部署 ISA Server 和 Exchange，可以更輕鬆的完成工作。不要一次加入整個 Kerberos 限制委派解決方案和設定 (尤其是您之前若從未部署過 ISA Server，更不要這麼做)。若處理程序中有元件或步驟失敗，這麼做會使得疑難排解的程序更加複雜。比較簡單的做法是採用標準方式部署 ISA Server 和 Exchange (採取使用者名稱和密碼、但沒有表格式的驗證)，先確保安裝之後可以正常運作，然後再轉換到 Kerberos 限制委派和認證驗證。
一般而言，表格式驗證無法在啟用了智慧卡的 OWA 中使用。表格式驗證表示使用者會透過標準 Outlook 表格，提交使用者名稱和密碼。然而，有了智慧卡的雙重關卡驗證，使用者只會有智慧卡，沒有密碼。因此表格式驗證將無法接受或提交只具有認證的驗證。在鏈結中任一處使用表格式驗證 (例如在 ISA Server 後方的前端伺服器)，都會破壞啟用了智慧卡的 OWA 組態。若您啟用表格式驗證，Exchange 虛擬目錄會強制設定為基本驗證，因此 IIS Metabase 也會同時設定為基本驗證。
如果在您的使用者群組中，有些會用使用者名稱/密碼，有些則用智慧卡，那麼您就可以啟用 ISA Web 接聽程式的後援驗證，當使用者在出現認證提示後按下 ESC 鍵，電腦就會提示使用者輸入標準使用者名稱/密碼認證，即使 Exchange Server 的 ISA Server 已啟用整合式驗證。此外，ISA Server 可以讓 SSL 工作階段逾時，方法和表格式驗證功能大同小異。
結論
使用智慧卡支援 OWA 驗證對於 Exchange Server 2003 和 Exchange Server 2007 來說，都具有加分效果。使用者能夠使用認證登入 OWA，就不再需要擔心記不住又臭又長的密碼，而系統管理員現在也可以利用更有效的工具，來對付以病毒感染系統而竊取使用者身分的按鍵記錄程式與其他惡意程式。如需詳細資訊，請參閱 [資源] 資訊看板。
為 ISA Server 正確設定雙重關卡驗證與智慧卡的功能，可以提升整體安全性，甚至能進一步在發佈的 OWA 應用程式上，執行應用程式層級的篩選工作。此外，ISA Server 2006 具有可透過簡易的發佈精靈，同時發佈 Exchange Server 2003 和 Exchange Server 2007 的內建支援，因此 ISA Server 仍是各組織移轉至 Exchange Server 2007 的有效投資標的。
資源
- 在 Exchange Server 2003 中，如何共用已由 Outlook Web Access 之 "Safe HTML" 篩選功能移除的檔案
- 為 Kerberos 委派進行疑難排解
- Metabase 更新服務
- ISA Server 2006 中的驗證
- Kerberos 通訊協定的轉換與限制委派
- TechNet 網路廣播：使用智慧卡執行多重關卡驗證
Victor Akinnagbe 為 Microsoft 專案領域工程師，工作地點在華盛頓。他的專長包括安全性、基礎架構以及郵件訊息。
Ted Dressel 擔任 Microsoft 顧問，工作地點在華盛頓。他的專長包括安全性和基礎架構。
Jason Opdycke 為 Microsoft 首席專業工程師，工作地點在北卡夏洛特市。他的專長包括安全性和基礎架構。
© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.