Windows 11の「ドメイン信頼関係」問題を実機確認｜KB5124008適用PCは大丈夫？確認方法を解説

2026年9月18日時点の情報です。 Microsoftは、2026年9月のWindows 11更新後、一部のドメイン参加PCでオンプレミスActive Directory（AD）とのセキュアチャネルが失われ、正しいID・パスワードでもサインインできなくなる問題を正式に確認しています。

2026年9月のWindows Update「KB5124008」を適用したWindows 11で、「このワークステーションとプライマリ ドメインとの信頼関係に失敗しました」といった状態になる問題が確認されています。

Microsoftが原因として挙げているのは、Machine Identity Isolation（マシンID分離）です。

そこで、実際にオンプレミスADへ参加しているWindows 11 PCを2台使い、KB5124008の適用状況、セキュアチャネル、Machine Identity Isolation、Credential Guard、イベントログを確認しました。

検証の途中では、1台で一度だけ Test-ComputerSecureChannel が False になる場面があり、2台ともNETLOGONのイベントID 5719が多数記録されていました。

ただし、こうした結果だけで今回のKB5124008既知問題と判断できるわけではありません。どの条件まで揃えば関連を疑えるのか、実際の確認結果をもとに切り分けていきます。

この記事では、自社のWindows 11が今回の問題に該当するかを確認する方法を、実機検証を交えて整理します。

この記事の要点

• MicrosoftはKB5124008以降、一部のWindows 11でオンプレADとのセキュアチャネルが失われる問題を正式確認
• 原因の中心は、既存のMachine Identity Isolation Enforcement設定が更新後に反映されるようになったこと
• 切り分けでは Test-ComputerSecureChannel、nltest /sc_query、Machine Identity Isolation、Credential Guardの状態確認が重要
• イベントID 5719だけでは、今回のKB5124008既知問題と判断できない

Microsoftが正式確認した「ドメインの信頼関係」問題とは

Microsoftは、Windows 11 24H2／25H2向けの2026年9月8日セキュリティ更新「KB5124008」、またはそれ以降の更新を適用した一部環境で、Credential Guardで保護されたマシンアカウントがオンプレミスADとのセキュアチャネルを失う場合があると案内しています。

影響を受けると、正しいドメイン資格情報を入力しているにもかかわらず対話型サインインに失敗し、ドメインとの信頼関係に失敗したことを示すメッセージが表示される場合があります。

一方、以前にキャッシュされた資格情報を使うオフラインサインインは機能する可能性があります。また、Microsoftによると、ドメインコントローラー側のADレプリケーションやADサービスそのものには影響しません。

原因はMachine Identity Isolation

Microsoftの最新説明では、KB5124008以降によってMachine Identity Isolationという機能が有効に扱われるようになったことが問題につながっています。

ここで誤解しやすいのですが、KB5124008がすべてのPCで「強制モード」を勝手に設定するわけではありません。Microsoftは、更新後にWindowsが既存の設定またはポリシーで構成されていたMachine Identity Isolation Enforcementを尊重するようになったと説明しています。

Machine Identity Isolationを有効にすると、ADのコンピューターアカウント資格情報がCredential Guard側へ移され、以後のマシンアカウント認証がCredential Guardを経由します。

Microsoftによると、この機能がサポートされるのはWindows Server 2025のドメイン機能レベル（DFL）以上の環境です。

ここで特に注意したいのは、過去のテストや誤設定などで MachineIdentityIsolation=2（強制モード）が構成されたままになっている環境です。ドメイン側のDFLがWindows Server 2025未満であっても、KB5124008以降がその既存設定を「尊重」することでMachine Identity Isolation Enforcementが実際に適用され、セキュアチャネルの問題につながる可能性があります。

Windows Server 2019／2022で利用できる最新のDFLはWindows Server 2016なので、古いDFL環境では「現在そのポリシーを使っているつもりがない」場合でも、過去の設定が残っていないか確認することが重要です。

なお、Windows 11 26H1では同種の問題がKB5124012以降で案内されています。

実際のオンプレAD参加PCを2台確認した

今回、社内のオンプレミスADに参加しているWindows 11 PCを2台確認しました。ここでは「検証PC A」「検証PC B」とします。

