共用方式為

Windows Hello 企業版已知部署問題

本文的內容是協助針對 Windows Hello 企業版的已知部署問題進行疑難解答。

Microsoft加入裝置上的 PIN 重設失敗， 因為目前無法開啟該頁面 錯誤

Microsoft加入 Entra 的裝置上重設 PIN 會使用稱為 Web 登 入的流程來驗證上述鎖定的使用者。 Web 登入僅允許導覽至特定網域。 如果 Web 登入嘗試流覽至不允許的網域，則會顯示含有錯誤訊息 的頁面：我們目前無法開啟該頁面。

識別 PIN 重設允許的網域問題

使用者可以使用在 PIN 認證提供者中 忘記 PIN 連結，從鎖定畫面啟動 PIN 重設流程。 選取連結會在 Microsoft Entra join 裝置上啟動 PIN 體驗的全螢幕 UI。 一般而言，UI 會顯示驗證頁面，使用者會在其中使用 Microsoft Entra 認證進行驗證並完成 MFA。

在同盟環境中，驗證可能會設定為路由傳送至 AD FS 或非Microsoft識別提供者。 如果 PIN 重設流程已啟動，並嘗試流覽至同盟識別提供者伺服器頁面，則會失敗，並顯示 [如果伺服器頁面的網域未包含在允許清單中， 目前無法開啟該頁面 ] 錯誤。

如果您是 Azure US Gov 雲端的客戶，PIN 重設也會嘗試瀏覽至預設允許清單中未包含的網域。 結果會出現訊息 ：我們目前無法開啟該頁面。

解決 PIN 重設允許的網域問題

若要解決此錯誤，您可以使用 ConfigureWebSignInAllowedUrls 原則來設定 PIN 重設的允許網域清單。 如需如何設定原則的詳細資訊，請參閱在已 加入 Entra 的裝置上設定同盟識別提供者的允許 URL Microsoft。

混合式金鑰信任登入因用戶公鑰刪除而中斷

適用於：

  • 混合式金鑰信任部署
  • Windows Server 2016 組建 14393.3930 至 14393.4048
  • Windows Server 2019 組建 17763.1457 至 17763.1613

在執行特定 Windows Server 2016 和 Windows Server 2019 組建之域控制器的混合式密鑰信任部署中，使用者的 Windows Hello 企業版密鑰會在使用者登入後刪除。 後續的登入將會失敗，直到使用者的密鑰在下一個Microsoft Entra Connect 差異同步處理週期期間同步處理。

識別使用者公鑰刪除問題

在使用者於混合式密鑰信任環境中佈建 Windows Hello 企業版認證之後，金鑰必須在 Microsoft Entra Connect 同步處理週期期間，從 Microsoft Entra ID 同步至 Active Directory。 使用者的公鑰會寫入使用者 msDS-KeyCredentialLink 物件的屬性。

在使用者的 Windows Hello 企業版金鑰同步處理之前，使用 Windows Hello 企業版登入失敗，並出現錯誤訊息 ：該選項暫時無法使用。目前，請使用不同的方法來登入。 成功同步金鑰之後，用戶可以使用其 PIN 或已註冊的生物特徵辨識技術登入並解除鎖定。

在發生問題的環境中，第一次使用 Windows Hello 企業版登入並布建完成之後，下一次登入嘗試會失敗。 在域控制器混合執行組建的環境中，某些使用者可能會受到此問題的影響，而後續的登入嘗試可能會傳送至不同的域控制器。 結果為間歇性登入失敗。

在初始登入嘗試之後，使用者的 Windows Hello 企業版公鑰會從 msDS-KeyCredentialLink attribute中刪除。 您可以在登入前後查詢使用者的 msDS-KeyCredentialLink 屬性，以確認刪除。 您可以使用 Get-ADUser 並指定 msds-keycredentiallink 參數，msDS-KeyCredentialLink在 AD 中-Properties查詢 。

解決使用者公鑰刪除問題

若要解決此問題，請使用最新的修補程式更新 Windows Server 2016 和 2019 域控制器。 針對 Windows Server 2016，在組建 14393.4104 (KB4593226 ) 和更新版本中已修正此行為。 針對 Windows Server 2019，在組建 17763.1637 (KB4592440) 中 已修正此行為。

使用密鑰信任和非Microsoft證書頒發機構單位 (CA) ，Microsoft加入 Entra 的裝置存取內部部署資源

適用於：

  • Microsoft已加入 Entra 的金鑰信任部署
  • 發行域控制器憑證 (CA) 非Microsoft證書頒發機構單位

Windows Hello 企業版針對許多作業使用智慧卡型驗證。 使用非Microsoft CA 發行憑證時，這種類型的驗證具有特殊指導方針，其中有些適用於域控制器。 並非所有 Windows Hello 企業版部署類型都需要這些設定。 使用非Microsoft CA 發行域控制器憑證時，從已加入 Microsoft 裝置存取內部部署資源需要特殊設定。

如需詳細資訊，請參閱 使用非Microsoft證書頒發機構單位來啟用智慧卡登入的指導方針。

識別非Microsoft CA 的內部部署資源存取問題

您可以使用來自客戶端的網路追蹤或 Kerberos 記錄來識別問題。 在網路追蹤中，當用戶嘗試存取資源時，客戶端無法提出 TGS_REQ 要求。 在用戶端上，可以在下方的 Kerberos 作業事件記錄 Application and Services/Microsoft/Windows/Security-Kerberos/Operational檔中觀察到。 預設會停用記錄。 此案例失敗事件包含下列資訊：

Log Name:      Microsoft-Windows-Kerberos/Operational
Source:        Microsoft-Windows-Security-Kerberos
Event ID:      107
GUID:          {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1}
Task Category: None
Level:         Error
Keywords:
User:          SYSTEM
Description:

The Kerberos client received a KDC certificate that does not have a matched domain name.
Expected Domain Name: ad.contoso.com
Error Code: 0xC000006D

解決非Microsoft CA 的內部部署資源存取問題

若要解決此問題，必須更新域控制器憑證，讓憑證主體包含伺服器對象的目錄路徑， (辨別名稱) 。 範例主旨： CN=DC1,OU=Domain Controllers,DC=ad,DC=contoso,DC=com

或者，您可以 (域控制器憑證的 SAN) 設定主體別名，以包含伺服器物件的完整功能變數名稱和網域的 NETBIOS 名稱。 範例主體別名：

dns=dc1.ad.contoso.com
dns=ad.contoso.com
dns=ad

Windows Server 2019 的金鑰信任驗證中斷

適用於：

  • Windows Server 2019
  • 混合式金鑰信任部署
  • 內部部署金鑰信任部署

執行舊版 Windows Server 2019 的域控制器發生問題，導致密鑰信任驗證無法正常運作。 網路追蹤報告 KDC_ERR_CLIENT_NAME_MISMATCH。

識別 Windows Server 2019 金鑰信任驗證問題

在用戶端上，使用 Windows Hello 企業版進行驗證失敗，並出現錯誤訊息： 該選項暫時無法使用。目前，請使用不同的方法來登入。

布建 Windows Hello 企業版之後，但在將使用者的密鑰從 Microsoft Entra ID 同步至 Active Directory 之前，密鑰信任部署中的 Microsoft Entra 混合式聯結裝置上會顯示此錯誤。 如果使用者的密鑰未從 Microsoft Entra ID msDS-keycredentiallink 同步處理，且 AD 中用戶物件上的屬性已填入 NGC，則可能會發生錯誤。

您可以使用網路追蹤來識別失敗的另一個指標。 如果您擷取密鑰信任登入事件的網路追蹤，追蹤會顯示 Kerberos 失敗，錯誤 KDC_ERR_CLIENT_NAME_MISMATCH。

解決伺服器 2019 金鑰信任驗證問題

此問題已在 Windows Server 2019 組建 17763.316 (KB4487044) 中解決。 將所有 Windows Server 2019 域控制器升級至組建 17763.316 或更新版本，以解決此問題。

Windows Server 2019 上已中斷 AD FS 的憑證信任布建

適用於：

  • Windows Server 2019
  • 混合式憑證信任部署
  • 內部部署憑證信任部署

在 Windows Server 2019 上執行的 AD FS 無法完成裝置驗證，因為要求中的傳入範圍檢查無效。 對 AD FS 進行裝置驗證是 Windows Hello 企業版使用 AD FS 註冊憑證的必要條件。 用戶端會封鎖 Windows Hello 企業版布建，直到驗證成功為止。

識別 AD FS 2019 註冊問題的憑證信任

如果必要條件檢查成功，Windows Hello 企業版的布建體驗就會啟動。 provisioningAdmin 檢查的結果可在 Microsoft-Windows-User 裝置註冊下的事件記錄檔中取得。 如果因為裝置驗證失敗而封鎖布建，則會記錄事件標識碼 362 ，指出 使用者已成功向企業 STS 進行驗證：否。

Log Name:      Microsoft-Windows-User Device Registration/Admin
Source:        Microsoft-Windows-User Device Registration
Date:          <Date and time>
Event ID:      362
Task Category: None
Level:         Warning
Keywords:
User:          <User SID>
Computer:      <Computer name>
Description:
Windows Hello for Business provisioning will not be launched.
Device is Azure Active Directory-joined ( AADJ or DJ++ ): Yes
User has logged on with Azure Active Directory credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Not Tested
Enterprise user logon certificate template is : No ( 1 : StateNoPolicy )
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.

如果裝置最近加入網域，在進行裝置驗證之前可能會有延遲。 如果此必要條件檢查的失敗狀態持續存在，則可能表示 AD FS 設定有問題。

如果 AD FS 範圍問題存在，AD FS 伺服器上的事件記錄會指出來自客戶端的驗證失敗。 錯誤會記錄在 AD FS/Admin 下的事件記錄檔中，作為事件識別碼 1021，而 事件會指定用戶端禁止存取範圍為 的ugs資源http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope：

Log Name:      AD FS/Admin
Source:        AD FS
Date:          <Date and time>
Event ID:      1021
Task Category: None
Level:         Error
Keywords:      AD FS
User:          <ADFS service Account>
Computer:      <Date and time>
Description:
Encountered error during OAuth token request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client '38aa3b87-a06d-4817-b275-7a316988d93b' is forbidden to access the resource 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs'.
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
       at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

解決 AD FS 2019 註冊的憑證信任問題

Windows Server 版本 1903 和更新版本已修正此問題。 針對 Windows Server 2019，您可以手動新增 ugs 範圍來補救問題。

  1. 啟動AD FS管理主控台。 流覽至 [服務 > 範圍描述]。

  2. 以滑鼠右鍵選取 [範圍描述] ，然後選取 [ 新增範圍描述]。

  3. 在 [名稱] 底下輸入 ugs，然後選取 [ 套用 > 確定]。

  4. 以系統管理員身分啟動PowerShell。

  5. 取得應用程式許可權的 ObjectIdentifier，其 ClientRoleIdentifier 參數等於 “38aa3b87-a06d-4817-b275-7a316988d93b”：

    (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier

  6. 執行 命令 Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'。

  7. 重新啟動AD FS服務。

  8. 在用戶端上：重新啟動用戶端。 系統應該會提示使用者布建 Windows Hello 企業版。