MENU

Windows 11でVBSが無効化できない：Credential Guard・UEFI lockとVMware

Windows11

Windows 11でVBSが残る場合は、Credential Guard、メモリ整合性、ハイパーバイザーの実行状態と設定元を別々に確認します。

Hyper-Vのチェックを外しただけでは、VBSを利用する保護機能やハイパーバイザーの実行状態まで判定できません。Windows 11 24H2でVMwareのネスト仮想化が動かない時も、まず実行状態と製品の対応範囲を読み取ります。「24H2のProでは必ずUEFI lockが既定」「6ステップで必ずESXiが動く」という原文の説明は訂正します。

目次

目次

  1. VBSが残る時に確認する状態
  2. 24H2だけがUEFI lock既定という説明を訂正
  3. Credential Guard・HVCI・Hyper-Vの違い
  4. 変更前に記録するもの
  5. 設定元とロック状態で選ぶ無効化手順
  6. 再起動後も残る場合の切り分け
  7. 機能への影響と別ホストの選択
  8. 元に戻す時の確認
  9. よくある質問
  10. 確認の順序

VBSが残る時に確認する状態

Windowsの検索でmsinfo32.exeを開き、「システムの要約」の仮想化ベースのセキュリティと、実行中のセキュリティサービスを確認します。原文のsysinfo.exeではありません。Hyper-Vについて「ハイパーバイザーが検出された」という表示も別に確認します。

管理者PowerShellから次を読む方法もあります。設定を書き換えない確認例です。

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace "root\Microsoft\Windows\DeviceGuard" |
    Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning
項目見方
VirtualizationBasedSecurityStatus0=未有効、1=有効だが未実行、2=有効で実行中
SecurityServicesConfigured配列に1ならCredential Guard設定、2ならメモリ整合性設定。他の機能値もあり得る
SecurityServicesRunning配列に1ならCredential Guard実行、2ならメモリ整合性実行。Configuredと区別

VBSがRunningでも、Credential Guardが必ず実行中とは限りません。またLsaIso.exeがあるかだけで判定する方法はMicrosoftが推奨していません。CPUの仮想化機能、Windowsハイパーバイザー、VBSサービスはそれぞれ別の状態です。

24H2だけがUEFI lock既定という説明を訂正

Microsoftは要件を満たすWindows 11 22H2以降のCredential Guard既定有効化を案内し、既定はUEFI lockなしと明記しています。Pro/Pro Educationにも、以前Credential Guardを使っていた端末が要件を満たす場合など、条件付きでVBS/Credential Guardが自動有効になる説明があります。クリーンインストールした全Pro端末がUEFI lock付きになるという仕様ではありません。

同じ24H2でもライセンス、ハードウェア、過去の設定、組織管理により状態が違います。24H2を新しいWindows全体の最新バージョンと扱わず、実際のOSビルド・エディションと設定を記録してください。過去の明示的な無効設定が既定有効化で常に上書きされるという説明も公式仕様と一致しません。

Credential Guard・HVCI・Hyper-Vの違い

Credential GuardはVBSを使いNTLMハッシュ等の資格情報を分離して保護する機能です。メモリ整合性（HVCI）は別の保護で、両方がWindowsハイパーバイザーを使う場合があります。LSA保護の名称やLsaIsoの表示だけをVBS全体と同一視しません。

VMware Workstationは、対応するホスト/製品/CPUの条件でWindows Hypervisor Platform経由の通常VMを実行できる場合があります。一方、VM内でさらにハイパーバイザーを使うネスト仮想化には別の制約があります。Broadcomの公式資料はWorkstationでホストHyper-Vと対象のネスト機能を同時に有効にする制約を案内しています。「通常VMが動いた」と「ネストが対応する」は別に確認します。

変更前に記録するもの

  • ホストOSの版/ビルド/エディション、CPU、Workstationの版と正確なエラーを記録する。
  • 通常VMの起動失敗か、VM内でVT-x/AMD-V等を使う時だけの失敗かを分ける。
  • msinfo32とWin32_DeviceGuardの変更前の結果を残す。
  • Intune/GPO/ローカル設定の管理元と、Credential GuardやHVCIのUEFI lock有無を担当者が確認する。
  • 必要なWSL2、Docker、Sandbox等の依存機能と、保護を維持する別の検証ホストを検討する。
  • 変更する場合は保守範囲、元設定、復旧用アクセス、BitLocker回復情報とバックアップを準備する。

設定元とロック状態で選ぶ無効化手順

Credential GuardがUEFI lockなしの場合

設定元Microsoft公式の変更経路
Intune/MDM同じCredential GuardポリシーをDisabledへ変更し、割当と適用後の再起動を確認
GPOコンピューターの構成→管理用テンプレート→システム→Device GuardのTurn On Virtualization Based SecurityをDisabledへ
GPOで制御されていないレジストリ設定公式のControl\LsaとPolicies\Microsoft\Windows\DeviceGuardのLsaCfgFlagsをREG_DWORD 0にする条件を確認

公式のレジストリ手順は、キーを削除するだけでは無効化にならない場合があるため値0を指定し、再起動を案内しています。元記事の壊れた.reg構文やRequirePlatformSecurityFeaturesの削除をUEFI lock解除と同一視する説明は使いません。これはCredential Guardの手順であり、他のVBSサービスを全部停止する保証ではありません。管理された設定をローカルで上書きし続けないようにします。

Credential GuardがUEFI lock付きの場合とSecConfig.efi