項目	検証PC A	検証PC B
OS	Windows 11 Pro 25H2	Windows 11 Pro 25H2
フルビルド	26200.9457	26200.9457
オンプレAD参加	あり	あり
KB5124008	更新履歴で適用を確認	更新履歴で適用を確認
KB5129195	適用済み	適用済み

検証時点のフルビルドは、Windows Update履歴に表示されたKB5129195のOSビルド表記から、両PCとも 26200.9457 であることを確認しました。実環境で確認する場合は、winver または Get-ComputerInfo とあわせて記録しておくと、後から更新前後を比較しやすくなります。

検証PC Bは、24H2の段階でKB5124008を適用した後、25H2へ機能更新されています。

Get-HotFixだけでは過去の更新を確認できなかった

検証用バッチでは当初、次のように Get-HotFix でKB5124008を確認していました。

Get-HotFix -Id KB5124008,KB5129195 -ErrorAction SilentlyContinue

しかし今回の2台では、出力に表示されたのは現在の累積更新KB5129195だけでした。一方、Windows Updateの「更新の履歴」にはKB5124008が残っています。

少なくとも今回の環境では、過去にKB5124008を適用したかどうかはWindows Update履歴でも確認した方が確実でした。

まずセキュアチャネルが正常か確認する

ドメインとの信頼関係を確認するため、管理者権限のPowerShellで次のコマンドを実行しました。

Test-ComputerSecureChannel -Verbose

正常な場合は True と表示されます。Microsoftのドキュメントでも、このコマンドはローカルコンピューターとドメイン間のセキュアチャネルが正常かを確認する方法として案内されています。

検証PC Aでは最初だけFalseになった

検証PC Aで最初に実行したときは、次の結果になりました。

False
ローカル コンピューターとドメインの間の
セキュリティで保護されたチャネルは破損しています。

それまで利用者からドメインログオンなどの不具合は報告されておらず、普段どおり利用できていたPCです。「もしかするとKB5124008の問題が発生しているのでは」と考え、さらに確認を進めました。

検証時に注意したい「nltest /sc_verify」

ここで今回、検証上の重要な注意点が分かりました。

セキュアチャネルを確認するため、続けて次を実行しました。

nltest /sc_verify:ドメイン名

結果は NERR_Success でした。その後、再度 Test-ComputerSecureChannel -Verbose を実行すると、今度は True に戻っていました。

Microsoftの nltest の仕様を確認すると、/sc_verify は単に状態を見るだけのコマンドではありません。セキュアチャネルが正常に動作していない場合、既存のチャネルを削除して新しいチャネルを構築する動作を含みます。

つまり、今回の検証PC Aでは「False → /sc_verify → True」という流れになったものの、/sc_verify の実行によって状態が変わった可能性があります。そのため、最初のFalseがKB5124008に起因するものだったとは断定できません。

これは実際に検証してみて気づいた点でした。

状態を変えずに確認するなら /sc_query

nltest /sc_query:ドメイン名

Microsoftの説明では、/sc_query は最後に使用したセキュアチャネルの状態を報告します。今回、その後に2台とも確認したところ、Trusted DC Connection Status Status = 0 0x0 NERR_Success となり、現在のセキュアチャネルは正常でした。

障害原因を調べたい場合は、Falseが出た直後に /sc_verify や修復コマンドを実行せず、まずログを保存する方が調査しやすいでしょう。

Machine Identity Isolationの設定を確認する

今回のMicrosoft既知問題で重要なのがMachine Identity Isolationです。Microsoftの回避策では、次の2か所を確認するよう案内されています。

Get-ItemProperty `
 "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
 -Name MachineIdentityIsolation `
 -ErrorAction SilentlyContinue

Get-ItemProperty `
 "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" `
 -Name MachineIdentityIsolation `
 -ErrorAction SilentlyContinue

今回の2台では、どちらの場所にもMachineIdentityIsolationの値は存在しませんでした。

値	状態
0	無効
1	監査モード
2	強制モード

今回問題になるのは主に2（Enforcement／強制モード）です。

なお、MachineIdentityIsolationのポリシー（CSP）は、MicrosoftのPolicy CSP資料上、対象エディションがEnterprise／Education／IoT Enterprise系に限定されており、Windows 11 Proは対象外です。

今回の検証PC2台はいずれもWindows 11 Proだったため、MachineIdentityIsolationの値が存在しなかったことは、技術的にも整合的な結果と言えます。

そのため、少なくとも確認時点では、Microsoftが説明している典型的なMachine Identity Isolation Enforcement環境ではありませんでした。

Credential Guardも確認した

$dg = Get-CimInstance `
 -ClassName Win32_DeviceGuard `
 -Namespace root\Microsoft\Windows\DeviceGuard
$dg | Select-Object `
 VirtualizationBasedSecurityStatus,
 SecurityServicesConfigured,
 SecurityServicesRunning

