Windows Hello 企業版、硬體金鑰和單一登錄

如果您在微軟環境中管理身份，您可能聽說過… Windows Hello、Windows Hello 企業版、按鍵 硬件 和 SSO但面對如此多的縮寫、信任類型和要求，很容易讓人迷失方向。此外，在與傳統 Active Directory 混合部署的情況下，了解 WHfB 與簡單的 PIN 碼或生物識別登入相比究竟有哪些優勢，對於專案的順利進行至關重要，否則可能會變成一場持續不斷的噩夢。

本文將詳細介紹它的工作原理。 Windows Hello 企業版 (WHfB) 中，硬體金鑰扮演什麼角色？如何實現單一登入 (SSO)？ 以及它與面向家庭用戶的「普通」Windows Hello有何不同。我們將探討其內部階段（設備註冊、配置、金鑰同步、憑證和身份驗證）、部署模型（純雲端、混合和本地部署）、信任類型、PKI要求、許可、實際部署挑戰，以及所有這些如何與FIDO2和無密碼安全等現代方法相契合。

Windows Hello 與 Windows Hello 企業版：究竟有哪些變化？

Windows Hello（簡單來說）是指使用 PIN 碼或生物辨識技術登入的使用者體驗。 Windows Hello 適用於 Windows 設備，既可用於家庭環境，也可用於專業環境。而 Windows Hello 企業版 (WHfB) 則是企業級擴展，它整合了強大的身份驗證功能，並與 Active Directory 和 Microsoft Entra ID 無縫對接。

兩種方法你都可以使用 支援PIN碼、指紋或臉部辨識 TPM的 登入計算機。您甚至可以使用傳統的本地域進行身份驗證。最大的差異在於 WHfB 建立和管理 企業級加密憑證與使用者和裝置關聯的金鑰對或證書，由策略管理，可用於本機和雲端資源的 SSO。

雖然「普通」的 Windows Hello 功能基本上僅限於 在該裝置上，用便捷的手勢代替密碼WHfB 產生身分提供者（AD、Microsoft Entra ID 或 AD FS）識別、儲存和使用的強憑證，用於頒發存取權杖和強制執行安全性。 條件存取、嚴格的KDC驗證、PRT、雲端Kerberos 以及其他進階控制功能。

合乎邏輯的問題是：如果我已經擁有已加入網域、使用 Intune 管理、具有 TPM 和生物識別功能，並透過密碼雜湊同步實現雲端 SSO 的設備， 添加 WHfB 究竟能為我帶來什麼好處？ 答案在於金鑰的建構和驗證方式、設備的連接方式，以及將這種安全性擴展到整個生態系統（而不僅僅是本地登入）的能力。

基本架構：Windows Hello 企業版各階段

WHfB是一個分散式系統，它依賴多個元件： 設備、TPM、身分提供者、PKI、目錄同步和 SSO 機制為了便於理解而不迷失方向，將其操作分為五個按時間順序實施的階段會很有幫助。

1. 設備註冊

拼圖的第一塊是 設備向身分提供者 (IdP) 註冊此步驟可讓您將裝置與目錄中的身分關聯起來，並使其在使用者登入時自動進行身份驗證。

在純雲端環境或混合式環境中， 身分識別提供者 (IdP) 是 Microsoft 輸入 ID 裝置向其裝置註冊服務註冊（已加入 Microsoft Entra、混合加入或已註冊）。在純本機場景中，身分提供者 (IdP) 通常是 AD FS 及其企業設備註冊服務.

註冊完成後，身分提供者 (IdP) 將分配團隊 用於建立設備目錄信任的唯一標識 在連續的身份驗證中。此記錄依「裝置加入類型」分類，該類型決定裝置是加入本機網域、Entra ID、混合模式，或僅註冊為個人裝置。

2. 設定：建立 Windows Hello 容器

設備註冊完成後，階段就開始了。 為企業設定 Windows Hello 憑證這裡會建立所謂的 Windows Hello 容器，該容器會將該電腦上使用者的所有加密材料進行邏輯分組。

