次の方法で共有

Credential Guard を使用するときの考慮事項と既知の問題

Microsoft では、Credential Guard の展開に加えて、組織はパスワードから他の認証方法 (Windows Hello for Business、FIDO 2 セキュリティ キー、スマート カードなど) に移行することをお勧めします。

アップグレードに関する考慮事項

Credential Guard が進化し、セキュリティ機能が強化されるにつれて、Credential Guard を実行している新しいバージョンの Windows が以前の機能シナリオに影響する可能性があります。 たとえば、Credential Guard は、特定の資格情報またはコンポーネントの使用を制限して、脆弱性を悪用するマルウェアを阻止する可能性があります。

Credential Guard を使用するデバイスを更新する前に、organization内の運用シナリオを徹底的にテストすることをお勧めします。

Windows 11、バージョン 22H2、および Windows Server 2025 へのアップグレードでは、明示的に無効になっていない限り、既定で Credential Guard が有効になっています。

Wi-Fi と VPN に関する考慮事項

Credential Guard が有効になっている場合、シングル サインオン (SSO) に NTLM クラシック認証 (NTLMv1) を使用できなくなります。 これらのプロトコルを使用するために資格情報の入力が強制され、後で使用するために資格情報を保存することはできません。

MS-CHAPv2 に基づく WiFi エンドポイントと VPN エンドポイントを使用している場合、NTLMv1 と同様の攻撃を受けます。

WiFi と VPN 接続の場合は、MSCHAPv2 ベースの接続 (PEAP-MSCHAPv2 や EAP-MSCHAPv2 など) から証明書ベースの認証 (PEAP-TLS や EAP-TLS など) に移行することをお勧めします。

委任に関する考慮事項

Credential Guard が有効になっている場合、基になる認証スキームが Credential Guard と互換性がないか、指定された資格情報が必要であるため、特定の種類の ID 委任は使用できません。

Credential Guard が有効になっている場合、 資格情報セキュリティ サポート プロバイダー ("CredSSP") は保存された資格情報または SSO 資格情報を使用できなくなりましたが、クリアテキスト資格情報は引き続き指定できます。 CredSSP ベースの委任では、宛先マシンでクリアテキスト資格情報を指定する必要があり、Credential Guard が有効になり、クリアテキスト資格情報の開示がブロックされると SSO では機能しません。 資格情報の盗難のリスクがあるため、委任および一般に CredSSP の使用はお勧めしません。

Kerberos の制約のない委任と DES は、Credential Guard によってブロックされます。 制約のない委任 は推奨される方法ではありません。

代わりに、一般的な認証には Kerberos または ネゴシエート SSP が推奨されます。委任の場合は、 Kerberos の制約付き委任 と リソース ベースの Kerberos の制約付き委任 が推奨されます。 これらのメソッドは、全体的に資格情報のセキュリティを強化し、Credential Guard とも互換性があります。

Microsoft 以外のセキュリティ サポート プロバイダーに関する考慮事項

Microsoft 以外のセキュリティ サポート プロバイダー (SP と AP) の中には、Microsoft 以外の SSP が LSA からのパスワード ハッシュを要求できないため、Credential Guard と互換性がない場合があります。 ただし、ユーザーがログオンやパスワードを変更したときに SSP や AP がパスワードの通知を受け取ることもあります。 カスタム SP と AP 内での文書化されていない API の使用はサポートされていません。

CSP/AP のカスタム実装は Credential Guard を使用してテストすることをお勧めします。 文書化されていない動作やサポートされていない動作に依存する SSP や AP は失敗します。 たとえば、KerbQuerySupplementalCredentialsMessage API の使用はサポートされていません。 NTLM または Kerberos SSP をカスタム SSP/AP に置き換えないでください。

詳細については、「 セキュリティ パッケージの登録とインストールに関する制限事項」を参照してください。

保存された Windows 資格情報に関する考慮事項

Credential Manager を使用すると、次の 3 種類の資格情報を格納できます。

  • Windows 資格情報
  • 証明書ベースの資格情報
  • 汎用資格情報

Credential Manager に格納されているドメイン資格情報は、Credential Guard で保護されます。

Web サイトのサインインに使用するユーザー名やパスワードなどの一般的な資格情報は、アプリケーションでクリア テキスト パスワードが必要になるため、保護されません。 アプリケーションにパスワードのコピーが必要ない場合は、保護されている Windows 資格情報としてドメイン資格情報を保存できます。 Windows 資格情報は、ネットワーク上の他のコンピューターへの接続に使用されます。

