共用方式為

Windows 驗證中的認證程序

這個針對 IT 專業人員的參考主題說明 Windows 驗證處理身分驗證的方式。

Windows 身分驗證管理是作業系統從服務或使用者接收身分驗證，並將該資訊安全以備將來呈遞至驗證目標的程序。 在加入網域的電腦的情況下，驗證目標是網域控制者。 身分驗證中使用的身分驗證是數位檔案，可將使用者的身份與某種形式的真實性證明 (例如憑證、密碼或 PIN) 相關聯。

依預設，會透過 Winlogon 服務，針對本機電腦上的 Security Accounts Manager (SAM) 資料庫，或針對加入網域的電腦上的 Active Directory 驗證 Windows 身分驗證。 透過在登入使用者介面上的使用者輸入或透過應用程式程式設計介面 (API) 以程式設計方式收集身分驗證，以呈現給身分驗證目標。

本機安全資訊儲存在登錄檔的 HKEY_LOCAL_MACHINE\SECURITY 下。 儲存的資訊包括原則設定、預設安全值和帳戶資訊，例如快取的登入身分驗證。 SAM 資料庫的副本也儲存在此處，但有寫入保護。

下圖顯示必要的元件，以及身分驗證透過系統以驗證使用者或程序成功登錄的路徑。

此圖顯示必要元件，以及認證通過系統進行的路徑，以驗證成功登入的用戶或進程。

下表說明在登錄時管理驗證程序身分驗證的每個元件。

所有系統的驗證元件

元件 描述
使用者登入 Winlogon.exe 是負責管理安全使用者互動的可執行檔。 Winlogon 服務會透過透過 Secur32.dll 將安全桌面 (登入 UI) 上使用者動作所收集的身分驗證傳遞給 Local Security Authority (LSA)，來啟動 Windows 作業系統的登錄程序。
應用程式登錄 不需要互動式登錄的應用程式或服務登錄。 大部分由使用者啟動的程序會使用 Secur32.dll 以使用者模式執行，而啟動時啟動的程序 (例如服務) 則使用 Ksecdd.sys 以核心模式執行。

如需有關使用者模式和核心模式的詳細資訊，請參閱本主題中的 Applications and User Mode 或 Services and Kernel Mode。
Secur32.dll 構成驗證程序基礎的多個驗證供應商。
Lsasrv.dll LSA 伺服器服務，可強制執行安全性原則並作為 LSA 的安全套件管理員。 LSA 包含 Negotiate 函式，該函式在確定會成功的協定後選擇 NTLM 或 Kerberos 協定。
Security Support Providers 一組供應商，可個別叫用一或多個驗證協定。 預設的供應商集合會隨每個 Windows 作業系統版本而變更，而且可以寫入自訂供應商。
Netlogon.dll Net Logon 服務執行的服務如下：

- 維護電腦與網域控制者之間的安全通道 (不要與 Schannel 混淆)。
- 透過安全通道將使用者身分驗證傳送到網域控制者，並傳回使用者的網域安全性識別碼 (SID) 和使用者權限。
- 在 Domain Name System (DNS) 中發佈服務資源記錄，並使用 DNS 將名稱解析為網域控制者的 Internet Protocol (IP) 位址。
- 根據遠端程式呼叫 (RPC)，實作同步處理主要網域控制者 (PDC) 和備份網域控制者 (BDC) 的複寫協定。
Samsrv.dll 儲存本機安全帳戶的 Security Accounts Manager (SAM) 會強制執行本機儲存的原則，並支援 API。
登錄 登錄檔包含 SAM 資料庫的副本、本機安全原則設定、預設安全值，以及只能由系統存取的帳戶資訊。

本主題包含下列幾節：

使用者登錄的身分驗證輸入

在 Windows Server 2008 和 Windows Vista 中，Graphical Identification 和 Authentication (GINA) 架構由身分驗證供應商模型所取代，允許可以透過使用登錄圖塊來列舉不同的登錄型別。 兩種模型說明如下。

