身份驗證 在“微軟身份和訪(fǎng)問(wèn)管理平臺”中，建議使用 Microsoft? Active Directory? 目錄服務(wù)技術(shù)來(lái)存儲身份信息的技術(shù)，其中包括在身份驗證流程中驗證用戶(hù)憑證的加密密鑰。 與 Microsoft Windows Server? 2003、Microsoft Windows? XP Professional 及 Windows 安全服務(wù)相集成的應用程序通常使用操作系統的內置功能來(lái)執行身份驗證。 Windows 身份驗證服務(wù) 按應用程序實(shí)施身份驗證協(xié)議不僅效率非常低下，而且還可能會(huì )給組織帶來(lái)安全漏洞。較為合理的方法是使用 Windows 平臺中的身份驗證機制來(lái)構建應用程序。 為達到最佳效果，在開(kāi)始應用程序設計流程前，開(kāi)發(fā)人員需要了解使用不同協(xié)議及協(xié)議支持接口的不同身份驗證類(lèi)型和分支。 Windows 身份驗證服務(wù)體系結構 Windows Server 2003 和 Microsoft Windows XP 實(shí)現了一套完整的身份驗證方法和安全協(xié)議，可以滿(mǎn)足許多應用程序的身份驗證需求。Microsoft .NET Passport、通過(guò)證書(shū)或智能卡進(jìn)行的公鑰身份驗證及用戶(hù)名/密碼組合因各自不同的憑證要求提供不同的用戶(hù)體驗，而且各種方法都各有其不同的安全特征。數據傳輸機制還可以定義您可以使用的身份驗證協(xié)議。 “微軟身份和訪(fǎng)問(wèn)管理”平臺中身份驗證服務(wù)的安全系統可分為劃分幾種級別：其范圍從提供較高靈活性和控制能力的較低級別接口直到靈活性較低但應用程序編程接口 (API) 更為簡(jiǎn)單的高級別接口。下圖顯示了如何劃分身份驗證協(xié)議和應用程序 API 的層次結構。 圖 6.1.Windows 操作系統中的身份驗證 API 和協(xié)議層次結構
查看大圖 在上圖中身份驗證堆棧的頂部，高級別 API 和服務(wù)提供了進(jìn)程間通信 (IPC) 機制，為傳輸應用程序數據提供通過(guò)驗證的安全通道。這種服務(wù)和 API 的示例包括分布式組件對象模型 (DCOM)、遠程過(guò)程調用 (RPC)、Microsoft ASP.NET、ASP、WinInet 等等。 微軟的 RPC 是一種功能強大、高效而又安全的 IPC 機制，它支持數據交換和調用駐留于不同進(jìn)程中的功能。這種進(jìn)程可以位于同一臺計算機上，也可以位于局域網(wǎng)上或 Internet 中。 WinInet 是專(zhuān)為支持 Internet 安全協(xié)議（例如 Internet 協(xié)議上的安全套接字層 (SSL)）而設計的一種應用程序協(xié)議接口。WinInet 安全支持的實(shí)現將安全支持提供程序接口 (SSPI) 應用于安全通道（SSL 的 Windows NT? 實(shí)現）安全提供程序。 有些情況下，這些服務(wù)所公開(kāi)的 API 可以幫助應用程序開(kāi)發(fā)人員全面控制身份驗證的執行和數據的保護。例如，DCOM API 允許開(kāi)發(fā)人員選擇特定的身份驗證協(xié)議，如 Kerberos 協(xié)議或 NT LAN Manager (NTLM) 挑戰/響應。它還指定應將數據簽名（防止攻擊者更改數據）還是加密（防止竊取者查看數據）。而其他服務(wù)和 API 只受系統配置的影響。最能說(shuō)明這一點(diǎn)的是 ASP.NET，它寄宿在運行 Microsoft Internet Information Services (IIS) 6.0 的服務(wù)器上，而后者可配置為針對特定情況使用相應的身份驗證機制。 安全支持提供程序接口 SSPI 是最低級別的身份驗證應用程序接口，是通用安全服務(wù) API (GSS-API) 的微軟版本。有關(guān) GSS-API 的更多信息，請參見(jiàn)“Internet 工程工作組”(ITEF) 請求注解 網(wǎng)站上的 RFC 1508 和 1509。 有關(guān) SSPI 的更多信息，請參見(jiàn) MSDN 網(wǎng)站上的再談安全支持提供程序接口 一文。 SSPI 和 GSS-API 所暗含的理念是雙方的網(wǎng)絡(luò )身份驗證通常遵循一種公共模式。各方需要按一定的順序交換一條或多條信息。由于他們可以從眾多不同網(wǎng)絡(luò )協(xié)議（超文本傳輸協(xié)議 (HTTP)、RPC、服務(wù)器消息塊 (SMB)、Internet Inter-ORB 協(xié)議 (IIOP)、DCOM、Java 遠程方法調用 (RMI) 等）中選擇一種進(jìn)行通信，因此最好不要將單一的身份驗證握手硬編碼到網(wǎng)絡(luò )協(xié)議之中。更好的辦法是只提供產(chǎn)生“身份驗證令牌”的泛型接口，這些驗證令牌其實(shí)只是代表身份驗證序列某個(gè)方面的二進(jìn)制數據結構。這些令牌通過(guò)所用的應用程序協(xié)議進(jìn)行交換。 例如，在 RPC 中，已使用握手進(jìn)程來(lái)同步客戶(hù)端和服務(wù)器之間的協(xié)議。RPC 只在此握手進(jìn)程中為任意大小的不透明身份驗證令牌提供空間。SSPI 和 GSS-API 所執行的大部分工作是生成和評估這些令牌。 如前所述，Windows Server 和客戶(hù)端操作系統實(shí)現了多種身份驗證協(xié)議。這些協(xié)議即是“安全數據包”，其中包括由本地安全授權服務(wù)加載的 DLL 文件。SSPI 是 Windows Server 和客戶(hù)端操作系統中所有安全數據包的接口。這些安全數據包通常用于實(shí)現一項網(wǎng)絡(luò )身份驗證協(xié)議，如 Kerberos 版本5 身份驗證協(xié)議、NTLM 挑戰/響應、摘要身份驗證、安全套接字層 (SSL) 或傳輸層安全 (TLS)。應用程序可以使用這些協(xié)議安全、無(wú)縫地集成 Active Directory ，進(jìn)行身份驗證，還可以使用協(xié)議的各種功能來(lái)保證應用程序數據的安全。 安全協(xié)議協(xié)商 (SPNEGO) 是根據需要在身份驗證協(xié)議之間進(jìn)行協(xié)商的特殊安全數據包。對于使用 SSPI 和 Kerberos 版本5 協(xié)議或 NTLM 的應用程序而言，最好使用 SPNEGO 數據包，而不要直接使用這些協(xié)議。有關(guān) SPNEGO 的更多信息，請參見(jiàn) MSDN 上的 Windows 安全性 頁(yè)面。 Kerberos 身份驗證 Kerberos 版本5 身份驗證協(xié)議的說(shuō)明請參見(jiàn)“請求注解”網(wǎng)站上的 IETF RFC 1510 頁(yè)面。此協(xié)議具有極高的安全性和可伸縮性，因此非常適合集成網(wǎng)絡(luò )環(huán)境中的身份驗證。 在運行 Microsoft Windows 2000 Server 或其更高版本的 Windows 服務(wù)器和客戶(hù)端中，Kerberos 版本5 身份驗證協(xié)議是 Active Directory 身份驗證的基礎。它還集成在 SMB、HTTP 和 RPC 及使用這些協(xié)議的客戶(hù)端和服務(wù)器應用程序中。Windows 平臺為用戶(hù)提供了對此強大安全工具的無(wú)縫集成體驗。 Kerberos 版本5 協(xié)議對于“微軟身份和訪(fǎng)問(wèn)管理”平臺非常重要，因為它基于一個(gè)開(kāi)放的標準。許多其他供應商業(yè)已根據 Kerberos 版本5 協(xié)議的麻省理工學(xué)院 (MIT) 實(shí)現實(shí)施了該項協(xié)議，從而為在微軟和非微軟平臺及應用程序之間實(shí)現身份驗證互操作性奠定了基礎。 Windows 支持兩種配置 Kerberos 版本5 協(xié)議實(shí)現互操作性的方法： | ? | 在 Windows 域和基于 MIT 的 Kerberos 版本5 協(xié)議領(lǐng)域之間建立信任關(guān)系。這種關(guān)系使得此領(lǐng)域中的客戶(hù)端可以通過(guò)信任機制驗證連接到 Windows 域中的網(wǎng)絡(luò )資源。 | | ? | 非 Windows 客戶(hù)端和服務(wù)器可以使用 Active Directory 帳戶(hù)從域控制器獲得身份驗證。 | 在 Intranet 中，在 Windows 平臺上的 Kerberos 版本5 協(xié)議實(shí)現可以為用戶(hù)提供 SSO 功能，這是由于身份驗證協(xié)議的基本特征和協(xié)議在 Windows 客戶(hù)端及服務(wù)器操作系統中實(shí)現方式的具體特性而決定的。 阻礙 Kerberos 版本5 協(xié)議成為應用程序身份驗證和安全的通用解決方案的一個(gè)最主要限制是，無(wú)法將 Kerberos 身份驗證配置在 Internet 上使用。其中的原因將在本章稍后的“Web 單一登錄”部分詳細探討。 有關(guān) Kerberos 版本5 身份驗證協(xié)議的更多信息，請參見(jiàn) Microsoft TechNet 上的循序漸進(jìn)指南：Kerberos 5 (krb5 1.0) 互操作性 頁(yè)面。 安全套接字層 3.0 和傳輸層安全 1.0 SSL 3.0 和 TLS 1.0 是兩個(gè)密切相關(guān)的協(xié)議，可用于解決兩應用程序間通信通道的一般安全問(wèn)題。SSL 3.0 是一個(gè)專(zhuān)有的 Netscape 通信協(xié)議，而 TLS 1.0 是“請求注解”網(wǎng)站上的 IETF 標準 RFC 2246 定義。兩個(gè)協(xié)議頗為相似，但 TLS 包含一些重要的改進(jìn)，因此微軟建議盡可能使用此協(xié)議。TLS 和 SSL 均支持在建立安全數據通道期間進(jìn)行服務(wù)器身份驗證，也允許選擇進(jìn)行客戶(hù)端身份驗證。 SSL 和 TLS 協(xié)議常用于在 HTTP 協(xié)議上提供數據保護和完整性（加密）。其他協(xié)議也支持 SSL 或 TLS。例如，輕型目錄訪(fǎng)問(wèn)協(xié)議 (LDAP) 與 SSL 合并后產(chǎn)生了 LDAP over SSL，即 LDAPS。此外，自定義或第三方應用程序也可以通過(guò) SSPI 直接使用 SSL 或 TLS，和指定 SChannel 安全數據包。 SSL 和 TLS 采用對稱(chēng)加密密鑰提供了基于證書(shū)和安全數據傳輸的身份驗證。在 Internet 上，組織通常使用 SSL 和 TLS 進(jìn)行服務(wù)器身份驗證?？蛻?hù)端通過(guò)核對下列條件來(lái)用 SSL 和 TLS 驗證服務(wù)器： | ? | 服務(wù)器證書(shū)有效。 | | ? | 經(jīng)證實(shí)，服務(wù)器擁有與服務(wù)器 X.509 證書(shū)相關(guān)的相應私鑰。 | | ? | 所驗證的服務(wù)器即為證書(shū)中所指定的服務(wù)器。 | SSL 和 TLS 還支持客戶(hù)端身份驗證，并通過(guò) X.509 客戶(hù)端證書(shū)將客戶(hù)端身份驗證與 Windows Server 2003 平臺相集成。同時(shí)進(jìn)行客戶(hù)端和服務(wù)器身份驗證通常稱(chēng)為相互身份驗證。為了完成客戶(hù)端身份驗證，客戶(hù)端須提供有效的客戶(hù)端證書(shū)，服務(wù)器根據針對服務(wù)器身份驗證描述的條件進(jìn)行衡量。Windows Server 確認客戶(hù)端證書(shū)有效后，將其映射到 Active Directory 帳戶(hù)。對于證書(shū)的映射方式， Active Directory 提供了很大的靈活性，既允許一對一映射，也允許多對一映射。 在使用 X.509 數字證書(shū)進(jìn)行身份驗證時(shí)，SSL 和 TLS 比其他身份驗證協(xié)議具有更高的安全性。 注意 SSL 和 TLS 在 Windows XP 客戶(hù)端上通過(guò) Windows 憑證管理器為用戶(hù)提供 Web SSO 功能，這一點(diǎn)將在本章稍后部分介紹。 Passport 身份驗證 Microsoft Passport 是一種 Web 服務(wù)，它根據龐大的數字身份數據庫對用戶(hù)進(jìn)行驗證。個(gè)人可通過(guò)某個(gè)安全網(wǎng)站來(lái)維護其 Passport 身份。Passport 在許多網(wǎng)站啟用了身份驗證和 Web SSO 功能，而且在許多微軟網(wǎng)站和一些不屬于微軟的站點(diǎn)都在使用 Passport。 開(kāi)發(fā)人員可以創(chuàng )建鏈接到 Passport 的應用程序，從而使應用程序僅接受來(lái)自已注冊 Passport 用戶(hù)的連接。如果 Passport 確定用戶(hù)的憑證有效，即會(huì )返回一個(gè)身份驗證票證，應用程序可以通過(guò)解密此票證來(lái)確定用戶(hù)的身份。為保護隱私，典型的 Passport 身份驗證只將一個(gè) Passport 唯一 ID (PUID) 傳送給相關(guān)的應用程序。 通常，應用程序隨后會(huì )將此 PUID 映射至本地維護的用戶(hù)帳戶(hù)，以派生在組織中有效的數字身份。在選中 IIS 6.0 中 Passport 身份驗證配置選項時(shí)，Windows Server 2003 將與 Passport 完全集成。此外，還可以將 Passport 用戶(hù)映射到 Active Directory 帳戶(hù)，使 Passport 身份驗證與 Windows 安全模型完全集成。 對于面向 Internet 的應用程序，Passport 身份驗證為用戶(hù)提供了 SSO 體驗。Passport 通過(guò)提供在 HTTP cookie 中編碼的身份驗證票證來(lái)實(shí)現此項功能。引入 Cookie（在瀏覽器會(huì )話(huà)的生命周期內維護）后，用戶(hù)無(wú)需重復登錄到 Passport 身份驗證服務(wù)即可完成對多個(gè)應用程序的身份驗證。 有關(guān) Passport 的更多信息，請參見(jiàn) MSDN 上的.NET Passport 服務(wù)指南套件 。 摘要身份驗證 摘要身份驗證是“請求注解”網(wǎng)站上 RFC 2617 中介紹的另一種基于標準的身份驗證協(xié)議，它作為一個(gè)驗證數據包而包含在 Windows Server 2003 之中。摘要身份驗證主要用于在 Windows 和非 Windows 平臺之間實(shí)現 Internet 身份驗證的互操作性。 Windows Server 2003 還將摘要身份驗證作為一個(gè)簡(jiǎn)單的身份驗證和安全層 (SASL) 機制來(lái)實(shí)現（如“請求注解”網(wǎng)站的 RFC 2831 中所述）。SASL 是應用程序和底層協(xié)議之間的另一個(gè)抽象層，通過(guò)該抽象層可以在不更改應用程序的情況下輕松引入不同的身份驗證機制。在某些方面，它與先前所述的 SPNEGO 機制類(lèi)似。SASL 主要用于 LDAP 身份驗證。 摘要身份驗證與 NTLM 專(zhuān)有協(xié)議具有相似的安全特征。摘要身份驗證與 NTLM 均為挑戰/響應協(xié)議，都需要驗證服務(wù)器生成包含一些不可預知數據的挑戰。隨后，客戶(hù)端使用從用戶(hù)密碼派生的密鑰加密挑戰，從而形成響應。服務(wù)器或者受信任的第三方服務(wù)（如 Active Directory ）通過(guò)將客戶(hù)端的響應與根據身份存儲中用戶(hù)的相關(guān)憑證計算出的值進(jìn)行比較，檢驗用戶(hù)是否擁有正確的密碼。如果響應與計算值相匹配，則認為用戶(hù)知道安全密碼，并通過(guò)身份驗證。 一般而言，摘要身份驗證不如 Kerberos 版本5 協(xié)議安全，因為它依靠強密碼來(lái)防止針對挑戰/響應機制的攻擊。但是，由于在身份驗證期間不會(huì )向服務(wù)器提供明文密碼，因此摘要身份驗證要比基于表單的身份驗證或基本身份驗證更為可靠。SSL 和 TLS 通常用于保護摘要身份驗證免遭攻擊。 大多數情況下，摘要身份驗證的可伸縮性不如 Kerberos 版本5 協(xié)議，但它可以在無(wú)法應用 Kerberos 協(xié)議的場(chǎng)合使用。例如對面向外部的網(wǎng)站的驗證。 摘要身份驗證提供 SSO 只是為了保護通過(guò)單一 Web URL 得到的信息。如果用戶(hù)導航至不同站點(diǎn)，或者導航至同一站點(diǎn)中的不同服務(wù)器，通常必須要再次輸入他們的憑證。 基于表單的身份驗證 基于表單的身份驗證依靠網(wǎng)頁(yè)中的登錄表單來(lái)收集用戶(hù)憑證，形式基本只有明文用戶(hù)名與密碼一種。因此，此類(lèi)身份驗證與我們前面介紹的 Kerberos 版本5 協(xié)議或摘要身份驗證不同，并不是客戶(hù)端和服務(wù)器之間的身份驗證協(xié)議。 基于表單的身份驗證需要格外小心，才能有力地保護支持它的應用程序，因此微軟建議在沒(méi)有 SSL 的情況下不要使用這種身份驗證方式。在使用基于表單身份驗證的應用程序中存在著(zhù)一個(gè)很大的漏洞，攻擊者可以利用它來(lái)竊取明文密碼數據，這將嚴重危及組織中應用程序數據和網(wǎng)絡(luò )自身的安全。 因為執行基于表單身份驗證的應用程序以明文形式接收用戶(hù)憑證，所以應用程序可以選擇根據其他用戶(hù)存儲而不是 Active Directory 進(jìn)行身份驗證。微軟建議在大多數情形下都不要使用這種方法，因為附加的身份存儲會(huì )使身份和訪(fǎng)問(wèn)管理解決方案復雜化。 實(shí)現基于表單身份驗證的應用程序開(kāi)發(fā)人員在以 Active Directory 方式驗證用戶(hù)時(shí)，最好使用 LDAP 綁定或 LogonUser() 這樣的 Windows API 來(lái)確認用戶(hù)憑證，也可以生成一個(gè)安全上下文，在本章后面的“身份驗證”部分對此進(jìn)行了說(shuō)明。 實(shí)施基于表單的身份驗證的應用程序通常會(huì )使用 HTTP cookie 或 URL 修改來(lái)為用戶(hù)提供 SSO。ASP.NET 提供了通過(guò)加密技術(shù)來(lái)防止未授權讀取并通過(guò)數字簽名來(lái)防止隨意篡改的 cookie 保護功能。 本系列文章中的“開(kāi)發(fā)可識別身份的 ASP.NET 應用程序”一文中，詳細介紹了開(kāi)發(fā)人員應如何在 Windows 平臺上使用基于表單的身份驗證。 基本身份驗證 與基于表單的身份驗證一樣，基本身份驗證并非真正的網(wǎng)絡(luò )身份驗證協(xié)議，因為在進(jìn)行網(wǎng)絡(luò )資源驗證時(shí)它并不以加密的方式來(lái)保護用戶(hù)的憑證。與基于表單的身份驗證一樣，執行此類(lèi)身份驗證的服務(wù)器以明文形式接收用戶(hù)憑證，然后使用 Windows API 驗證用戶(hù)。與基于表單的身份驗證的另一點(diǎn)相同之處是，部署此類(lèi)身份驗證技術(shù)的開(kāi)發(fā)人員和系統管理員必須付出巨大的努力來(lái)保護應用程序或服務(wù)器免遭危害。因此，微軟強烈建議在沒(méi)有 SSL 的情況下不要使用基本身份驗證?；旧矸蒡炞C與摘要身份驗證具有相同的 SSO 特征。 單一登錄 任何關(guān)于身份驗證的探討都少不了一個(gè)重要概念，即單一登錄 (SSO)。在身份驗證進(jìn)程中實(shí)施 SSO 的方式有多種： | ? | 桌面集成的 SSO。 | | ? | Web SSO。 | | ? | 憑證映射，或企業(yè) SSO。 | SSO 完全省去了額外輸入用戶(hù)憑證的過(guò)程，也意味著(zhù)不必再去判斷其中所涉及的身份驗證安全級別。出于安全性考慮，有一些 SSO 類(lèi)型可能比其他的更好一些。 此外，Extranet SSO 和 Intranet SSO 這兩個(gè)術(shù)語(yǔ)是指在 Extranet 或 Intranet 情景中實(shí)現 SSO 時(shí)所采用的技術(shù)。Extranet SSO 通?；?Web，而 Intranet SSO 則會(huì )涉及許多類(lèi)型的應用程序和服務(wù)，其中包括 Web 應用程序、胖客戶(hù)端應用程序和終端會(huì )話(huà)。 桌面集成的單一登錄 安全登錄要求用戶(hù)向網(wǎng)絡(luò )提供其身份的證明，但是以反復鍵入密碼的方式訪(fǎng)問(wèn)多個(gè)資源會(huì )令用戶(hù)感到厭煩。Microsoft Windows 平臺利用單一登錄功能，跨網(wǎng)絡(luò )中使用單一用戶(hù)身份（在 Active Directory 中維護）。由于用來(lái)登錄到工作站的憑證往往就是用來(lái)訪(fǎng)問(wèn)網(wǎng)絡(luò )資源的憑證，因此用戶(hù)的登錄憑證（用戶(hù)名和密碼組合）將會(huì )被緩存到客戶(hù)端操作系統本地的“本地安全授權”(LSA) 中。用戶(hù)登錄到域中后，在驗證到網(wǎng)絡(luò )資源時(shí)，Windows 身份驗證將使用這些緩存的憑證來(lái)提供 SSO。 為確保良好的安全性，需要用戶(hù)提供一個(gè)經(jīng)過(guò)驗證的身份來(lái)訪(fǎng)問(wèn)網(wǎng)絡(luò )資源。通過(guò) SSO，用戶(hù)只需經(jīng)過(guò)一次系統身份驗證即可訪(fǎng)問(wèn)他們有權使用的所有應用程序和數據源，而不必再輸入另一個(gè)帳戶(hù) ID 或密碼。 Kerberos 版本5 身份驗證協(xié)議、NTLM 和智能卡身份驗證技術(shù)均與微軟客戶(hù)端及服務(wù)器操作系統中的桌面登錄進(jìn)程相集成，以為組織 Intranet 中 Windows 域或 Windows 林內的用戶(hù)提供 SSO 體驗。 Active Directory 提供了受信任的第三方，使服務(wù)器無(wú)需本地存儲每個(gè)用戶(hù)的相關(guān)信息即可驗證用戶(hù)。 Windows Server 2003 中的高級信任機制（例如跨林信任）允許某個(gè)林中的身份在訪(fǎng)問(wèn)其他林中的資源時(shí)享用 SSO。 Web 單一登錄 由于越來(lái)越多的公司都在部署員工、合作伙伴和客戶(hù)使用的 Extranet 和 Intranet Web 應用程序，因此為用戶(hù)提供 SSO 體驗的能力就變得非常重要。 Web 應用程序與傳統的“胖”客戶(hù)端/服務(wù)器應用程序不同，因為它們通常依靠 Web 服務(wù)器實(shí)現身份驗證。這種依賴(lài)性使用戶(hù)可以通過(guò)常用方法將身份驗證機制添加到單一應用程序（Web 服務(wù)器）中，同時(shí)還解決了大量服務(wù)器托管應用程序的身份驗證問(wèn)題。在 Intranet 環(huán)境中，微軟服務(wù)器和客戶(hù)端產(chǎn)品通過(guò)在 Internet Explorer 和 IIS 6.0 中實(shí)施 Kerberos 版本5 身份驗證協(xié)議來(lái)提供 Web 單一登錄或 Web SSO，本系列文章的“Intranet 訪(fǎng)問(wèn)管理”一文將對此進(jìn)行了描述。 不幸的是，Intranet 環(huán)境中行之有效的 Kerberos 實(shí)現對組織 Extranet 中面向 Internet 的應用程序卻束手無(wú)策。Intranet 和 Extranet Web SSO 之間的差異是以下三個(gè)因素共同作用的結果： | ? | 部署面向 Internet 的“密鑰分發(fā)中心”(KDC)（例如 Active Directory 域控制器）過(guò)程中固有的困難。 | | ? | 許多瀏覽器不支持在 HTTP 上進(jìn)行 Kerberos 身份驗證。 | | ? | KDC 協(xié)議中原有的漏洞 | 雖然對部署面向 Internet 的 KDC 過(guò)程中固有困難的詳細討論不在本文的論述范圍之內，但該問(wèn)題卻是實(shí)施部署的一大障礙。 第二個(gè)問(wèn)題對 Extranet 部署的影響通常更為明顯。與內部部署不同，軟件標準在內部是強制執行的，然而很少有組織能夠規定外部客戶(hù)和商業(yè)合作伙伴使用哪種類(lèi)型和版本的瀏覽器軟件來(lái)訪(fǎng)問(wèn)外部應用程序。Microsoft Internet Explorer 6.0 及更高版本是市面上唯一可以買(mǎi)到的支持在 HTTP 上進(jìn)行 Kerberos 身份驗證的瀏覽器。 解決多個(gè) Web 應用程序 SSO 問(wèn)題的標準方法是使用會(huì )話(huà)“cookie”，“HTTP 狀態(tài)管理機制”提供了對此的詳細介紹，在“請求注解”網(wǎng)站上將由 IETFRFC 2109 加以定義。一些獨立軟件供應商 (ISV) 提供了跨 Extranet Web 應用程序實(shí)現 Web SSO 的解決方案。 對于支持 Passport 身份驗證的站點(diǎn)，前文詳細介紹的 Microsoft Passport 服務(wù)也為用戶(hù)提供了 SSO 體驗。 用戶(hù)可以將 Web SSO 技術(shù)與企業(yè) SSO 技術(shù)結合起來(lái)，如 SharePoint Portal Server 站點(diǎn)，它包括用于訪(fǎng)問(wèn)唯一身份驗證目錄內舊版應用程序數據的 Web 部件。在此示例中，Web SSO 技術(shù)提供對網(wǎng)站的訪(fǎng)問(wèn)，而企業(yè) SSO 技術(shù)則提供對舊版應用程序數據的訪(fǎng)問(wèn)。 憑證映射和企業(yè)單一登錄 “企業(yè) SSO”是指采用憑證映射形式提供 SSO 體驗的任何技術(shù)。其中，憑證映射是一個(gè)必備因素，因為身份驗證會(huì )涉及多種不同的身份存儲或目錄。某項服務(wù)（運行于客戶(hù)端或服務(wù)器上）可以代表帳戶(hù)登錄到目標應用程序，模擬 SSO 體驗。這種服務(wù)必須從憑證映射存儲或數據庫中查找相應的憑證（帳戶(hù)、密碼等等）。 Microsoft BizTalk? Server、Host Integration Server、SharePoint? Portal Server、Windows 憑證管理器以及來(lái)自 PassLogix、Protocom 和 Version3 等 ISV 的產(chǎn)品都采用各種不同的企業(yè) SSO 技術(shù)來(lái)針對遺留系統和使用自身目錄進(jìn)行身份驗證的應用程序實(shí)現 SSO，甚至用它來(lái)實(shí)現對不可信 Windows 域中資源的訪(fǎng)問(wèn)。 許多組織都存在擁有多個(gè)非信任身份存儲卻沒(méi)有實(shí)現 SSO 的現象，與之相比“企業(yè) SSO”能夠提供更好的用戶(hù)體驗?！捌髽I(yè) SSO”方法應與配置和密碼管理方法相集成，以確保無(wú)縫的體驗和最大程度減少幫助臺的呼叫次數。這種方法在最大程度降低總擁有成本的同時(shí)還可提供最佳的用戶(hù)體驗。 注意 由于“桌面集成的 SSO”與選項目錄緊密集成，而且不需要額外的冗余目錄和憑證映射數據庫配置和管理，因此要優(yōu)于企業(yè) SSO。 有關(guān)通過(guò)“企業(yè) SSO”實(shí)現憑證映射的更多信息，請參見(jiàn)本系列文章中的“Intranet 訪(fǎng)問(wèn)管理”一文。 Windows 憑證管理器 Windows XP Professional 和 Windows Server 2003 中包括一項“存儲的用戶(hù)名和密碼”功能，它也可提供憑證管理功能。此組件可以根據所嘗試的身份驗證類(lèi)型，保存用戶(hù)憑證，并在以后的訪(fǎng)問(wèn)嘗試過(guò)程中重新加以使用。 圖 6.2.“存儲的用戶(hù)名和密碼”支持多組憑證的 SSO 如果應用程序不允許用戶(hù)保存憑證，用戶(hù)則必須手動(dòng)訪(fǎng)問(wèn)“存儲的用戶(hù)名和密碼”來(lái)設置該資源的憑證。憑證管理器支持以下類(lèi)型的憑證： | ? | Kerberos 版本5 協(xié)議和 NTLM 身份驗證的用戶(hù)名/密碼組合。 | | ? | 使用 SSL/TLS 進(jìn)行客戶(hù)端身份驗證的 X.509 數字證書(shū)。 | | ? | 用于 Web 身份驗證的 Microsoft Passport 憑證。 | 注意 用戶(hù)可以使用 Windows 憑證管理器通過(guò) SSL/TLS X.509 客戶(hù)端證書(shū)身份驗證提供 Web SSO 體驗。默認情況下，只要用戶(hù)擁有一個(gè)以上的有效證書(shū)，就會(huì )看到提示選擇身份驗證證書(shū)的消息。憑證管理器可確保在驗證對特定資源的訪(fǎng)問(wèn)權限時(shí)自動(dòng)提供適當的證書(shū)。 有關(guān) Windows 憑證管理器的更多信息，請參見(jiàn)本系列文章中的“Intranet 訪(fǎng)問(wèn)管理”一文。 授權 授權是應用程序或平臺通過(guò)對比用戶(hù)權利和資源安全配置來(lái)確定資源訪(fǎng)問(wèn)權的過(guò)程。例如，用戶(hù)可對文件服務(wù)器提出驗證請求，服務(wù)器隨后確定用戶(hù)是否具有讀、寫(xiě)或刪除文件的能力。 與 Windows Server 2003 操作系統及 Active Directory 相集成的應用程序使用操作系統的內置功能來(lái)執行授權。 Windows Server 2003 支持兩種授權機制：基于 Windows 訪(fǎng)問(wèn)控制列表 (ACL) 的模擬模型，和基于角色的新型授權管理器。此外，Microsoft ASP.NET 應用程序還可以使用 ASP.NET 角色進(jìn)行授權。以下部分將詳細討論這兩種機制。 Windows 模擬和訪(fǎng)問(wèn)控制列表 Microsoft Windows NT 3.1 引入了模擬和 ACL 模型來(lái)為服務(wù)和應用程序提供授權。模擬是為實(shí)現無(wú)縫用戶(hù)體驗和輕松管理而緊密耦合身份驗證和授權的產(chǎn)物。 身份驗證數據包首先驗證用戶(hù)，然后為該用戶(hù)構建“安全上下文”。安全上下文代表用戶(hù)身份和所屬的組以及用戶(hù)的權利。一旦身份驗證數據包生成安全上下文，應用程序或服務(wù)即可獲得允許訪(fǎng)問(wèn)資源的安全上下文。換句話(huà)說(shuō)，服務(wù)在嘗試訪(fǎng)問(wèn)資源時(shí)，可以使用用戶(hù)的安全上下文（而非服務(wù)自身的上下文）獲得訪(fǎng)問(wèn)權，在本地模擬用戶(hù)。 這是一個(gè)很重要的概念，因為大多數服務(wù)在計算機中都擁有廣泛的權限。例如，在運行 Windows 的服務(wù)器上提供文件和打印服務(wù)的服務(wù)器消息塊 (SMB) 服務(wù)可作為本地系統運行，而且可以訪(fǎng)問(wèn)任何資源。為了根據文件所有者或系統管理員所建立的規則來(lái)限制用戶(hù)對文件的訪(fǎng)問(wèn)，SMB 服務(wù)應模擬遠程用戶(hù)。 Windows 授權模型的另一部分是基于對象的 ACL。對象的 ACL 定義了對象的訪(fǎng)問(wèn)級別安全主體（用戶(hù)或組）。例如，文件的 ACL 可以定義一個(gè)用戶(hù)擁有讀取某文件的權限，而另一個(gè)用戶(hù)擁有讀取和刪除該文件的權限。 操作系統（特別是 NT 對象管理器）是使用此模型訪(fǎng)問(wèn)對象時(shí)的最終仲裁者?！癗T 對象管理器”將用戶(hù)的安全上下文與對象的 ACL 加以比較，完成仲裁操作。由于操作系統是最終的仲裁者，因此模擬/ACL 模型的安全特性非常適合多個(gè)應用程序可以訪(fǎng)問(wèn)系統資源的方案。 然而，模擬/ACL 模型的某些方面仍有待進(jìn)一步改進(jìn)，其中包括： | ? | 性能。對于同時(shí)將內容傳送給多個(gè)不同用戶(hù)的服務(wù)，使用模擬來(lái)切換上下文會(huì )增加服務(wù)器的負荷，影響應用程序的可伸縮性。 | | ? | 靈活性。使用模擬模型時(shí)，應用程序開(kāi)發(fā)人員或服務(wù)管理員必須在域級別更改組成員身份之后才能為用戶(hù)創(chuàng )建新組或角色。域管理員反對為單一應用程序創(chuàng )建大量組供其使用，致使應用程序開(kāi)發(fā)人員只能利用目前現有的組進(jìn)行工作。 | | ? | 商業(yè)規則。模擬/ACL 模型充分表現了對象的授權，卻很難描述商業(yè)規則邏輯，例如日期時(shí)間或其他運行時(shí)邏輯。例如，用戶(hù)可能希望實(shí)行一種僅允許特定的人員在特定時(shí)間執行特定動(dòng)作的授權策略。 | 為克服這些問(wèn)題，Windows Server 2003 為系統管理員和應用程序開(kāi)發(fā)人員加入了“授權管理器”。授權管理器的 Windows 2000 版本可從 Microsoft.com 的 Windows 2000 授權管理器運行時(shí) 下載頁(yè)面獲得。 Windows Server 2003 授權管理器 Windows Server 2003 中的“授權管理器”是新的基于角色的訪(fǎng)問(wèn)控制 (RBAC) 接口?！笆跈喙芾砥鳌睘殚_(kāi)發(fā)人員提供了實(shí)現以下目標的能力： | ? | 簡(jiǎn)化應用程序訪(fǎng)問(wèn)控制管理。 | | ? | 提供精簡(jiǎn)自然的開(kāi)發(fā)模型。 | | ? | 實(shí)現靈活而動(dòng)態(tài)的授權決策。 | 對于特定任務(wù)，“授權管理器”接口將用戶(hù)與應用程序內的各種角色有機地組織在一起，并在模擬這些角色時(shí)給予其訪(fǎng)問(wèn)權限。下圖顯示了訪(fǎng)問(wèn)某個(gè)應用程序的三個(gè)不同用戶(hù)?！笆跈喙芾砥鳌睂⒚總€(gè)用戶(hù)都映射到在授權策略存儲中所定義的角色。 “授權管理器”提供了根據每個(gè)應用程序的需求定義和維護邏輯角色及任務(wù)的能力。這種根據組織結構表現安全模型的方式簡(jiǎn)化了訪(fǎng)問(wèn)控制管理。此外，任務(wù)和角色的定義有助于為應用程序工作流建模，也有助于通過(guò)“授權管理器”為開(kāi)發(fā)人員提供一個(gè)以應用程序為中心的自然環(huán)境。 “授權管理器”還動(dòng)態(tài)限定運行時(shí)賦予的權利。這一功能解決了行業(yè) (LOB) Web 應用程序（例如支出報告應用程序或基于 Web 的購物應用程序）存在的特殊授權問(wèn)題。 對于這種應用程序，對既定永久對象的訪(fǎng)問(wèn)往往不能做出授權決策。而是需要檢查工作流程或包含多個(gè)不同操作的操作組，例如查詢(xún)數據庫和發(fā)送電子郵件消息。這樣的訪(fǎng)問(wèn)決策不僅基于令牌組成員身份，還基于商業(yè)邏輯，例如在支出應用程序或工作流完成驗證中提交的數量。這些沒(méi)有既定永久對象的應用程序沒(méi)有放置 ACL 的位置。這些動(dòng)態(tài)訪(fǎng)問(wèn)決策采用“授權管理器”所提供的動(dòng)態(tài)商業(yè)規則（稱(chēng)為 BizRule）形式，易于使用。 BizRule 通常使用在應用程序運行期間檢查訪(fǎng)問(wèn)權限時(shí)所執行的 Microsoft Visual Basic? Scripting Edition 腳本或 JScript? 例程來(lái)實(shí)現。如果 BizRule 成功，應用程序便執行所請求的操作。 定義應用程序所用邏輯角色和任務(wù)的授權管理器策略可以存儲在 Active Directory 或 Active Directory 應用程序模式的應用程序分區中，也可以存儲在服務(wù)器或網(wǎng)絡(luò )上的 XML 文件中。 有關(guān)使用 Windows Server 2003 授權管理器的 RBAC 的更多信息，請參見(jiàn) TechNet 上的授權管理器概念 頁(yè)面。 IIS 6.0 中提供了一個(gè)用于說(shuō)明應用程序如何使用授權管理器角色框架的示例。Windows Server 2003 中包含 IIS 6.0，它通過(guò)與“授權管理器”的集成來(lái)實(shí)現 IIS 6.0 URL 授權。實(shí)現這一集成后，Web 應用程序管理員可以根據自定義的用戶(hù)角色、LDAP 查詢(xún)和 BizRule 來(lái)控制對 URL 的訪(fǎng)問(wèn)。 在 IIS 6.0 中授權用戶(hù)對網(wǎng)頁(yè)的訪(fǎng)問(wèn)時(shí)，可能需要在 Web 應用程序所用的資源上管理多個(gè)自由訪(fǎng)問(wèn)控制列表 (DACL)。Web 應用程序的資源可能包括網(wǎng)頁(yè)文件、數據庫記錄和注冊表項。為了維護 DACL，管理員必須確切知道每個(gè)對象在 Web 應用程序中執行針對性任務(wù)必須具備哪些后端權限要求。 IIS 6.0 URL 授權使管理員可以通過(guò)授予用戶(hù)對構成 Web 應用程序的 URL 的訪(fǎng)問(wèn)權限，來(lái)簡(jiǎn)化訪(fǎng)問(wèn)管理?？蛻?hù)端請求 URL 時(shí)，IIS 6.0 URL 授權將根據用戶(hù)角色驗證用戶(hù)的訪(fǎng)問(wèn)權限。必要時(shí)，Web 應用程序可以使用授權管理器角色框架來(lái)進(jìn)一步限定對資源和操作的訪(fǎng)問(wèn)。 ASP.NET 授權 ASP.NET 提供了基于角色的授權模型，這種模型使用 Active Directory 組和應用程序派生角色。授權管理器 RBAC 和基于 ASP.NET 角色的授權有一些相似之處，但卻通過(guò)不同的機制來(lái)實(shí)現。ASP.NET 角色對于不能歸屬到更大型應用程序組中的獨立應用程序最為有用。 信任和聯(lián)合 有時(shí)您可能需要鏈接兩個(gè)或多個(gè)不同的身份存儲，例如在您需要實(shí)現合作關(guān)系安排或使用不同的外部和內部目錄結構時(shí)。這種鏈接使得僅對一個(gè)身份存儲擁有驗證資格的用戶(hù)可針對另一個(gè)身份存儲進(jìn)行驗證，即使他們在這個(gè)身份存儲中沒(méi)有數字身份，也能夠成功進(jìn)行驗證。這種安排稱(chēng)為信任關(guān)系。 信任關(guān)系存在于定義了安全邊界的不同領(lǐng)域之間。在 Windows NT 和 Active Directory 環(huán)境中，可以在域之間建立信任。在 Windows Server 2003 中，可以在林結構之間建立更高的信任級別。但林結構內部各域之間具有隱性的信任關(guān)系。 與 Windows Server 2003 及 Active Directory 相集成的應用程序使用操作系統的內置功能來(lái)建立和維護信任。 管理信任關(guān)系 在較高級別，信任關(guān)系只提供了一種在領(lǐng)域之間進(jìn)行身份驗證的方法。但是，信任機制變得越來(lái)越復雜，因為若要使身份驗證和后續授權真正具備實(shí)用價(jià)值，必須在領(lǐng)域之間執行許多任務(wù)。 本節的其余部分將介紹 Windows 平臺中可用的信任類(lèi)型，以及如何使用信任來(lái)解決身份和訪(fǎng)問(wèn)管理問(wèn)題。 外部信任 Microsoft Windows NT Server 中引入了域信任的概念。Windows NT 域信任（現稱(chēng)外部信任）允許一個(gè) Windows NT 域信任另一個(gè) Windows NT 域，將其視為一種特權來(lái)驗證隸屬于該域的用戶(hù)。外部信任既可以是單向的也可以是雙向的，信任的方向決定著(zhù)身份驗證和訪(fǎng)問(wèn)可能發(fā)生的方向，如下圖所示。 圖 6.4.信任域和被信任域之間的關(guān)系 Windows NT Server 4.0 模型非常靈活，它允許各部門(mén)根據需要采用自下而上的基層部署模式來(lái)實(shí)現 Windows NT 4.0 域。其問(wèn)題在于，由于各個(gè)大型公司引入了越來(lái)越多的域，使得管理外部信任關(guān)系逐漸成為一個(gè)非常嚴重的問(wèn)題。因為每個(gè)部署的域都可能擁有 n 多個(gè)信任關(guān)系，因此要管理的信任關(guān)系總數隨著(zhù)域數量的增加而迅速增加。擁有 4 個(gè)域的小型公司可能只需管理 12 個(gè)不同的信任關(guān)系，而擁有 10 個(gè)域的較大型公司則可能需要管理 90 個(gè)信任關(guān)系。擁有 100 個(gè)域的公司則要管理數量更為龐大的信任關(guān)系。 Windows 2000 Server 林 為簡(jiǎn)化大型組織中的信任管理，Microsoft Windows 2000 Server 引入了 Active Directory 林的概念。 Active Directory 林保留了 Windows NT Server 4.0 隨需式由下而上信任模型的靈活性，同時(shí)解決了執行自上而下信任管理的問(wèn)題，如下圖所示。 圖 6.5.單一 Windows 2000 Server 林 此圖形表示一個(gè)擁有單一 Windows 2000 Server 林的組織。林結構內部的信任關(guān)系是隱式信任，其功能與雙向外部信任相同，只是這些信任關(guān)系是向同一林中添加域（可看作林中的樹(shù)）時(shí)自動(dòng)創(chuàng )建的。林結構內部的域是有層次的，使組織的網(wǎng)絡(luò )能夠反映出組織的業(yè)務(wù)狀況。 遺憾的是，Windows 2000 Server 并沒(méi)有最終解決信任關(guān)系問(wèn)題。這種信任關(guān)系假設大多數公司在其整個(gè)網(wǎng)絡(luò )和資源范圍內部署單一林結構。然而，眾多原因決定了這種假設并不成立。 例如，一些非常龐大的組織沒(méi)有集中的信任管理組負責管理組織的所有資源。因此在這種組織中，組織各個(gè)不同部分間存在目錄服務(wù)體系結構必須實(shí)現的自然安全邊界。另一個(gè)常見(jiàn)的例子就是，對單獨 Intranet 林和 Extranet 林的需求。盡管開(kāi)發(fā)人員可以將 Extranet 設計為 Intranet 林的一個(gè)域，但是出于安全考慮，許多組織還是希望在 Extranet 和 Intranet 之間有更大程度的隔離。 有關(guān) Windows 域和林安全邊界特性的更多信息，請參見(jiàn) Microsoft.com 上的“創(chuàng )建和增強安全邊界”。 對于具有多個(gè) Windows 2000 Active Directory 林但又希望在不同林的域之間使用信任關(guān)系的組織來(lái)說(shuō)，必須在不同林的各域之間建立顯式信任關(guān)系。與在每個(gè) Windows NT Server 4.0 域之間建立信任關(guān)系相比，這種配置的實(shí)現只是稍微簡(jiǎn)單了一點(diǎn)點(diǎn)而已，所以必須找到一種更為優(yōu)秀的解決方案。 Windows Server 2003 林信任 為簡(jiǎn)化多個(gè)林的部署，Windows Server 2003 建立了林信任的概念。林信任允許管理員通過(guò)單一信任關(guān)系聯(lián)合兩個(gè) Active Directory 林，以在兩個(gè)林之間提供無(wú)縫的身份驗證和授權體驗。林信任是兩個(gè)林的根域之間的單一信任鏈接；它可以在每個(gè)林中的所有域之間建立起一種可傳遞的信任關(guān)系。例如，如果“林 A”信任“林 B”，則通過(guò)林信任，“林 A”中的所有域將信任“林 B”中的所有域。下圖說(shuō)明了這一概念： 圖 6.6.Windows Server 2003 林信任關(guān)系 但是，林信任不會(huì )跨林傳遞。也就是說(shuō)，如果“林 A”信任“林 B”，而“林 B”又信任“林 C”，“林 A”并不會(huì )自動(dòng)信任“林 C”。 有關(guān)使用和配置 Windows Server 2003 跨林信任的更多信息，請參見(jiàn) Microsoft TechNet 上的在 Windows Server 2003 中規劃和實(shí)施聯(lián)合林 頁(yè)面。 使用林信任 林信任使 Windows Server 2003 中的聯(lián)合林概念成為可能。前面提過(guò)，林信任允許在兩個(gè)林中所有域之間傳遞信任關(guān)系；這種信任建立在兩個(gè)林的根域之間。 林信任既可以是單向信任，也可以是雙向信任。在上圖中，“林 A”和“林 B”之間的信任關(guān)系是雙向的。因此，“林 A”中的用戶(hù)可以針對“林 B”中的資源進(jìn)行驗證，“林 B”中的用戶(hù)也可以針對“林 A”中的資源進(jìn)行驗證。除身份驗證外，林信任還支持授權，從而每個(gè)林中的資源所有者都可以將主體從另一個(gè)林添加到 DACL 和組中，或者根據這些組創(chuàng )建角色。 使用影子帳戶(hù)代替信任 有時(shí)，一些安全性要求會(huì )禁止在林之間使用 Windows 信任機制。在這種情況下，可以在一個(gè)目錄中創(chuàng )建影子帳戶(hù)來(lái)鏡像另一個(gè)目錄中的帳戶(hù)。影子帳戶(hù)通常只從源領(lǐng)域鏡像特定應用程序或方案所需要的身份信息。為滿(mǎn)足安全性要求，特別敏感的身份屬性將不會(huì )出現。敏感信息包括身份的社會(huì )保障號或用戶(hù)密碼等信息。 盡管使用員工影子帳戶(hù)這一概念可能不太直觀(guān)，但卻非常適合這樣一種情況：組織使用 Active Directory 的 Intranet 實(shí)例進(jìn)行身份驗證，又想具有可供員工使用的 Extranet。在 Extranet 上驗證員工身份有以下兩個(gè)選擇： | ? | 使用從外圍網(wǎng)絡(luò )（也稱(chēng) DMZ、外圍安全區或屏蔽子網(wǎng)）到 Intranet 的林或域信任。 | | ? | 在外圍網(wǎng)絡(luò )中創(chuàng )建影子帳戶(hù)。 | 第一種方式需要開(kāi)放許多端口，從而可以允許一條路徑通過(guò)分隔外圍網(wǎng)絡(luò )和 Intranet 的防火墻。這種方式適用于許多組織，但還有一些組織需要將其外圍網(wǎng)絡(luò )和 Intranet 之間徹底隔離。 對于需要嚴格網(wǎng)絡(luò )隔離的組織而言，使用影子帳戶(hù)可能是最好的選擇。微軟建議通過(guò)自動(dòng)化機制來(lái)創(chuàng )建影子帳戶(hù)，例如 Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1) 中提供的機制。在某些允許安全性較低的服務(wù)器（比如 Extranet 中的服務(wù)器）采用非密碼身份驗證機制的場(chǎng)合，影子帳戶(hù)甚至能提高網(wǎng)絡(luò )安全性。這種示例包括基于安全套接字層 (SSL) 3.0 的身份驗證和傳輸層安全 (TLS) 1.0 客戶(hù)端證書(shū)身份驗證，或一次性密碼身份驗證機制（例如 RSA Security Inc. 的 SecurID 雙因素身份驗證產(chǎn)品）。 公鑰基礎結構信任 公鑰基礎結構 (PKI) 是由以下要素組成的一套體系：數字證書(shū)、認證機構 (CA) ，以及其他通過(guò)公鑰加密來(lái)檢查和驗證電子事務(wù)中每一方有效性的注冊機構。但要檢查和驗證有效性，每一方都必須信任證書(shū)的頒發(fā)者（通常是 CA）。 對于 Windows 用戶(hù)、計算機和服務(wù)，如果受信任的根認證機構存儲中存在根證書(shū)副本以及有效的認證路徑，則會(huì )建立證書(shū)頒發(fā)機構中的信任。有效的認證路徑表示認證路徑中沒(méi)有任何被吊銷(xiāo)或已過(guò)期的證書(shū)。認證路徑中包含頒發(fā)給認證層次結構中每個(gè) CA（從從屬 CA 至根 CA）的所有證書(shū)。 例如，對于根 CA，認證路徑就是一個(gè)證書(shū)，是其自簽名的證書(shū)。對于從屬 CA，它僅位于認證層次結構中根 CA 之下，其認證路徑使用兩個(gè)證書(shū)：其自己的證書(shū)和根 CA 證書(shū)。 若要為計算機和計算機托管的應用程序建立 PKI 信任，最簡(jiǎn)單直觀(guān)的方法是將根證書(shū)導入受信任根認證機構存儲中。例如，如果 Contoso Pharmaceuticals（一個(gè)虛構的組織）的 Web 服務(wù)器將 Fabrikam Inc.（另一個(gè)虛構的組織）的根證書(shū) CA 安裝到根認證機構的存儲中，Contoso Web 服務(wù)器就會(huì )信任由 Fabrikam CA 所頒發(fā)的任何有效證書(shū)。但這一流程只是建立事務(wù)的信任部分，而不會(huì )在 Web 服務(wù)器上建立身份或上下文。若要創(chuàng )建從身份到上下文的映射，需要執行一些其他操作，例如將證書(shū)中的某些信息映射到 Active Directory 中的安全主體。 有關(guān)使用 Active Directory 證書(shū)映射功能進(jìn)行相互身份驗證的更多信息，請參見(jiàn) Microsoft Windows 2000 Server 網(wǎng)站上的循序漸進(jìn)指南：將證書(shū)映射到用戶(hù)帳戶(hù) 頁(yè)面。 雖然受信任根認證機構的存儲機制相當容易部署，但它無(wú)法滿(mǎn)足在建立兩個(gè)組織（如 Contoso 和 Fabrikam）間聯(lián)合信任這類(lèi)復雜場(chǎng)合下的安全性要求?？梢钥紤] Contoso 和 Fabrikam 用戶(hù)都可以提供有效證書(shū)來(lái)訪(fǎng)問(wèn) Contoso 網(wǎng)站這種方案。在這種情況下，外部 Active Directory 中將包含來(lái)自 Contoso 和 Fabrikam CA 的證書(shū)映射。 一種操作是建立基于證書(shū)主題的映射，例如：E=fred@fabrikam.com。這種方法的問(wèn)題是沒(méi)有綁定信任。未綁定的信任意味著(zhù) Contoso 愿意完全信任 Fabrikam，不會(huì )頒發(fā)主題為 E=fred@contoso.com 的證書(shū)，此處 fred@contoso.com 是 Contoso 組織中的用戶(hù)，而不是 Fabrikam 組織中的用戶(hù)。這種情況下，證書(shū)持有者可能會(huì )獲得對 Contoso 站點(diǎn)上敏感信息的訪(fǎng)問(wèn)權限。出現這個(gè)問(wèn)題并不是因為 PKI 信任本身存在不足，而是因為證書(shū)定義過(guò)于廣泛。解決這一問(wèn)題的辦法是建立可控性更高的 PKI 信任機制，使 Fabrikam 只能為 @fabrikam.com 域頒發(fā)證書(shū)，而不能為 @contoso.com 域頒發(fā)證書(shū)。 限定從屬 在 Windows 2000 網(wǎng)絡(luò )中，根本無(wú)法實(shí)現 CA 層次結構的真正交叉認證。唯一可替代的方法是定義信任特定 CA 和限制證書(shū)用途的證書(shū)信任列表 (CTL)。 Windows 2003 Server 中所引入的限定從屬是交叉認證 CA 層次結構的過(guò)程，此過(guò)程使用基本策略、命名和應用程序約束條件來(lái)限制從合作伙伴 CA 層次結構或同一組織內的輔助層次結構中接受的證書(shū)。通過(guò)限定從屬，CA 管理員可以明確地定義其組織信任合作伙伴 PKI 所頒發(fā)的證書(shū)。限定從屬還提供了根據策略原則在組織內劃分和控制證書(shū)頒發(fā)的方法。 限定從屬還允許在不同信任層次結構中的 CA 之間建立信任。這種類(lèi)型的信任關(guān)系還可稱(chēng)為交叉認證。通過(guò)這種信任關(guān)系，限定從屬不再限定于從屬 CA。使用一個(gè)層次結構中的從屬 CA 和另一個(gè)層次結構中的根 CA 可以在兩層次結構之間建立信任。 限定從屬允許在 PKI 中為域內部和域之間設置額外的信任條件，以擴展信任層次結構。通過(guò)限定從屬，信任層次結構中的每個(gè)限定從屬 CA 可以具有不同的規則，來(lái)控制其證書(shū)的頒發(fā)方式及使用方式。 有一個(gè)示例可以說(shuō)明如何使用信任條件來(lái)解決先前所提到的證書(shū)定義過(guò)廣的問(wèn)題，即在 Contoso 和 Fabrikam 層次結構之間建立交叉認證時(shí)使用命名空間約束條件。通過(guò)這種方式，Contoso 將只接受指定了 fabrikam.com 域的 Fabrikam CA 證書(shū)。 有關(guān)限定從屬的更多信息，請參見(jiàn) Microsoft TechNet 上的限定從屬 頁(yè)面。 實(shí)施聯(lián)合 聯(lián)合身份管理是基于標準的技術(shù)和信息技術(shù)，支持跨組織和平臺邊界的分布式標識、身份驗證及授權。聯(lián)合系統可以跨組織邊界進(jìn)行互操作，并可以將使用不同技術(shù)、身份存儲、安全方法和編程模型的過(guò)程連接起來(lái)。在聯(lián)合系統內部，組織需要通過(guò)一種標準化的安全方式來(lái)表示為受信任的合作伙伴和客戶(hù)所提供的服務(wù)。組織還必須實(shí)施商業(yè)運作所仰賴(lài)的策略，如： | ? | 信任哪些其他組織和用戶(hù)。 | | ? | 接受哪些類(lèi)型的憑證和請求。 | | ? | 實(shí)施哪些隱私策略。 | Microsoft Windows Server 2003 R2 引入了 Active Directory 聯(lián)合服務(wù) (ADFS)，使得組織可以安全共享用戶(hù)的身份信息。ADFS 提供了 Web 單一登錄 (SSO) 技術(shù)，以在單一聯(lián)機會(huì )話(huà)的生命期內實(shí)現用戶(hù)對多個(gè) Web 應用程序的驗證。ADFS 通過(guò)跨不同安全和企業(yè)邊界安全共享數字身份、權利或“聲明”的方式實(shí)現了此目標。 ADFS 與 Active Directory 以及 Active Directory 應用程序模式 (ADAM)} 一起工作。具體來(lái)說(shuō)，ADFS 使用 Active Directory 的企業(yè)級部署或 ADAM 的實(shí)例進(jìn)行工作。在使用 Active Directory 時(shí)，ADFS 可以利用 Active Directory 中強大的身份驗證技術(shù)，包括 Kerberos、X.509 數字證書(shū)和智能卡。在使用 ADAM 時(shí)，ADFS 使用輕型目錄訪(fǎng)問(wèn)協(xié)議 (LDAP) 綁定來(lái)驗證用戶(hù)身份。 ADFS 支持在 Internet 上應用分布式身份驗證和授權。ADFS 可集成到組織和部門(mén)的現有訪(fǎng)問(wèn)管理解決方案中，將組織所使用的條款轉換為聯(lián)合時(shí)商定的聲明。ADFS 可以創(chuàng )建、保護和檢查在組織之間移動(dòng)的聲明。同時(shí)它還可以審核、監視組織和部門(mén)間的活動(dòng)，以確保事務(wù)處理的安全。 有關(guān) ADFS 的更多信息，請參見(jiàn) Microsoft.com 上的 Windows Server 2003 R2 中的 Active Directory 聯(lián)合服務(wù) (ADFS) 概述 。 安全審核 審核提供了監視訪(fǎng)問(wèn)管理事件和身份對象更改的方法。安全審核通常用于監視問(wèn)題或違反安全性事件的出現。Windows 安全事件日志等技術(shù)、Windows 管理接口 (WMI) 以及 MOM 2005 SP1 等產(chǎn)品都可以提供全面的安全審核和報告。 審核目錄服務(wù) Active Directory 和 ADAM 與 Windows Server 2003 審核完全集成。Windows 安全事件日志反映目錄對象和屬性的更改，也反映目錄對象和屬性的授權策略、架構和組策略。您可精確控制如何配置基于成功、失敗或嘗試操作的可審核事件。 審核身份驗證 上述 Windows 身份驗證機制都會(huì )在 Windows 安全事件日志中生成審核?？梢允褂媒M策略配置要生成的審核（例如身份驗證失敗或成功），也可以手動(dòng)配置每一臺服務(wù)器。 Windows Server 2003 還通過(guò)根據身份驗證類(lèi)型對身份驗證進(jìn)行分類(lèi)，提供了對身份驗證事件的精確控制。例如，一種類(lèi)型的審核跟蹤控制臺登錄，而另一種類(lèi)型的審核則跟蹤網(wǎng)絡(luò )資源的身份驗證嘗試。身份驗證審核始終可以跟蹤到唯一的安全主體。 一旦啟用了用戶(hù)對身份存儲的驗證，下一步驟即是需要指定用戶(hù)可以訪(fǎng)問(wèn)的資源。授權是控制資源訪(fǎng)問(wèn)權限的過(guò)程。 審核授權 Windows Server 平臺完全支持授權操作的審核。對于模擬/ACL 模型，“NT 對象管理器”根據審核配置來(lái)報告對資源訪(fǎng)問(wèn)的審核。此項配置可以通過(guò)組策略來(lái)實(shí)施，也可以在每臺服務(wù)器上手動(dòng)實(shí)施。系統生成這些審核之后，審核事件將會(huì )出現在“系統安全事件日志”中。 審核配置功能非常精確，審核內容的指定也很方便，例如可以輕松指定僅審核文件的失敗訪(fǎng)問(wèn)嘗試。因為身份驗證和授權機制緊密地集成在一起，因此授權審核根據其唯一安全標識符 (SID) 來(lái)指定訪(fǎng)問(wèn)資源的安全主體。 “授權管理器”支持運行時(shí)審核和“授權管理器”策略更改審核。運行時(shí)審核使用失敗或成功的審核記錄來(lái)報告應用程序初始化、上下文創(chuàng )建與刪除和對象訪(fǎng)問(wèn)?！笆跈喙芾砥鳌辈呗愿膶徍丝梢詧蟾娌呗源鎯Φ娜魏巫兓?，包括對策略和策略定義的審核。 在單一安全領(lǐng)域或安全目錄林內的身份驗證和授權過(guò)程相對簡(jiǎn)單一些。然而，身份和訪(fǎng)問(wèn)管理往往需要面對鏈接兩種不同安全領(lǐng)域的要求，而這就需要在目錄服務(wù)之間或組織之間實(shí)現某種形式的信任。下一章將探討此項要求。 審核信任 Windows Server 2003 會(huì )詳細而充分地審核信任配置。您可以審核信任的創(chuàng )建、刪除和修改等事件。信任審核事件會(huì )顯示在“安全事件日志”中。
| 