資格情報マネージャーのための Credential Guard による保護には、次の考慮事項が適用されます。

  • リモート デスクトップ クライアントによって保存された Windows 資格情報をリモート ホストに送信することはできません。 保存された Windows 資格情報の使用が失敗し、ログオン試行に失敗したというエラー メッセージが表示される
  • Windows 資格情報を抽出するアプリケーションが失敗する
  • 資格情報ガードが有効になっている PC から資格情報をバックアップすると、Windows 資格情報を復元できません。 資格情報をバックアップする必要がある場合は、Credential Guard を有効にする前にバックアップする必要があります

TPM のクリアに関する考慮事項

仮想化ベースのセキュリティ (VBS) では、TPM を使用してそのキーを保護します。 TPM がクリアされると、VBS シークレットの暗号化に使用される TPM で保護されたキーが失われます。

Warning

TPM をクリアすると、VBS を使用してデータを保護するすべての機能の保護されたデータが失われます。

TPM がクリアされると、VBS を使用してデータを保護 するすべての 機能で、保護されたデータの暗号化を解除できなくなります。

その結果、Credential Guard は保護されたデータの暗号化を解除できなくなります。 VBS では、Credential Guard 用に TPM で保護された新しいキーを作成します。 Credential Guard は、新しいキーを使用して新しいデータを保護します。 ただし、以前に保護されていたデータは完全に失われます。

注

Credential Guard は、初期化中にキーを取得します。 データ損失は永続的なデータにのみ影響し、次回のシステム起動後に発生します。

資格情報マネージャーに保存された Windows 資格情報

Credential Manager は保存された Windows 資格情報の暗号化を解除できないため、削除されます。 アプリケーションでは、以前に保存された資格情報の入力が求められます。 再度保存すると、Windows 資格情報は Credential Guard で保護されます。

ドメイン参加済みデバイスの自動的にプロビジョニングされた公開キー

Active Directory ドメインに参加しているデバイスは、バインドされた公開キーを自動的にプロビジョニングします。公開キーの自動プロビジョニングの詳細については、「 ドメイン参加済みデバイス公開キー認証」を参照してください。

Credential Guard は保護された秘密キーの暗号化を解除できないため、Windows はドメインに参加しているコンピューターのパスワードを使用してドメインへの認証を行います。 他のポリシーがデプロイされていない限り、機能が失われるべきではありません。 公開キーのみを使用するようにデバイスが構成されている場合は、そのポリシーが無効になるまでパスワードで認証できません。 公開キーのみを使用するデバイスの構成について詳しくは、ドメインに参加しているデバイスの公開キー認証に関するページをご覧ください。

また、認証ポリシーを含むアクセス制御チェックでデバイスに KEY TRUST IDENTITY (S-1-18-4) または既知の SID を FRESH PUBLIC KEY IDENTITY (S-1-18-3) する必要がある場合、これらのアクセス チェックは失敗します。 認証ポリシーについて詳しくは、「認証ポリシーと認証ポリシー サイロ」をご覧ください。 既知の SID について詳しくは、[MS DTYP] セクション 2.4.2.4 既知の SID 構造体に関するページをご覧ください。

ドメインに参加しているデバイスでの DPAPI の中断

ドメインに参加しているデバイスで、DPAPI によって、ユーザーのドメインからドメイン コントローラーを使用してユーザーのキーを回復できます。 ドメインに参加しているデバイスにドメイン コントローラーへの接続がない場合、復旧はできません。

重要

ドメインに参加しているデバイスで TPM をクリアする場合のベスト プラクティスは、ドメイン コントローラーへの接続を持つネットワーク上にあることです。 これにより、DPAPI 関数を確実に使用でき、ユーザーに対して奇妙な動作は発生しません。

VPN の自動構成は、ユーザーの DPAPI によって保護されています。 VPN 構成が失われたため、ユーザーは VPN を使用してドメイン コントローラーに接続できない可能性があります。 ドメイン コントローラーに接続されていない、ドメインに参加しているデバイスで TPM をクリアする場合、次の点を効力する必要があります。

ドメイン コントローラーへの接続がない限り、TPM をクリアした後のドメイン参加済みデバイスでのドメイン ユーザー サインイン:

資格情報の種類 動作
証明書 (スマート カードまたは Windows Hello for Business) ユーザー DPAPI で保護されているすべてのデータは使用できず、ユーザー DPAPI はまったく機能しません。
パスワード TPM をクリアする前に証明書またはパスワードでサインインしたユーザーは、パスワードでサインインでき、ユーザー DPAPI は影響を受けません。

デバイスがドメイン コントローラーに接続されると、DPAPI は、ユーザーのキーを回復し、TPM をクリアする前に保護されていたデータの暗号化を解除できます。

Windows 情報保護への DPAPI 障害の影響

ユーザー DPAPI で保護されているデータが使用できない場合、ユーザーは Windows 情報保護によって保護されているすべての作業データにアクセスできません。 影響には、Outlook を起動できず、保護されたドキュメントを開くことができません。 DPAPI が動作している場合、新しく作成された作業データは保護され、アクセスすることができます。

対応策: ユーザーは、自分のデバイスをドメインに接続して、再起動するか、暗号化ファイル システム データ回復エージェント証明書を使用することにより、問題を解決できます。 暗号化ファイル システム データ回復エージェント証明書について詳しくは、「暗号化ファイル システム (EFS) データ回復エージェント (DRA) 証明書の作成と検証」をご覧ください。

既知の問題

Credential Guard は、特定の認証機能をブロックします。 Credential Guard が有効になっている場合、このような機能を必要とするアプリケーションは機能しません。

この記事では、Credential Guard が有効になっている場合の既知の問題について説明します。

Windows Server 2025 へのアップグレード時に Hyper-V によるライブ マイグレーションが中断される

CredSSP ベースの委任を使用するデバイスは、Windows Server 2025 にアップグレードした後、 Hyper-V でライブ マイグレーション を使用できなくなる可能性があります。 ライブ マイグレーションに依存するアプリケーションやサービス ( SCVMM など) も影響を受ける可能性があります。 CredSSP ベースの委任は、Windows Server 2022 以前のライブ マイグレーションの既定です。

説明
影響を受けるデバイス Credential Guard が有効になっているサーバーでは、この問題が発生する可能性があります。 Windows Server 2025 以降、Credential Guard は、ドメイン コントローラーではないすべてのドメイン参加サーバーで 既定で有効になっています 。 Credential Guard の既定の有効化は、アップグレード前 に事前にブロック できます。
問題の原因 Hyper-V を使用したライブ マイグレーションと、それに依存するアプリケーションとサービスは、特定の接続の一方または両端で Credential Guard を有効にして CredSSP を使用しようとすると、この問題の影響を受けます。 Credential Guard が有効になっている場合、CredSSP は、保存または SSO 資格情報ではなく、指定された資格情報のみを利用できます。

Live Migration のソース マシンが Credential Guard を有効にした委任に CredSSP を使用する場合、Live Migration は失敗します。 ほとんどの場合、移行先マシンでの Credential Guard の有効化状態は、Live Migration には影響しません。 また、任意のデバイスがソース マシンとして機能する可能性があるため、クラスター シナリオ (SCVMM など) でもライブ マイグレーションが失敗します。
解決方法 CredSSP 委任の代わりに、 Kerberos の制約付き委任と Resource-Based Kerberos の制約付き委任 が推奨されます。 これらの形式の委任は、Credential Guard との互換性に加えて、より優れた資格情報保護を提供します。 Hyper-V の管理者は、 これらの種類の委任 を手動で、または自動スクリプトを使用して構成できます。

Windows 11、バージョン 22H2、または Windows Server 2025 にアップグレードした後、ネットワーク サービスのシングル サインオンが中断する

パスワードベースの認証で安全でないプロトコルに依存する 802.1x ワイヤレスまたは有線ネットワーク、RDP、または VPN 接続を使用するデバイスは、SSO を使用してサインインできず、Credential Guard の実行中にすべての新しい Windows セッションで手動で再認証を強制されます。

説明
影響を受けるデバイス Credential Guard が有効になっているデバイスで問題が発生する可能性があります。 Windows 11 バージョン 22H2 および Windows Server 2025 以降では、Credential Guard を無効にしなかった適格なデバイスでは、既定で有効になっています。 これは、 最小ハードウェア要件を満たしている限り、Enterprise (E3 および E5) および Education ライセンスのすべてのデバイスと一部の Pro ライセンスに影響します。