Graphical Identification 和 Authentication 架構

Graphical Identification 和 Authentication (GINA) 架構適用於 Windows Server 2003、Microsoft Windows 2000 Server、Windows XP 和 Windows 2000 Professional 作業系統。 在這些系統中，每個互動式登錄工作階段都會建立 Winlogon 服務的個別執行個體。 GINA 架構載入到 Winlogon 使用的程序空間中，接收並處理身分驗證，並透過 LSALogonUser 對身份驗證介面進行呼叫。

工作階段 0 中執行互動式登錄的 Winlogon 執行個體。 工作階段 0 裝載系統服務及其他重要程序，包括 Local Security Authority (LSA) 程序。

下圖顯示 Windows Server 2003、Microsoft Windows 2000 Server、Windows XP 和 Microsoft Windows 2000 Professional 的身分驗證程序。

此圖顯示 Windows Server 2003、Microsoft Windows 2000 Server、Windows XP 和 Microsoft Windows 2000 Professional 的認證程式

身分驗證供應商架構

身分驗證供應商架構適用於本主題開頭的 Applies to 清單指定的版本中。 在這些系統中，身分驗證輸入架構透過使用身分驗證供應商變成一個可擴充的設計。 這些供應商由安全桌面上的不同登錄圖塊代表，這些圖塊允許任意數量的登錄方案，同一使用者的不同帳戶和不同的驗證方法，如密碼、智慧卡和生物測定法。

使用身分驗證供應商架構，Winlogon 一律會在收到安全注意順序事件後啟動 Logon UI。 Logon UI 會查詢每個身分驗證供應商，以取得該供應商設定為列舉的不同身分驗證型別的數目。 身分驗證供應商可選擇指定其中一個圖塊作為預設值。 所有供應商列舉其圖塊後，Logon UI 會將其顯示給使用者。 使用者會與圖塊互動，以提供其身分驗證。 Logon UI 會提交這些身分驗證以進行驗證。

身分驗證供應商不是強制機制。 它們用於收集和序列化身份驗證。 Local Security Authority 和驗證套件會強制執行安全性。

身分驗證供應商已在電腦上註冊，並負責下列項目：

  • 描述驗證所需的身分驗證資訊。

  • 處理與外部驗證授權單位的通訊和邏輯。

  • 用於互動式和網路登錄的封裝身分驗證。

互動式登錄和網路登錄的封裝身分驗證包括序列化程序。 透過序列化身分驗證，可在登入 UI 上顯示多個登入圖塊。 因此，您的組織可以使用自訂身分驗證供應商來控制登錄顯示，例如使用者、登錄的目標系統、網路預先登錄存取權以及工作站鎖定/解除鎖定原則。 多個身分驗證供應商可以共存於同一台電腦上。

單一登入 (SSO) 供應商可以做為標準身分驗證供應商或 Pre-Logon-Access Provider。

每個版本的 Windows 都包含一個預設身分驗證供應商和一個預設 Pre-Logon-Access Provider (PLAP)，也稱為 SSO 供應商。 SSO 供應商允許使用者在登錄本機電腦前連線到網路。 實作此供應商時，供應商不會列舉 Logon UI 上的圖塊。

SSO 供應商適用於下列情況：

  • 網路驗證和電腦登入由不同的身分驗證供應商處理。 此案例的變體包括：

    • 使用者在登錄電腦前可以選擇連線到網路，例如連線到虛擬專用網路 (VPN)，但不需要進行此連線。

    • 需要網路驗證才能擷取本機電腦上互動式驗證期間所使用的資訊。

    • 多重網路驗證後接著進行其他其中一個案例。 例如，使用者向 Internet 服務供應商 (ISP) 進行身份驗證，向 VPN 進行身份驗證，然後使用他們的使用者帳戶身分驗證在本機登錄。

    • 已停用快取的身分驗證，而且需要透過 VPN 的 Remote Access Services 連線，在本機登錄驗證使用者。

    • 網域使用者沒有設定加入網域電腦上的本機帳戶，而且必須在完成互動式登錄之前，透過 VPN 連線建立 Remote Access Services 連線。

  • 網路驗證和電腦登錄由相同的身分驗證供應商處理。 在此情況下，使用者必須先連線到網路，才能登錄電腦。

