Windows Hello for Business の既知の展開に関する問題

  • [アーティクル]
  • 適用対象:
    ✅ Windows 11, ✅ Windows 10

この記事の内容は、Windows Hello for Business の既知の展開の問題のトラブルシューティングに役立ちます。

Microsoft Entra 参加デバイスの PIN リセットが失敗し 、そのページを今すぐ開くことができない エラー

Microsoft Entra 参加済みデバイスでの PIN リセットでは、 Web サインイン と呼ばれるフローを使用して、ロック以上のユーザーを認証します。 Web サインインでは、特定のドメインへのナビゲーションのみが許可されます。 Web サインインが許可されていないドメインに移動しようとすると、エラー メッセージが表示されたページが表示されます。 このページは現在開いていません。

PIN リセットが許可されているドメインの問題を特定する

ユーザーは、PIN 資格情報プロバイダーの [PIN を 忘れた 場合] リンクを使用して、ロック画面から PIN リセット フローを起動できます。 リンクを選択すると、Microsoft Entra 参加デバイスでの PIN エクスペリエンスの全画面表示 UI が起動します。 通常、UI には認証ページが表示されます。ここで、ユーザーは Microsoft Entra 資格情報を使用して認証を行い、MFA を完了します。

フェデレーション環境では、AD FS または Microsoft 以外の ID プロバイダーにルーティングするように認証を構成できます。 PIN リセット フローが起動され、フェデレーション ID プロバイダー サーバー ページに移動しようとすると、失敗し、サーバー ページのドメインが許可リストに含まれていない場合は、 そのページを今すぐ開くことができない というエラーが表示されます。

Azure US Government クラウドの顧客である場合、PIN リセットでは、既定の許可リストに含まれていないドメインへの移動も試行されます。 結果は、 現在そのページを開くことができないというメッセージです。

PIN リセットが許可されているドメインの問題を解決する

このエラーを解決するには、 ConfigureWebSignInAllowedUrls ポリシーを使用して、PIN リセットで許可されるドメインの一覧を構成できます。 ポリシーを構成する方法の詳細については、「 Microsoft Entra 参加済みデバイスでフェデレーション ID プロバイダーの許可 URL を構成する」を参照してください。

ユーザーの公開キーの削除が原因でハイブリッド キー信頼サインインが破損しました

適用対象:

  • ハイブリッド キー信頼のデプロイ
  • Windows Server 2016、ビルド 14393.3930 から 14393.4048
  • Windows Server 2019、ビルド 17763.1457 から 17763.1613

Windows Server 2016 および Windows Server 2019 の特定のビルドを実行しているドメイン コントローラーを使用したハイブリッド キー信頼展開では、サインイン後にユーザーの Windows Hello for Business キーが削除されます。 後続のサインインは、次の Microsoft Entra Connect 差分同期サイクル中にユーザーのキーが同期されるまで失敗します。

ユーザー公開キーの削除に関する問題を特定する

ユーザーがハイブリッド キー信頼環境で Windows Hello for Business 資格情報をプロビジョニングした後、キーは Microsoft Entra Connect 同期サイクル中に Microsoft Entra ID から Active Directory に同期する必要があります。 ユーザーの公開キーは、ユーザー オブジェクトの msDS-KeyCredentialLink 属性に書き込まれます。

ユーザーの Windows Hello for Business キーが同期される前に、Windows Hello for Business でのサインインが失敗し、エラー メッセージ [その] オプションは一時的に使用できません。ここでは、別の方法を使用してサインインしてください。 キーが正常に同期されると、ユーザーは PIN または登録済みの生体認証を使用してサインインしてロックを解除できます。

問題がある環境では、Windows Hello for Business での最初のサインインとプロビジョニングが完了すると、次のサインイン試行は失敗します。 ドメイン コントローラーが複数のビルドを実行している環境では、一部のユーザーがこの問題の影響を受ける可能性があり、その後のサインイン試行が異なるドメイン コントローラーに送信される可能性があります。 その結果、断続的なサインイン エラーが発生します。