UEFI lock付きのCredential GuardはEFI変数に状態を保持するため、上のポリシー/レジストリだけでは完了しません。公式の「Disable Credential Guard with UEFI lock」は、管理者コマンドプロンプトからSecConfig.efiをEFIシステムパーティションへ置き、一時ブートエントリとbootsequenceを設定し、再起動時に端末で変更を確認する手順です。物理的な操作が必要とされています。

現在のCredential Guard公式例のloadoptionsはDISABLE-LSA-ISOです。元記事のDISABLE-LSA-ISO,DISABLE-VBSを、その章の全端末向けの必須値として置き換えません。また{guid}という文字のままでは作成/設定する実エントリの識別子になりません。公式の一連の例と、使用済みドライブ文字、既存のBCD/EFI設定を確認して担当者が実施してください。起動確認キーを全機種でF3→Enterと固定する案内はしません。

具体的な一連のコマンドはMicrosoftのUEFI lock付きCredential Guardの無効化手順で、実施時点の内容を確認できます。Credential Guardのロックと、HVCIのUEFI lockの扱いも同じと決めつけません。原文の改変されたブートコマンド列の一括コピーは撤去しています。

メモリ整合性とHyper-V関連機能は別に扱う

HVCIの設定元が管理ポリシーなら、担当者がその設定を変更します。ローカルのメモリ整合性画面だけでは管理ポリシーやUEFI lockを解除できない場合があります。Hyper-Vは「Windowsの機能」でHyper-V Platform/Hypervisorの対象を確認する公式手順がありますが、不要な機能をすべて一括で外す前に依存関係を確認してください。

Credential Guardの公式解除を行うために、Tamper Protection、Secure Boot、IOMMUをすべて必ずオフにするという手順は採用しません。HVCIのロック付き復旧など別の条件の公式手順を、通常の全端末へ広げないことが大切です。ファームウェアのカスタムキー切り替えを一般的なブルースクリーン対処にも使いません。

再起動後も残る場合の切り分け

結果次の確認
Credential Guardは停止、VBSは実行中SecurityServicesRunningのHVCI等、他の保護と管理ポリシーを確認
再起動後に設定が戻るIntune/GPOの割当、適用結果、ロック付き構成と実行状態を確認
ハイパーバイザーは検出、VBSサービスは停止Windows機能と依存するWSL2等、起動構成を担当者が確認
VBS停止でもネストVMが起動しないホスト自体がVMか、CPU仮想化の公開、製品/ゲストのサポート条件を確認

RequirePlatformSecurityFeaturesが1/3であることだけを「UEFI lockが復活する原因」と決めません。レジストリ値だけで現在の実行状態や全ロックを判定せず、ポリシーとmsinfo32/WMI、エラーを合わせます。

機能への影響と別ホストの選択

Credential GuardやHVCIを止めると、それぞれが提供する資格情報/コード整合性の保護が減ります。BitLockerやMFAは役割が異なり、同じ保護をそのまま代替するものではありません。保護が必要な業務ホストを維持し、専用ラボや別ホストで実験する構成も比較できます。

WSL2はHyper-Vの一部であるVirtual Machine Platformを利用します。ハイパーバイザーを停止した後、DockerのWSL2バックエンドへ変えるだけで問題なく代替できるという元説明は訂正します。利用中のバックエンドとホスト要件を確認してください。

Broadcomはネストしたハイパーバイザー全般を無条件にサポートしていません。限定的なHyper-V関連用途の例外と、学習用のネストESXi、本番のサポート範囲を分けます。VBSを停止したことでESXiやすべてのNested Hyper-Vが保証されるという結論にはしません。

元に戻す時の確認

変更前に記録したIntune/GPO/ローカルの管理元から必要な設定を戻し、関連Windows機能と起動設定を整合させます。LsaCfgFlagsの1（ロック付き）と2（ロックなし）を同じ復元値として使わず、元の方針を確認します。UEFI lockを付け直すと、再び解除時に端末操作が必要になる点も考慮します。

再起動後、VBS全体のRunningだけで完了とせず、Credential Guard/HVCIの実行配列、必要なWSL/Docker/VMと業務認証が使えるかを確認します。元記事の{guid}をそのまま削除コマンドへ入れたり、使用中の別ブートエントリを消したりしないでください。

よくある質問

UEFI lockは24H2で初めて追加されたもの？

いいえ。公式の既定有効化は22H2以降で案内され、既定はロックなしです。24H2すべての端末がロック付きという前提を置きません。

Hyper-Vと共存するWorkstationならネストも動く？

通常VMの共存と、ゲストへの仮想化機能の公開は別です。Broadcomの対応条件とネスト制約を確認します。

今後の更新で絶対に再有効化されない？

明示設定の扱いは公式資料に説明がありますが、組織の再配布や構成変更まで保証するものではありません。更新後の実行状態と管理設定を確認します。

確認の順序

  1. 通常VMとネストVMのどちらの問題かを特定する。
  2. msinfo32とWin32_DeviceGuardで状態を読む。
  3. 管理元とCredential Guard/HVCIそれぞれのロック有無を調べる。
  4. 必要な変更を対象機能と設定元に合わせ、保護/依存機能の影響を記録する。
  5. 再起動後の実状態とVMの結果を確認し、検証後に元の方針へ戻す。

この記事ではセキュリティ機能、BCD、EFI、Windows機能の変更やVM起動テストを行っていません。読み取りコードは構文確認のみです。

参照した公式資料

Windows11
Windows11 Hyper‑V Credential Guard VBS VMware Workstation ネスト仮想化

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメント一覧 （2件）

  • 素晴らしい情報でした。どうやっても無効化できなかったVBSを無効化できました。ありがとうございます。

    返信

コメントする

目次