2台とも結果は、VirtualizationBasedSecurityStatus : 2、SecurityServicesConfigured : {2}、SecurityServicesRunning : {2} でした。

Microsoftの定義では、VirtualizationBasedSecurityStatus = 2 はVBSが実行中であることを示します。SecurityServicesRunning は、1がCredential Guard、2がメモリ整合性（HVCI）です。

今回の2台は {2} のみだったため、メモリ整合性は動作していましたが、Credential Guardの実行は確認できませんでした。 この点からも、今回の検証PCはMicrosoftが説明している「Credential Guard protected machine accounts」の典型条件とは一致していません。

イベントログにはNETLOGON 5719が多数あった

セキュアチャネルを確認する過程で、イベントビューアーの「システム」ログも確認しました。すると、2台ともNETLOGONのイベントID 5719が多数記録されていました。

過去14日間で、検証PC Aは28件、検証PC Bは36件でした。ただし、時系列を確認すると、両PCともKB5124008を適用する前の9月4日～9日にも5719が発生していました。

KB適用前だけでも検証PC Aは9件、検証PC Bは13件あります。したがって、今回の環境では「NETLOGON 5719があるからKB5124008のドメイン信頼関係問題が発生している」とは判断できません。

イベントID 5719自体には複数の原因があり、Microsoftも特定条件ではセキュアチャネルが最終的に確立される無害な5719が記録される例を公開しています。5719については原因の切り分けが別途必要なので、これは別記事で詳しくまとめる予定です。

自社PCが今回の問題に該当するか確認する手順

1. Windows Update履歴を確認

「設定」→「Windows Update」→「更新の履歴」でKB5124008、またはそれ以降の累積更新が入っているか確認します。Windows 11 24H2／25H2ではKB5124008以降が対象です。

2. セキュアチャネルを確認

Test-ComputerSecureChannel -Verbose

True なら、その時点ではセキュアチャネルは正常です。False なら、すぐに修復せず、まず確認結果やイベントログを保存します。

3. nltestでは /sc_query を使う

nltest /sc_query:ドメイン名

正常な例は Trusted DC Connection Status Status = 0 0x0 NERR_Success です。原因調査中は /sc_verify を先に実行しない方がよいでしょう。

4. Machine Identity Isolationを確認

前述の2つのレジストリ位置を確認し、値が 2 なら今回の既知問題との関連を強く疑う材料になります。

5. Credential Guardを確認