以前に資格のあるライセンスで Credential Guard を実行し、その後 Pro にダウングレードした後、 ハードウェアの最小要件を満たすすべての Windows Pro デバイスは、既定の有効化を受け取ります。
問題の原因 アプリケーションとサービスは、パスワードベースの認証を使用する安全でないプロトコルに依存している場合、この問題の影響を受けます。 このようなプロトコルは、クライアントまたはサーバーでパスワードが漏洩する可能性があり、Credential Guard によってブロックされるため、安全でないと見なされます。 影響を受けるプロトコルは次のとおりです。

- Kerberos の制約のない委任 (SSO と指定された資格情報の両方がブロックされます)
- PKINIT が Diffie-Hellman ではなく RSA 暗号化を使用する場合の Kerberos (SSO と指定された資格情報の両方がブロックされます)
- MS-CHAP (SSO のみがブロックされます)
- WDigest (SSO のみがブロックされます)
- NTLM v1 (SSO のみがブロックされます)

注: MS-CHAP、WDigest、NTLM v1 では SSO のみがブロックされるため、これらのプロトコルは引き続きユーザーに資格情報の入力を求めることで使用できます。
解決方法 Microsoft では、MSCHAPv2 ベースの接続 (PEAP-MSCHAPv2 や EAP-MSCHAPv2 など) から証明書ベースの認証 (PEAP-TLS や EAP-TLS など) への移行をお勧めします。 Credential Guard では、証明書ベースの認証はブロックされません。

より迅速で安全性の低い修正を行う場合は、 Credential Guard を無効にします。 Credential Guard にはプロトコルごとまたはアプリケーションごとのポリシーがないため、オンまたはオフにできます。 Credential Guard を無効にした場合、保存されているドメイン資格情報は盗難に対して脆弱なままにします。

ヒント

既定の有効化を防ぐには、既定の有効化を受け取ったバージョンに更新する前に、Credential Guard を無効にするようにデバイスを構成します。 設定が構成されていない場合 (既定の状態)、デバイスが適格な場合、更新後にデバイスは自動的に Credential Guard を有効にします。

Credential Guard が明示的に無効になっている場合、デバイスは更新後に Credential Guard を自動的に有効にしません。

注

Windows 11 バージョン 22H2 または Windows Server 2025 にアップグレードしたときに、Windows Pro デバイスが既定の有効化を受け取るかどうかを判断するには、レジストリ キーIsolatedCredentialsRootSecretがComputer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0に存在するかどうかをチェックします。 存在する場合、デバイスは更新後に Credential Guard を有効にします。

アップグレード後に、無効化の手順に従って Credential Guard を 無効にすることができます。

問題を確認する方法

MS-CHAP と NTLMv1 は、Windows 11 バージョン 22H2 更新後の SSO の破損に関連します。 Credential Guard が MS-CHAP または NTLMv1 をブロックしているかどうかを確認するには、イベント ビューアー (eventvwr.exe) を開き、[Application and Services Logs\Microsoft\Windows\NTLM\Operational] に移動します。 次のログを確認します。

イベント ID (型)

Description

4013 (警告)

<string
id="NTLMv1BlockedByCredGuard"
value="Attempt to use NTLMv1 failed.
Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID
of client process: %4%nName
of client process: %5%nLUID
of client process: %6%nUser identity
of client process: %7%nDomain name
of user identity of client process: %8%nMechanism OID: 9%n%n
This device doesn't support NTLMv1.
/>

4014 (エラー)

<string
id="NTLMGetCredentialKeyBlockedByCredGuard"
value="Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2"
/>

Microsoft 以外のアプリケーションに関する問題

次の問題は MSCHAPv2 に影響します。

次の問題は Java GSS API に影響します。 次の Oracle バグ データベースの記事をご覧ください。

Windows で Credential Guard が有効になっている場合、Java GSS API は認証されません。 Credential Guard は、特定のアプリケーション認証機能をブロックし、レジストリ キーの設定に関係なく、アプリケーションに TGT セッション キーを提供しません。 詳細については、「 アプリケーション要件」を参照してください。

ベンダー サポート

次の製品とサービスでは、Credential Guard はサポートされていません。

重要

この一覧は包括的ではありません。 特定のバージョンの Windows を実行するシステムで、製品ベンダー、製品バージョン、またはコンピューター システムが Credential Guard をサポートしているかどうかを確認します。 特定のコンピューター システム モデルは、Credential Guard と互換性がない可能性があります。