登錄圖塊列舉

身分驗證供應商會在下列執行個體中列舉登入圖塊：

  • 適用於本主題開頭的 Applies to 清單中指定的那些作業系統。

  • 身分驗證供應商會列舉工作站登入的圖塊。 身分驗證供應商一般會將身分驗證序列化至本機安全授權機關。 此程序會顯示每個使用者特定的圖塊，以及每個使用者的目標系統特定的圖塊。

  • 登錄與驗證架構可讓使用者使用身分驗證供應商列舉的圖塊來解除工作站的鎖定。 一般而言，目前登錄的使用者是預設的圖塊，但如果有一個以上的使用者登錄，則會顯示許多的圖塊。

  • 身分驗證供應商響應於使用者請求來列舉圖塊，以更改其密碼或其它私密資訊，例如 PIN。 一般而言，目前登錄的使用者是預設的圖塊；不過，如果有一個以上的使用者登錄，則會顯示許多的圖塊。

  • 身分驗證供應商會根據序列化身分驗證來列舉要在遠端電腦上進行驗證的圖塊。 Credential UI 使用的供應商執行個體與 Logon UI、Unlock Workstation 或 Change Password 不同。 因此，在 Credential UI 的執行個體之間，無法在供應商中維護狀態資訊。 此結構會為每個遠端電腦登錄產生一個圖塊 (假設身分驗證已正確序列化)。 此方案也用於 User Account Control (UAC)，可在允許可能影響電腦操作或可能影響電腦其他使用者的設定之前，提示使用者權限或管理員密碼，從而幫助防止對電腦進行未經授權的更改。

下圖顯示本主題開頭的 Applies To 清單中所指定作業系統的身分驗證程序。

此圖顯示本主題開頭的 [套用至] 列表中所指定作業系統的認證程式。

應用程式與服務登錄的身分驗證輸入

Windows 驗證旨在管理不需要使用者互動的應用程式或服務的身分驗證。 使用者模式中的應用程式會受到其可存取之系統資源的限制，而服務可不受限制地存取系統記憶體與外部裝置。

系統服務和傳輸級應用程式透過 Windows 中的 Security Support Provider Interface (SSPI) 存取 Security Support Provider (SSP)，SSPI 提供列舉系統上可用的安全套件、選擇套件以及使用該套件獲取已驗證連線的功能。

驗證客戶端/伺服器連線時：

  • 連線客戶端的應用程式會使用 SSPI InitializeSecurityContext (General)功能將身分驗證傳送到伺服器。

  • 連線伺服器端的AcceptSecurityContext (General)應用程式會以 SSPI 函式回應。

  • SSPI 函式和會InitializeSecurityContext (General)重複執行，直到交換所有必要AcceptSecurityContext (General)的驗證訊息，以成功驗證或失敗驗證。

  • 在連線經過驗證之後，伺服器上的 LSA 會使用來自客戶端的資訊來建立包含存取權杖的安全內容。

  • 然後，伺服器可以呼叫 SSPI 函式ImpersonateSecurityContext以將存取權杖附加到服務的模擬執行緒。

應用程式與使用者模式

在 Windows 中，使用者模式由兩個系統組成，這兩個系統能夠將 I/O 請求傳遞到相應的核心模式驅動程式：環境系統，執行為許多不同型別的作業系統編寫的應用程式；以及完整系統，代表環境系統執行特定於系統的功能。