(Get-CimInstance `
 -ClassName Win32_DeviceGuard `
 -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

結果に 1 が含まれていればCredential Guardが動作しています。2 はメモリ整合性（HVCI）です。

6. 必要ならドメイン機能レベルを確認

Get-ADDomain | Select-Object DNSRoot,DomainMode

Active Directory PowerShellモジュールを利用できる管理端末またはDCで実行します。MicrosoftはMachine Identity Isolationについて、Windows Server 2025 DFL以上の環境でサポートすると案内しています。

問題が発生した場合のMicrosoft公式回避策

Microsoftは暫定的な回避策として、Machine Identity Isolationを有効化したときと同じ管理方法で無効にするよう案内しています。IntuneならIntune、GPOならGPO、レジストリで直接設定したならレジストリから変更します。

レジストリで MachineIdentityIsolation=2 の場合は 0 へ変更し、PCを再起動します。その後、管理者PowerShellで次を実行します。

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

レジストリ変更にはリスクがあるため、Microsoftも事前のバックアップを案内しています。

2026年9月18日時点では恒久修正版はまだ提供されておらず、Microsoftは今後のWindows UpdateでMachine Identity Isolation Enforcementを一時的に抑止する修正を予定しています。

今回の実機確認では既知問題は再現しなかった

確認項目	結果
KB5124008	2台とも適用履歴あり
フルビルド	2台とも26200.9457
現在のセキュアチャネル	2台とも正常
検証PC Aの初回確認	一度だけFalse
Machine Identity Isolation	2台とも値なし
Credential Guard	2台とも実行確認できず
メモリ整合性	2台とも実行中
NETLOGON 5719	2台とも多数。ただしKB適用前から発生

検証PC Aで一度 Test-ComputerSecureChannel=False を確認したのは事実です。しかし、その後に実行した nltest /sc_verify には異常時のセキュアチャネル再構築動作があるため、Falseになった時点の状態を維持したまま原因を追跡することはできませんでした。

また、Microsoftが既知問題の中心として説明しているMachine Identity Isolation Enforcementは2台とも確認できず、Credential Guardについても SecurityServicesRunning に 1 は含まれていませんでした。

このため、今回の2台については、Microsoftが正式確認しているKB5124008のMachine Identity Isolation起因問題を実環境で再現したとは判断していません。

なお、2台とも SecurityServicesRunning={2} で、メモリ整合性（HVCI）は動作していました。今回確認できたのは「Credential Guardの実行を示す 1 が出ていなかった」という点であり、設定としてCredential Guardが明示的に無効化されていることまでを示すものではありません。

今回の検証で特に重要だったのは、次の5点です。

• KB5124008の適用履歴だけでは、今回の既知問題の発生有無は判断できない
• Test-ComputerSecureChannel と nltest /sc_query を組み合わせて状態を確認する
• /sc_verify は検証対象のセキュアチャネルを再構築する可能性があるため、原因調査中は実行順序に注意する
• Machine Identity IsolationとCredential Guardの状態を確認して、Microsoftが示す発生条件と照合する
• イベントID 5719だけでは、今回のKB5124008障害と判断しない

「信頼関係に失敗」と表示されたら、すぐにドメイン再参加する前に確認を

「このワークステーションとプライマリ ドメインとの信頼関係に失敗しました」というエラーが出た場合、最初に行いたいのはドメイン再参加ではなく、その時点の状態を記録することです。

まず Test-ComputerSecureChannel -Verbose を実行し、False であれば、そのまま nltest /sc_query、Machine Identity Isolation、Credential Guard、イベントログを確認します。

原因調査中は、状態を変える可能性がある /sc_verify や修復コマンドを先に実行しない方が、後から原因を追いやすくなります。

一方、業務継続を優先して修復が必要な場合は、Microsoftが案内している回避策と、自社のGPO／Intune／レジストリ管理方法を確認したうえで対応します。

2026年9月18日時点では、Microsoftは本件の恒久修正を今後のWindows Updateで提供する予定としています。情シス担当者は、次の更新が公開されたら、次の点を確認するとよいでしょう。

• KB5129195以降の既知の問題欄が更新されたか
• Machine Identity Isolation Enforcementの扱いが変更されたか
• 回避策が不要になったか

この記事も、Microsoftの修正状況に合わせて更新していきます。

よくある質問

KB5124008が入っていれば、すべてのドメイン参加PCが危険ですか？

いいえ。Microsoftが正式確認しているのは一部のCredential Guard protected machine accountで、Machine Identity Isolation Enforcementの既存設定が関係します。KB5124008が入っているだけで必ず発生する問題ではありません。

KB5129195を入れれば直りますか？

2026年9月18日時点では、このドメイン信頼関係問題はKB5129195の「既知の問題」として残っています。KB5129195では別の問題が修正されていますが、本件の恒久修正ではありません。

Event ID 5719があれば信頼関係が壊れていますか？

5719だけでは判断できません。今回の検証PCではKB5124008適用前から多数記録されており、現在のセキュアチャネルは正常でした。Test-ComputerSecureChannel や nltest /sc_query、他のNETLOGONイベントと組み合わせて確認する必要があります。

参考情報

• Microsoft Support：KB5129195
• Microsoft Support：KB5124008
• Microsoft Learn：Credential Guard protected machine accounts
• Microsoft Learn：DeviceGuard Policy CSP
• Microsoft Learn：AD DS functional levels
• Microsoft Learn：Nltest
• Microsoft Learn：メモリ整合性を有効にする
• BleepingComputer：Microsoft shares workaround for Windows domain login issues
• 窓の杜：Windows 11の9月パッチに新たな問題