典型的採購流程遵循以下主要步驟，始終遵循… 初始身份驗證 使用弱密碼（使用者名稱和密碼）：

• 使用者在身分提供者使用多因素身份驗證 (MFA) 進行身份驗證。 （Microsoft 輸入 MFA 或其他相容方法，或在本機環境中的 AD FS 中使用 MFA 轉接器）。
• 克服了第二個因素後，您需要配置一個 PIN碼，以及（如果相容硬體可用）生物辨識手勢 （腳印、臉、虹膜）
• 確認 PIN 碼後，Windows 會生成 Windows Hello 容器 針對該團隊的那個帳戶。
• 在該容器內， 加密金鑰對（公鑰和私鑰）如果存在 TPM，則與 TPM 連接；如果 TPM 不存在，則透過軟體進行保護。
• La 私鑰保留在裝置上，無法匯出。並受到 TPM 和 PIN/生物辨識保護器的保護。
• La 公鑰已在身分識別提供者 (IdP) 中註冊。 它與使用者物件關聯：在 Microsoft 登入 ID 中，它會被寫入使用者；在聯合本機場景中，AD FS 會將其傳輸到 Active Directory。

容器內還包含一個 管理密鑰這對於諸如重置 PIN 碼之類的場景非常有用；在配備 TPM 的裝置上，也會儲存包含 TPM 憑證的資料區塊。只有當使用者執行特定操作（PIN 碼或生物識別）時，所有內容才會解鎖，而這種初始的多因素身份驗證 (MFA) 組合會在用戶、裝置和身分提供者 (IdP) 之間建立信任。

3. 容器內的金鑰：身份驗證和使用者識別符

在 Windows Hello 容器中，我們發現了幾種不同類型的金鑰，它們各自扮演著不同的角色。 採用基於PIN碼或生物辨識技術的加密保護:

• 身份驗證金鑰註冊過程中產生的一對非對稱密鑰，必須始終使用 PIN 碼或生物辨識手勢解鎖。 PIN 碼更改後，其他材料將以此為基礎進行回收。
• 使用者標識符鍵身分金鑰可以是對稱的，也可以是不對稱的，這取決於身分提供者 (IdP) 和金鑰模型（金鑰或憑證）。它們用於對發送至身分提供者的請求和令牌進行簽署或加密。在企業環境中，它們通常以非對稱金鑰對的形式生成，其中公鑰已註冊到身分提供者。

用戶標識符密鑰可透過以下兩種主要方式取得： 與企業公鑰基礎設施 (PKI) 相關聯，用於頒發憑證 （例如，對於 VPN（例如，基於 RDP 或憑證的 Kerberos 驗證）或在沒有 PKI 的場景中由 IdP 直接產生（純金鑰模型）。

同樣的基礎設施允許使用 Windows Hello 作為 FIDO2/WebAuthn 驗證器 在相容的應用程式和網站中，網站可以在 Windows Hello 容器內建立 FIDO 憑證；使用者在後續造訪時，可以使用 PIN 碼或生物辨識資訊進行身份驗證，而無需透露密碼。

4. 混合環境中的密鑰同步

在共存的混合架構中 Microsoft 登入 ID 和 Active Directory僅僅在雲端註冊密鑰是不夠的。配置完成後，必須將 WHfB 公鑰同步到本機目錄才能啟用。 針對本機資源的身份驗證和單一登入.

在這些情況下，Microsoft Entra Connect Sync 會處理下列事項： 將公鑰複製到 msDS-KeyCredentialLink 屬性 Active Directory 中的使用者物件。這種同步至關重要，以便網域控制器能夠使用儲存在 TPM 中的私鑰驗證裝置產生的簽章。

5. 證書登記（僅在必要時）

在某些模型中（例如 證書信託除了金鑰之外，組織還需要向使用者頒發身份驗證憑證。在這種情況下，將啟動一個額外的階段。 證書登記.

註冊公鑰後，客戶端產生一個 證書請求 這會將請求傳送到憑證註冊機構 (CRA)，該機構通常整合在共同部署的 AD FS 中。 CRA 使用企業 PKI 驗證請求， 它會頒發一個儲存在 Hello 容器內的憑證。可重複用於仍依賴憑證的本機資源的身份驗證。