該整合系統代表環境系統管理作業系統的特定功能，並且包括安全系統進程 (LSA)、工作站服務和伺服器服務。 安全系統進程處理安全權杖，基於資源權限授予或拒絕存取使用者帳戶的權限，處理登錄請求和發起登錄驗證，並確定作業系統需要稽核的系統資源。

應用程式可以在使用者模式中執行，其中應用程式可以作為任何主體執行，包括在 Local System (SYSTEM) 的安全內容中。 應用程式也可以以核心模式執行，應用程式可以在 Local System (SYSTEM) 的安全內容中執行。

SSPI 可以透過 Secur32.dll 模組取得，這是一個 API，用於取得整合式安全服務，以進行驗證、訊息完整性和訊息私密性。 它在應用層協定和安全協定之間提供一個抽象層。 因為不同的應用程式需要不同的識別或驗證使用者的方法，以及不同的資料加密方式，SSPI 提供存取包含不同驗證和加密功能的動態連結程式庫 (DLL) 的方法。 這些 DLL 稱為 Security Support Providers (SSP)。

受管理服務帳戶和虛擬帳戶在 Windows Server 2008 R2 和 Windows 7 中引入，以提供關鍵應用程式 (如 Microsoft SQL Server 和 Internet Information Services (IIS))，並隔離其自己的網域帳戶，同時無需管理員手動管理這些帳戶的服務主體名稱 (SPN) 和身分驗證。 如需有關這些功能及其在驗證中角色的詳細資訊，請參閱 Windows 7 和 Windows Server 2008 R2 和 Group Managed Service Accounts Overview。

服務與核心模式

儘管大多數 Windows 應用程式在啟動它們的使用者的安全背景內容中執行，但服務並非如此。 許多 Windows 服務，例如網路和列印服務，都是由服務控制者在使用者啟動電腦時啟動的。 這些服務可能會以 Local Services 或 Local System 的形式執行，並且可能會在最後一位使用者登出後繼續執行。

注意

服務通常在稱為 Local System (SYSTEM)、Network Service 或 Local Service 的安全內容中執行。 Windows Server 2008 R2 引進以受管理服務帳戶執行的服務，它們是網域主體。

在啟動服務之前，服務控制者會使用為服務指定的帳戶登入，然後提供服務的身分驗證以供 LSA 驗證。 Windows 服務實作一個程式化介面，服務控制者管理員可以使用該介面來控制服務。 Windows 服務可以在系統啟動時自動啟動，也可以使用服務控制程式手動啟動。 例如，當 Windows 客戶端電腦加入網域時，電腦上的訊息服務會連線到網域控制者，並開啟安全通道至該網域控制者。 若要取得已驗證的連線，服務必須具有遠端電腦的 Local Security Authority (LSA) 信任的身分驗證。 當與網路中的其他電腦通訊時，LSA 會使用本機電腦網域帳戶的身分驗證，與在 Local System 與 Network Service 安全性內容中執行的所有其他服務一樣。 本機電腦上的服務以 SYSTEM 身分執行，因此不需要提供身分驗證給 LSA。

檔案 Ksecdd.sys 管理和加密這些身份驗證，並使用本地過程呼叫到 LSA。 檔案型別為 DRV (驅動程式)，稱為核心模式 Security Support Provider (SSP)，在本主題開頭的 Applies To 清單指定的版本中，與 FIPS 140-2 Level 1 相容。

核心模式可以完全存取電腦的硬體和系統資源。 核心模式會停止使用者模式服務與應用程式存取不應存取的重要作業系統區域。

本機安全性授權

Local Security Authority (LSA) 是受保護的系統程序，可驗證使用者並登錄本機電腦。 此外，LSA 維護著關於電腦上本機安全所有方面的資訊 (這些方面統稱為本機安全原則)，並且提供各種服務，用於名稱和安全識別符號 (SID) 之間的轉換。 安全性系統程序 Local Security Authority Server Service (LSASS) 會追蹤在電腦系統上有效的安全性原則與帳戶。