最初のサインイン試行後、ユーザーの Windows Hello for Business 公開キーが msDS-KeyCredentialLink attributeから削除されます。 削除を確認するには、サインインの前後にユーザーの msDS-KeyCredentialLink 属性に対してクエリを実行します。 Get-ADUser を使用して AD のmsDS-KeyCredentialLinkに対してクエリを実行し、-Properties パラメーターにmsds-keycredentiallinkを指定できます。

ユーザー公開キーの削除に関する問題を解決する

この問題を解決するには、Windows Server 2016 および 2019 ドメイン コントローラーを最新のパッチで更新します。 Windows Server 2016 の場合、動作はビルド 14393.4104 (KB4593226) 以降で修正されています。 Windows Server 2019 の場合、動作はビルド 17763.1637 (KB4592440) で修正されています。

Microsoft Entra は、キー信頼と Microsoft 証明機関以外 (CA) を使用してオンプレミス リソースへのデバイス アクセスに参加しました

適用対象:

  • Microsoft Entra 参加済みのキー信頼デプロイ
  • ドメイン コントローラー証明書を発行する Microsoft 以外の証明機関 (CA)

Windows Hello for Business では、多くの操作にスマート カード ベースの認証が使用されます。 この種類の認証には、証明書の発行に Microsoft 以外の CA を使用する場合に特別なガイドラインがあります。その一部はドメイン コントローラーに適用されます。 すべての Windows Hello for Business 展開の種類にこれらの構成が必要なわけではありません。 Microsoft Entra 参加済みデバイスからオンプレミス リソースにアクセスするには、Microsoft 以外の CA を使用してドメイン コントローラー証明書を発行する場合に特別な構成が必要です。

詳細については、「 Microsoft 以外の証明機関でスマート カード サインインを有効にするためのガイドライン」を参照してください。

Microsoft CA 以外のオンプレミス リソース アクセスの問題を特定する

この問題は、クライアントからのネットワーク トレースまたは Kerberos ログを使用して特定できます。 ネットワーク トレースでは、ユーザーがリソースにアクセスしようとすると、クライアントは TGS_REQ 要求を送信できません。 クライアントでは、 Application and Services/Microsoft/Windows/Security-Kerberos/Operationalの下の Kerberos 操作イベント ログで確認できます。 ログは既定で無効になっています。 この場合のエラー イベントには、次の情報が含まれます。

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 for Business での認証が失敗し、エラー メッセージが表示されます。 このオプションは一時的に使用できません。ここでは、別の方法を使用してサインインしてください。

このエラーは、Windows Hello for Business がプロビジョニングされた後、ユーザーのキーが Microsoft Entra ID から Active Directory に同期される前に、キー信頼展開の Microsoft Entra ハイブリッド参加済みデバイスで表示されます。 ユーザーのキーが Microsoft Entra ID から同期されておらず、AD のユーザー オブジェクトの msDS-keycredentiallink 属性が NGC 用に設定されている場合は、エラーが発生する可能性があります。

障害の別のインジケーターは、ネットワーク トレースを使用して識別できます。 キー信頼サインイン イベントのネットワーク トレースをキャプチャすると、エラー KDC_ERR_CLIENT_NAME_MISMATCHで失敗した Kerberos がトレースに表示されます。

Server 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 for Business が AD FS を使用して証明書を登録するための要件です。 クライアントは、認証が成功するまで Windows Hello for Business プロビジョニングをブロックします。

AD FS 2019 登録に関する問題を使用して証明書の信頼を特定する

前提条件のチェックが成功すると、Windows Hello for Business のプロビジョニング エクスペリエンスが起動します。 provisioningAdmin チェックの結果は、 Microsoft-Windows-User デバイス登録のイベント ログで確認できます。 デバイス認証が成功しないためにプロビジョニングがブロックされた場合、ユーザーがエンタープライズ STS に対して正常に認証されたことを示すイベント ID 362 がログに記録されます。いいえ。

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 のイベント ログにイベント ID 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」と入力し、[ 適用] > [OK] を選択します。

  4. 管理者として PowerShell を起動します。

  5. ClientRoleIdentifier パラメーターが "38aa3b87-a06d-4817-b275-7a316988d93b" と等しいアプリケーション権限の ObjectIdentifier を取得します。

    (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 for Business をプロビジョニングするように求められます。