身份驗證、私鑰和單一登入：它們如何協同工作

註冊和配置階段完成後，使用者的日常生活變得非常簡單： 透過手勢（PIN碼或生物辨識）「釋放」裝置上的私鑰真正有趣的是幕後發生的事情。

當使用者解鎖電腦時，Windows 會使用 WHfB 憑證的私鑰部分。 對傳送給身分提供者 (IdP) 的資料進行加密簽名此過程使用儲存在使用者物件中的公鑰驗證簽名。由於 PIN 碼和私鑰始終保留在設備內部，因此該流程能夠有效抵禦網路釣魚和傳統的憑證竊取攻擊。

在 Microsoft 輸入 ID 場景中，完成驗證後會得到一個結果。 主刷新令牌 (PRT)包含使用者和裝置資訊的 JSON Web Token。它是雲端應用程式單一登入 (SSO) 的基礎，並且與 Microsoft Kerberos 或金鑰同步結合使用，也可用於本機資源。

如果沒有 PRT，即使使用者擁有有效的 WHfB 憑證， 我會失去單一登入功能。 這樣一來，用戶將被迫在每個應用程式中持續進行身份驗證。因此，無論是基於設備的還是基於風險的條件存取策略，通常都會考慮個人身份驗證工具（PRT）的存在及其有效性。

對於 Active Directory，當使用金鑰或憑證信任時，WHfB 會充當… 虛擬智慧卡使用者對來自 KDC 的 nonce 或質詢進行簽名，網域控制器驗證憑證或金鑰，並頒發 Kerberos TGT 票證，從而實現與 Kerberos 整合的本地服務的 SSO。

內部安全：生物辨識、TPM 和攻擊防護

WHfB 的支柱之一是… 生物辨識數據永遠不會離開設備感測器產生的模板儲存在本地。 數據庫 使用每個資料庫唯一的金鑰對（例如，在路徑 C:\WINDOWS\System32\WinBioDatabase）進行加密，並使用 CBC 模式下的 AES 和 SHA-256 作為雜湊函數進行保護。

這意味著即使攻擊者獲得了這些檔案的存取權限， 我無法重建使用者的臉部或指紋影像。它們也不能用於其他設備。此外，每個感測器都擁有獨立的儲存空間，從而降低了生物辨識模板被集中盜竊的可能性。

Windows Hello 企業版 PIN 碼的安全性也比傳統密碼好。它無需透過網路傳輸，而是在本地進行驗證，並且由 TPM 強制執行安全措施。 由於錯誤嘗試次數過多而被阻止這使得暴力破解或字典攻擊失效。即使有人竊取了PIN碼，也只能在該特定設備上使用，因為憑證與硬體綁定。

面對現代威脅（如何判斷電子郵件是否為釣魚郵件（密碼重複使用、大規模憑證竊盜），WHfB 依賴 裝置關聯公鑰加密這種設計從根本上避免了共享密鑰的洩漏。這完全符合 NIST 800-63B 等法規的標準和建議，以及零信任安全模型。

部署模式：雲端、混合式和本機部署

WHfB在拓樸結構上具有彈性，但這種彈性也帶來了一定的複雜性。總的來說，我們可以討論三種以不同方式組合的部署模型。 Microsoft Entra ID、Active Directory、PKI 與聯合身分驗證.

純雲模式

在幾乎100%生活在其中的組織中 微軟365 以及其他SaaS服務，如果沒有相關的本地基礎設施，最簡單的模型是： 僅限雲端，且設備需連接至微軟。登入在這種情況下：

• 所有使用者和設備都位於 微軟Entra ID.
• 設備和密鑰註冊直接在雲端完成。
• 無需企業級 PKI 也沒有網域控制器證書。
• 應用程式的 SSO 是基於 PRT 和 Microsoft Entra 令牌。

對於雲端優先型公司而言，這是最直接的選擇，因為 基礎架構成本低，部署相對簡單當本地資源不可用或極少時，這是理想的選擇。