LSA 會根據下列兩個實體中的以下簽發使用者帳戶來驗證使用者的身分：

  • Local Security Authority。 LSA 可以檢查位於相同電腦上的 Security Accounts Manager (SAM) 資料庫，以驗證使用者資訊。 任何工作站或成員伺服器都可以儲存本機使用者帳戶與本機群組資訊。 但是，這些帳戶只能用於存取該工作站或電腦。

  • 本機網域或受信任網域的安全性授權。 LSA 聯絡簽發該帳戶的實體，並要求驗證該帳戶有效並且請求源自該帳戶持有者。

本機安全性授權子系統服務 (LSASS) 會代表使用中 Windows 工作階段的使用者，將認證儲存在記憶體中。 儲存的身分驗證可讓使用者順利存取網路資源，例如檔案共用、Exchange Server 信箱和 SharePoint 網站，而不需要重新輸入每個遠端服務的身分驗證。

LSASS 可以使用多種形式儲存認證，包括：

  • 可回復的已加密純文字

  • Kerberos 工單 (工單授權工單 (TGT)、服務工單)

  • NT 雜湊

  • LAN Manager (LM) 雜湊

如果使用者使用智慧卡登入 Windows，LSASS 不會儲存明文密碼，但會儲存帳戶對應的 NT 雜湊值，以及智慧卡的明文 PIN。 如果為互動式登入所需的智慧卡啟用帳戶屬性，則會為帳戶自動產生隨機 NT 雜湊值，而不是原始的密碼雜湊。 設定屬性時自動產生的密碼雜湊不會變更。

如果使用者使用與 LAN Manager (LM) 雜湊相容的密碼登入 Windows 電腦，則此驗證器會出現在記憶體中。

您不能停用在記憶體中純文字認證的儲存體，即使需要它們的認證提供者已被停用。

儲存的身分驗證會直接與上次重新啟動後啟動且尚未關閉的 Local Security Authority Subsystem Service (LSASS) 登錄工作階段產生關聯。 例如，當使用者執行下列其中一項動作時，會建立具有儲存的 LSA 認證的 LSA 工作階段：

  • 登錄電腦上的本機工作階段或 Remote Desktop Protocol (RDP) 工作階段

  • 使用 RunAs 選項執行工作

  • 在電腦上執行使用中的 Windows 服務

  • 執行排程的工作或批次工作

  • 使用遠端系統管理工具在本機電腦上執行工作

在某些情況下，LSA 機密 (只能由 SYSTEM 帳戶程序存取的機密資料段) 儲存在硬碟驅動器上。 部分這些密碼是重新開機後必須保留的認證，它們是以加密形式儲存在硬碟上。 儲存為 LSA 密碼的認證可能包括：

  • 電腦的 Active Directory Domain Services (AD DS) 帳戶的帳戶密碼

  • 電腦上設定的 Windows 服務的帳戶密碼

  • 已設定排程工作的帳戶密碼

  • IIS 應用程式集區及網站的帳戶密碼

  • Microsoft 帳戶的密碼

在 Windows 8.1 中引入的客戶端作業系統為 LSA 提供額外的保護，以防止非受保護進程讀取記憶體和插入代碼。 此保護可提高 LSA 儲存和管理的身分驗證的安全性。

有關這些附加保護的詳細資訊，請參閱 Configuring Additional LSA Protection。

快取的身分驗證和驗證

驗證機制取決於登錄時證明資料的呈現。 但是，當電腦與網域控制者中斷連線，且使用者正在呈現網域身分驗證時，Windows 會在驗證機制中使用快取的身分驗證程序。

每次使用者登錄網域時，Windows 都會快取提供的身分驗證，並將其儲存在作業系統登入中的安全性登錄區中。

使用快取的身分驗證，使用者可以登錄網域成員，而不必連線到該網域中的網域控制者。

身分驗證儲存與驗證

使用一組身分驗證來存取不同資源並不總是理想的。 例如，管理員在存取遠端伺服器時可能希望使用管理而不是使用者身分驗證。 同樣地，如果使用者存取外部資源 (例如銀行帳戶)，則他或她只能使用不同於其網域身分驗證的身分驗證。 下列各節說明目前的 Windows 作業系統版本與 Windows Vista 與 Windows XP 作業系統之間的身分驗證管理差異。

遠端登錄身分驗證程序

Remote Desktop Protocol (RDP) 使用 Windows 8 中引入的 Remote Desktop Client，管理連線到遠端電腦的使用者身分驗證。 明文的身分驗證會傳送至目標主機，而主機會嘗試執行驗證程序，如果成功，則會將使用者連線至允許的資源。 RDP 不會將身分驗證儲存在客戶端，但使用者的網域身分驗證儲存在 LSASS中 。

Windows Server 2012 R2 和 Windows 8.1 中引入的 Restricted Admin 模式為遠端登錄方案提供額外的安全性。 這種 Remote Desktop 模式會導致客戶端應用程式使用 NT 單向功能 (NTOWF) 執行網路登錄質詢回應，或在驗證遠端主機時使用 Kerberos 服務工單。 在驗證管理員之後，管理員在 LSASS 中沒有各自的帳戶身分驗證，因為未提供給遠端主機。 相反，管理員擁有該工作階段的電腦帳戶身分驗證。 管理員身分驗證未提供給遠端主機，因此動作是以電腦帳戶執行。 資源也僅限於電腦帳戶，管理員不能用自己的帳戶存取資源。

自動重新啟動登入身分驗證程序

當使用者登入 Windows 8.1 裝置時，LSA 會將使用者身分驗證儲存在只有 LSASS.exe 可以存取的加密記憶體中。 當 Windows Update 在沒有使用者在場的情況下啟動自動重新啟動時，會使用這些身分驗證來設定使用者的 Autologon。

重新啟動時，使用者會自動透過 Autologon 機制登入，然後電腦會額外鎖定，以保護使用者的工作階段。 鎖定是透過 Winlogon 啟動，而身分驗證管理則由 LSA 完成。 透過自動登入及鎖定使用者在主控台上的工作階段，使用者鎖定畫面應用程式會重新啟動並可供使用。

如需有關 ARSO 的詳細資訊，請參閱 Winlogon Automatic Restart Sign-On (ARSO)。

在 Windows Vista 和 Windows XP 中儲存的使用者名稱和密碼

在 Windows Server 2008、Windows Server 2003、Windows Vista 和 Windows XP 中，Control Panel 中的 Stored User Names 和 Passwords，簡化多組登錄身分驗證的管理和使用，這些身分驗證包括智慧卡和 Windows Live 身分驗證 (現在稱為 Microsoft 帳戶) 使用的 X.509 憑證。 身分驗證是使用者設定檔的一部分，會儲存到需要為止。 這個動作可以透過確保如果某個密碼遭到破壞，不會危及所有安全性，來增加每個資源的安全性。

使用者登入並嘗試存取其他受密碼保護的資源 (例如伺服器上的共用) 之後，如果使用者的預設登錄身分驗證不足以取得存取權，則會 Stored User Names 和 Passwords。 如果已將具有正確登入資訊的替代身分驗證儲存在 Stored User Names 和 Passwords 中，則會使用這些身分驗證來取得存取權。 否則，系統會提示使用者提供新的身分驗證，這些身分驗證可在稍後登錄工作階段或後續工作階段期間儲存以供重複使用。

適用以下限制：

  • 如果 Stored User Names 和 Passwords 包含特定資源的無效或不正確身分驗證，則會拒絕存取該資源，且不會顯示 Stored User Names 和 Passwords 對話方塊。

  • Stored User Names 和 Passwords 只會儲存 NTLM、Kerberos 協定、Microsoft 帳戶 (以前稱為 Windows Live ID) 及 Secure Sockets Layer (SSL) 驗證的身分驗證。 某些 Internet Explorer 版本會維護自己的快取記憶體以進行基本驗證。