混合模型：最常見的情況

絕大多數公司都介於兩者之間： 歷史 Active Directory 與 Microsoft 登入 ID 同步WHfB 在這裡表現出色，但如果規劃不當，配置問題也最容易出現。

在混合環境中，識別資訊透過 Microsoft Entra Connect Sync 進行同步，並且存在多種可能的組合方式。 部署模型（混合）和信任類型（雲端 Kerberos、金鑰或憑證）其目標通常是提供：

• 雲端服務的單一登入 (的SharePoint 線上、Teams、OIDC/SAML 應用程式）。
• 透明地取得當地資源 （股份， 應用程序 Kerberos、VPN、RDP）。
• 在保留原有應用程式的同時，逐步淘汰密碼。

混合場景下的主要信任類型有：

• 雲端 KerberosMicrosoft Entra Kerberos 無需額外的公鑰基礎架構 (PKI) 即可為 Active Directory 頒發 TGT。這是最先進、最簡單的混合模型，因為它利用了現有的 FIDO2 基礎架構，並且無需將公鑰與 Active Directory 同步。
• 關鍵信託使用者使用裝置綁定金鑰向 Active Directory 進行驗證；網域控制站則需要特定的憑證。網域控制器需要 PKI，但使用者憑證則不需要。
• 憑證置信度使用者驗證憑證用於取得 Kerberos TGT。這需要完整的 PKI、作為 CRA 的 AD FS 以及更複雜的配置。

選擇合適的信託類型至關重要： 沒有哪一種本質上是「更安全」的。然而，它們在成本、複雜性和基礎設施要求方面存在差異。如果用戶端和伺服器的 Windows 版本符合最低要求，那麼對於新部署而言，依賴雲端 Kerberos 通常是最佳選擇。

純局部模型

對於受到嚴格監管限製或幾乎沒有採用雲端技術的組織而言，他們可能會選擇 WHfB 部署。 100% 本機部署，受 Active Directory 和 AD FS 支持在這個模型中：

• 設備註冊由管理員管理 AD FS.
• 身份驗證可以是基於金鑰的，也可以是基於憑證的，但始終需要安全機制的支援。 企業級公鑰基礎設施.
• MFA 選項包括 AD FS 適配器或 Azure MFA 伺服器（已是傳統方案）等整合到本地的解決方案。

這種方法可以帶來 對身份驗證資料擁有完全控制權然而，這需要大量的維護工作（PKI、AD FS、發布非網域加入電腦可存取的 CRL 等），並非所有組織都願意長期承擔這些工作。

可存取的 PKI、網域控制器憑證和 CRL

在依賴憑證的模型中（無論是使用者憑證、網域控制器憑證或兩者兼有），公鑰基礎架構 (PKI) 成為信任的核心。 WHfB 要求 對KDC進行嚴格驗證 當加入 Microsoft Enter 的裝置向本機網域進行驗證時。

實際上，這意味著網域控制器憑證必須滿足若干技術條件： 由受信任的根 CA 基於 Kerberos 驗證模板，使用「KDC 驗證」EKU、正確的 DNS 名稱、RSA 2048 和 SHA-256 作為簽章演算法，為裝置頒發的憑證。以及其他要求。

此外，該設備必須能夠 檢查證書吊銷情況這就是CRL的經典問題所在：僅加入Microsoft Entra的裝置如果尚未通過身份驗證，則無法讀取Active Directory中的LDAP路徑，因此必須發佈CRL分發點。 無需身份驗證即可存取的 HTTP URL.

這包括準備 Web 伺服器（例如 IIS）、建立虛擬目錄（cdp）以及調整權限。 NTFS 並從共享資源中停用 存儲 在離線快取中，配置 CA 以將 CRL 發佈到該共用資源並透過 HTTP 公開。完成後，您需要… 續訂網域控制器證書 納入新的 CDP，並確保將企業根憑證部署到加入 Microsoft Entra 的裝置（例如，使用 Intune 和「受信任的憑證」設定檔）。

目錄同步、多因素身份驗證和設備配置

最終用戶對 Windows Hello 企業版的使用體驗很大程度取決於 如何整合目錄同步、多因素身份驗證和策略配置.

在混合部署中，Microsoft Entra Connect Sync 不僅可以同步帳戶，還可以同步其他內容。 關鍵屬性，例如 msDS-KeyCredentialLink其中包含 AD 身份驗證所需的 WHfB 公鑰。在具有 Azure MFA 伺服器的本機環境中，同步功能用於將使用者匯入 MFA 伺服器，然後 MFA 伺服器會查詢雲端服務以進行驗證。

關於多因素身份驗證，企業有以下幾種選擇： 適用於雲端或混合場景的 Microsoft Entra MFAEntra ID 中集成了外部身份驗證方法，可透過外部身份驗證或聯合身份驗證集成，本地環境中還支援用於 AD FS 的第三方 MFA 適配器。聯合域中的 FederatedIdpMfaBehavior 標誌決定 Entra ID 是否接受、要求或忽略聯合身分提供者 (IdP) 執行的 MFA，這對於 WHfB 配置的正常運作至關重要。

可以透過以下方式在設備上進行 WHfB 配置： 群組策略 (GPO) 或透過 MDM 實現的 CSP （例如 Intune）。在現代組織中，通常會啟用自動 WHfB 註冊、強制首次登入時進行 MFA、定義 PIN 碼複雜度策略，並控制接受哪些生物辨識方法（僅限經過認證的感測器、紅外線攝影機等）。

同時，復原經驗也至關重要： 自助式 PIN 碼重置、FIDO2 鑰匙等替代方法，以及 BitLocker 加密 在設備遺失或被盜時保護靜態資料。

許可證、系統要求和實際限制

常見的誤解之一是，你總是需要使用 WHfB。 Microsoft 輸入 ID P1 或 P2實際上，WHfB 的核心功能在免費的 Entra ID 層級中即可使用，無需高級許可證即可啟用無密碼配置所需的多因素身份驗證，但自動 MDM 註冊、高級條件存取或延遲設備寫入等功能確實需要更高的層級。

就作業系統而言，幾乎所有現代Windows客戶端版本都支援WHfB，但是… 對雲端 Kerberos 的信任需要滿足一定的最低要求。 （例如，安裝了某些修補程式或特定版本的 Windows 10 21H2） 窗戶11在伺服器端，任何受支援的 Windows Server 版本通常都可以充當網域控制器，儘管雲端的 Kerberos 部分需要網域控制站上的特定版本和更新。

除了技術層面之外，還存在一些非常實際的挑戰：共享設備的問題 WHfB 是針對特定裝置和使用者的，因此通常適用。；沒有 TPM 2.0 或沒有生物辨識感測器的硬體；或更新舊設備、部署 PKI 和升級 2012 年資料中心的成本使得短期內全面採用 WHfB 不具吸引力的環境。

在某些情況下，合理的路徑包括 將 WHfB 與其他無密碼因素結合使用 （FIDO2 金鑰、智慧卡、電話認證）可覆蓋共用工作站、非 Windows 平台或高度行動用戶，從而使 WHfB 成為主要身份驗證器。 手提 與Entra或混合型公司有關聯的企業。

從整體來看，Windows Hello 企業版提供的遠不止「一個漂亮的 PIN 碼」：它還引入了 硬體級非對稱憑證、嚴格的金鑰分發中心 (KDC) 驗證、與 Microsoft Entra ID 和 Active Directory 的深度集成，以及強大的安全單一登入 (SSO) 框架 無論是在雲端還是本地部署，WHfB 都能發揮作用。然而，與基本的 Windows Hello 相比，它的真正價值取決於您的起點：在擁有更新的 PKI 和資料中心的現代雲端優先或混合環境中，安全性和管理方面的飛躍顯然超過了投入的精力；而在基礎設施薄弱且沒有現代化計劃的非常老舊的域中，先升級硬體、PKI 和存取控制，然後再充分發揮潛力，然後再充分發揮潛力的潛力，然後再充分發揮潛力，然後再充分發揮 WHfB 的潛力，然後再充分發揮潛力。