這些身分驗證會成為 \Documents 和 Settings\Username\Application Data\Microsoft\Credentials 目錄中使用者本機設定檔的加密部分。 因此，如果使用者的網路原則支援 Roaming User Profiles，則這些身分驗證可與使用者一起漫遊。 但是，如果使用者在兩個不同的電腦上擁有 Stored User Names 和 Passwords 的副本，並更改與這些電腦之一上的資源相關的身分驗證，則所做的更改不會傳播到第二台電腦上的 Stored User Names 和 Password。

Windows Vault and Credential Manager

Credential Manager 在 Windows Server 2008 R2 和 Windows 7 中作為 Control Panel 功能引入，用來儲存和管理使用者名稱和密碼。 Credential Manager 可讓使用者將與其他系統和網站相關的身分驗證儲存在安全的 Windows Vault 中。 某些 Internet Explorer 版本會使用此功能來驗證網站。

使用認證管理員的認證管理是由本機電腦上的使用者所控制的。 使用者可以儲存和存放支援的瀏覽器及 Windows 應用程式的認證，便於在需要登入這些資源時使用。 身分驗證會儲存在電腦上使用者設定檔下的特殊加密資料夾中。 支援此功能的應用程式 (透過使用 Credential Manager API)，例如網路瀏覽器和應用程式，可在登錄程序期間將正確的身分驗證呈現給其他電腦和網站。

當網站、應用程式或其他電腦透過 NTLM 或 Kerberos 協定要求驗證時，會出現一個對話方塊，您可以在其中選取 Update Default Credentials 或 Save Password 核取方塊。 此對話方塊可讓使用者在本機儲存身分驗證，由支援 Credential Manager API 的應用程式產生。 如果使用者選取 Save Password 核取方塊，Credential Manager 會追蹤使用者的使用者名稱、密碼以及正在使用的驗證服務的相關資訊。

下次使用服務時，Credential Manager 會自動提供儲存在 Windows Vault 中的身分驗證。 如果不接受這個認證，則會提示使用者輸入正確的存取資訊。 如果以新身分驗證授予存取權，Credential Manager 會以新身分驗證覆寫先前的身分驗證，然後將新身分驗證儲存在 Windows Vault 中。

Security Accounts Manager 資料庫

Security Accounts Manager (SAM) 是一個資料庫，用來儲存本機使用者帳戶和群組。 它存在於每個 Windows 作業系統中；不過，當電腦加入網域時，Active Directory 會管理 Active Directory 網域中的網域帳戶。

例如，即使沒有使用者登錄，執行 Windows 作業系統的客戶端電腦也會透過與網域控制者通訊來參與網路網域。 若要起始通訊，電腦必須在網域中擁有作用中的帳戶。 在接受來自電腦的通訊之前，域控制器上的 LSA 會驗證電腦的身份，然後建構電腦的安全背景內容文，就像對人類安全主體所做的那樣。 此安全性內容定義特定電腦上的使用者或服務，或網路上的使用者、服務或電腦的身分與能力。 例如，安全背景內容包含的存取權杖定義可存取的資源 (如檔案共用或印表機) 以及該主體 (使用者、電腦或服務在該資源上) 可執行的操作 (如讀取、寫入或修改)。

使用者或電腦的安全性背景內容會因電腦的不同而不同，例如當使用者登錄伺服器或除使用者自己的主要工作站以外的工作站時。 它也可能因工作階段的不同而有所不同，例如管理員修改使用者的權利和權限時。 此外，當使用者或電腦獨立作業、在網路中或作為 Active Directory 網域的一部分時，安全背景內容通常不同。

本機網域和受信任的網域

當兩個域之間存在信任時，每個域的身分驗證機制依賴於來自另一個域的身分驗證的有效性。 信任協助提供資源網域 (信任網域) 中共用資源的控制存取，方法是驗證傳入的驗證要求是否來自受信任的授權單位 (受信任的網域)。 透過這種方式，信任充當橋樑，使得只有經過驗證的身分驗證請求才能在網域間傳遞。

特定信任如何傳遞驗證要求取決於其配置方式。 信任關係可以是單向的，透過從受信任的域提供存取信任域中的資源權限，或者是雙向的，透過從每個域提供存取另一個域中的資源權限。 信任也可以是具非傳遞性 (在這種情況下，信任只存在於兩個信任夥伴域之間)，也可以是具傳遞性的 (在這種情況下，信任自動擴展到任何夥伴信任的任何其他網域)。

如需有關驗證網域與樹系信任關係的資訊，請參閱 Delegated Authentication 和 Trust Relationships。

Windows 驗證中的憑證

公用金鑰基礎設施 (PKI) 是軟體、加密技術、程序和服務的組合，使組織能夠保護其通訊和業務交易。 PKI 保護通訊和商業交易安全的能力基於在身分驗證使用者和受信任資源之間交換數位憑證。

數位憑證是一種電子文件，其中包含有關其所屬實體、其頒發者、唯一序號或其他唯一識別、簽發和到期日期的資訊以及數位指紋。

驗證是判斷遠端主機是否可信任的程序。 要建立可信度，遠端主機必須提供可接受的驗證憑證。

遠端主機透過從憑證授權單位 (CA) 取得憑證來建立其可信度。 CA 可以擁有來自更高權威的身分驗證，從而建立信任鏈。 要確定憑證是否可信，應用程式必須確定根 CA 的身分，然後確定是否可信。

類似地，遠端主機或本地電腦必須確定使用者或應用程式提供的憑證是否可信。 使用者透過 LSA 和 SSPI 呈現的憑證會評估本機電腦上本機登錄、網路上或透過 Active Directory 中的憑證存放區在網域上的真實性。

為了產生憑證，驗證資料會透過雜湊演算法 (例如 Secure Hash Algorithm 1 (SHA1)) 來產生訊息摘要。 然後，使用傳送者的私人金鑰對訊息摘要進行數位簽章，以證明消息摘要是由傳送者產生的。

注意

SHA1 是 Windows 7 和 Windows Vista 中的預設值，但在 Windows 8 中變更為 SHA2。

智慧卡驗證

智慧卡技術是基於憑證的驗證範例。 使用智慧卡登錄網路提供強大的驗證形式，因為當使用者驗證網域時，會使用密碼學為基礎的識別與擁有證明。 Active Directory Certificate Services (AD CS) 透過為每個智慧卡發行登錄憑證，提供密碼編譯型識別。

有關智慧卡身份驗證的資訊，請參閱 Windows Smart Card Technical Reference。

虛擬智慧卡技術在 Windows 8 中引入。 它將智慧卡的憑證儲存在 PC 中，然後使用裝置的防篡改 Trusted Platform Module (TPM) 安全晶片對其進行保護。 這樣，PC 實際上就變成智慧卡，該智慧卡必須接收使用者的 PIN 才能被驗證。

遠端與無線驗證

遠端和無線網路驗證是另一種使用憑證進行驗證的技術。 Internet Authentication Service (IAS) 和虛擬專用網路伺服器使用 Extensible Authentication Protocol-Transport Level Security (EAP-TLS)、Protected Extensible Authentication Protocol (PEAP) 或 Internet Protocol 安全性 (IPsec) 為多種型別的網路存取執行基於證書的身份驗證，包括虛擬專用網路 (VPN) 和無線連線。

如需網路中憑證式驗證的相關資訊，請參閱 Network 存取驗證與憑證。

另請參閱

Windows 驗證概念