Windows Server 2025で「このワークステーションとプライマリドメインとの信頼関係が失われています」を止める：機械アカウントパスワード更新の不具合とGPO回避策・復旧手順・ロールバック計画

Windows Server 2025 へドメインコントローラーを全面移行した直後から、Windows 10/11 クライアントで「このワークステーションとプライマリドメインとの信頼関係が失われています」が断続的に発生する――そんな相談が急増しています。本稿は原因の背景と、現場で実効性が高かった一次安定化（ワークアラウンド）から監視・ロールバック計画までを、WordPressにそのまま貼り付けて運用手順書として使える形でまとめました。

Windows Server 2025 への全面移行後に顕在化する“信頼関係切れ”の正体

現象の多くは、機械アカウント（コンピューターアカウント）パスワードの扱いが Windows Server 2025 で強化・変更されたことを契機として、クライアントと DC のセキュアチャンネル維持がうまくいかず途切れる、という構図です。コンピューターは既定で 30 日ごとに自分のパスワードをローテーションしますが、すべての DC が Server 2025 になった環境では、新仕様とクライアント側の更新タイミング／暗号設定の組み合わせにより、更新要求が失敗 → 既存のセッション鍵が無効化 → ログオン不能という流れに陥るケースがあります。

代表的なユーザー報告例

Windows 10/11（22H2〜24H2 を含む）で sporadic に発生。一度 Reset-ComputerMachinePassword や Test-ComputerSecureChannel -Repair を実施すると復帰するが、同一端末で再発する。
「最新の累積更新（例：KB5055523）を適用済み」でも、根本的には止まらない環境がある。
DC をすべて Server 2025 にした“純 2025 ドメイン”で顕在化しやすい傾向がある。

なぜ「修復してもまた切れる」のか

修復コマンドは現在の DC とローカルのコンピューターアカウントパスワードを再同期します。ところが背景にある「パスワード更新の失敗」が解消していないと、次のローテーション時に再び失敗し、数日〜数週間後に同じ端末で再発します。これが「一次的には直るのに、またすぐ切れる」の理由です。

まず押さえるべき“症状・環境・既知情報”

項目	内容
典型症状	「このワークステーションとプライマリドメインとの信頼関係が失われています」 `Reset-ComputerMachinePassword` や `Test-ComputerSecureChannel -Repair` で一時的に回復するが、同一端末で再発する。
発生環境	すべての DC を Windows Server 2025 に更新済み。クライアント OS は Windows 10/11（22H2〜24H2 を含む）。24H2 でも発生報告あり。最新の累積更新プログラム（例：KB5055523）適用済みでも再発する環境がある。
既知情報	Server 2025 で導入された機械アカウントパスワード更新の扱い・既定挙動の強化により、セキュアチャンネル維持が破綻するパターンがある。

運用を安定化させるための優先順位付きプレイブック

一次的な安定化（ワークアラウンド）

根本修正が提供されるまでの「痛み止め」として、DC 側でパスワード変更要求を拒否し、クライアント側はそもそも変更を出さないように合わせ込みます。

目的	手順	補足
一次安定化	グループポリシーによるワークアラウンド DC 向け GPO（DC の OU に適用） `コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカルポリシー → セキュリティオプション` 「Domain controller: Refuse machine account password changes」→ 有効ドメインメンバー（端末）向け GPO 同パスにある「Domain member: Maximum machine account password age」→ 0 日（無期限）	DC 側で変更要求を拒否し、クライアント側も更新を発生させない設定に揃え、認証エラーの発生源を遮断します。既定の「30 日更新」は本来セキュリティ上推奨ですが、恒久パッチが出るまでの限定措置として容認。適用範囲に注意：DC 用 GPO は必ずドメインコントローラー OU にリンク。全域に適用しないこと。
追加のリスク低減	可能なら旧バージョン DC（例：Server 2022）を 1 台残して混在させ、クライアント側の更新パスに逃げ道を作る。再発に備えて Intune / 構成プロファイルまたは PowerShell で自動修復スクリプトを配布。	現場報告では、純 2025 ドメインより混在構成の方が発生頻度が下がるケースがある一方、混在ゆえの暗号方式差異が別事象を誘発する報告もあります。評価用 OU で十分に検証してください。
恒久対策の監視	Microsoft の修正パッチ公開を Windows Update / セキュリティ更新情報で定期確認。修正パッチ適用後は、上記ワークアラウンドを元に戻す（Refuse＝無効、最大パスワード年齢＝既定 30 日など）。	ワークアラウンドの長期常用は避けること。放置すると別の認証不具合やセキュリティリスク（固定化パスワードの露出期間増大）を生む可能性があります。

注意：この設定は「Disable machine account password changes（無効化）」とは異なる

クライアント側には「Disable machine account password changes」という設定もありますが、これはより強力に更新を止めるため、復旧シナリオを狭める副作用があります。本稿では年齢（Maximum age）＝ 0に留めることを推奨します。

再発時に備える端末側“自己修復”の配布

# 端末のセキュア チャンネルを検査し、壊れていたら再作成する（対話認証）
$Computer = $env:COMPUTERNAME
if (-not (Test-ComputerSecureChannel)) {
    Test-ComputerSecureChannel -Repair -Credential (Get-Credential) -Verbose
}

上記はユーザー対話を伴うため、Intune の Endpoint analytics（リメディエーション）や、企業配布のランチャー経由での実行を推奨します。資格情報の扱いに注意しつつ、限定的な権限の結合アカウントを用意すると安全です。

発生の有無を素早く見分ける“観測”の作り方

イベントログのシグナル

ログ	イベント ID	意味／示唆
DC（System）ソース：NETLOGON	5722 / 5805 ほか	端末のセッションセットアップ失敗や、コンピューターアカウントの認証不一致。信頼関係切れの温床を示唆。
クライアント（System）ソース：NETLOGON	3210	セキュアチャンネル確立の失敗。まさにユーザーに見えるエラーの直前や同時に出ることが多い。
クライアント／DC（System）ソース：LSASRV	40960 / 40961	Kerberos の認証失敗。暗号種別やチケット検証に起因するケースがある。

PowerShell で「問題端末の洗い出し」を自動化

直近 7 日間に DC 側で 5722 を出した端末を列挙するサンプルです（イベントログ閲覧権限が必要）。

$since = (Get-Date).AddDays(-7)
$filter = @{ LogName='System'; ProviderName='NETLOGON'; Id=5722; StartTime=$since }
Get-WinEvent -FilterHashtable $filter |
  ForEach-Object {
    # メッセージ本文から端末名を正規表現で抽出（環境により調整）
    if ($_.Message -match 'computer\s+([A-Za-z0-9\-_]+)\s+failed to authenticate') {
      [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        Client      = $matches[1]
        DC          = $_.MachineName
      }
    }
  } | Sort-Object TimeCreated -Descending | Format-Table -Auto

必要に応じて Netlogon ログを有効化

難治性のケースでは、DC で一時的に Netlogon の詳細ログを出すと原因追跡が進みます（容量に注意）。

# 例：詳細ログを有効化（0x2080ffff）、収集が済んだら 0 に戻す
nltest /dbflag:0x2080ffff
# ... 調査後に停止
nltest /dbflag:0x0

一次安定化を“安全に”広げる：実装とロールバックの設計

GPO 配布の実装ポイント

スコープ設計：
DC 用 GPO は 「ドメインコントローラー」OU のみにリンク。リンクの継承や優先度を確認し、意図しない DC 以外のサーバーに掛からないよう WMI フィルター（ProductType = 2 など）で保険をかけると安全です。
クライアント側 GPO：
サブネットや部門単位のパイロット OUから展開し、イベント監視とヘルプデスクチケットの推移を見て段階拡大。
競合回避：
既存のセキュリティベースライン（CIS/DoD STIG 等）で当該設定が「未定義／推奨値 30 日」とされているケースが多いので、リンク順と GPO の上書き関係を明示する。

ロールバック計画（修正パッチ適用後）

修正パッチを ラボ OU の DC / 代表端末群に適用。
上記 OU にだけ一時的に “元の既定”（Refuse＝無効／最大年齢＝30 日）に戻すテスト GPO をリンク。
イベント／利用者影響がないことを確認できたら、全域へ段階撤回。
撤回後 1〜2 サイクル（30〜60 日）監視し、問題なければワークアラウンド GPO を無効化→削除。

よくある質問（FAQ）

Q. KB5055523 を当てても直らないのはなぜ？

同更新は「Kerberos 経路における一部のパスワード変更／証明書連携」の不具合を改善します。しかし、機械アカウントパスワードのローテーション失敗をすべてのシナリオで解消するものではなく、Server 2025 の新たな既定挙動と組み合わせた場合に再発する環境が残ります。本稿の GPO ワークアラウンドはその“隙間”を一時的に塞ぐものです。

Q. クライアントを 24H2 にすれば収まる？

24H2 で改善したという現場報告もありますが、すべてのケースを撲滅する保証はありません。サービシングブランチ／セキュリティベースライン／暗号設定（RC4/AEAD/PKINIT など）との相互作用があるため、一部では 24H2 でも再発します。

Q. 「Disable machine account password changes（無効化）」を有効にするのはダメ？

完全停止は復旧策の柔軟性を下げ、固定化パスワードの長期利用というリスクをさらに高めます。年齢 0（無期限）による抑制の方が、ロールバック設計上も扱いやすく推奨です。

Q. 既に「信頼関係切れ」になった端末はどう直せばよい？

Test-ComputerSecureChannel -Repair または Reset-ComputerMachinePassword（あるいは netdom resetpwd）でアカウントパスワードの再同期を行います。これでログオン可能になりますが、ワークアラウンドを未適用なら次回ローテーションで再発し得ます。

運用現場で役立つ“チェックリスト”

適用前（準備）

ドメイン機能レベル／フォレスト機能レベル／DC の台数と配置を棚卸し。
監視の目安：DC System（NETLOGON 5722/5805）、クライアント System（NETLOGON 3210、LSASRV 40960/40961）。
時刻同期（w32tm /query /status）の健全性を確認。Kerberos トラブルの温床を除く。

適用（展開）

DC 用 GPO を DC OU へリンク（WMI フィルター推奨）。
クライアント用 GPO はパイロット OU → 全社へ段階拡大。ヘルプデスクの問い合わせ件数を KPI として併走。
必要に応じて Intune Remediation を投入（検出：Test-ComputerSecureChannel、修復：-Repair）。

適用後（運用）

イベント発生の推移・端末リストを週次レビュー。
（上掲スクリプトでハイライトし、SCCM/Intune/Defender XDR に取り込むと調査が捗ります）
パッチ情報のモニタリング（Windows Update/セキュリティ更新情報）。
修正パッチ入手後は、必ず GPO を元に戻す手順を実施。

テクニカルリファレンス（設定とレジストリの対応表）

セキュリティオプション（GPO）	レジストリ（参考）	意味・備考
Domain controller: Refuse machine account password changes	`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RefusePasswordChange`（DWORD 1=拒否）	DC がメンバーからの機械アカウントパスワード変更要求を受け付けない。
Domain member: Maximum machine account password age	`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge`（DWORD 日数、0=無期限）	機械アカウントパスワードの更新サイクル。既定は 30 日。
Domain member: Disable machine account password changes	`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange`（DWORD 1=無効化）	完全停止。復旧の柔軟性が下がるため本稿では推奨しない。

トラブルの“地雷”を避けるための実践知

DC OU 以外に「Refuse」を掛けない：意図せずメンバーサーバーや管理端末に掛かると別の障害を誘発します。
GPO 競合の明文化：既存のベースライン（CIS/DoD STIG 等）で「30 日以下」と定義されていれば、今回のワークアラウンドは一時的な例外として例外管理台帳に残す。
暗号方式（msDS-SupportedEncryptionTypes）をむやみに変更しない：RC4 再有効化などは短期的に通ることがあっても、長期的にはセキュリティ低下に直結します。
仮想化製品のスナップショット／バックアップ復元直後：機械アカウントパスワードの「巻き戻り」で高頻度に失敗します。イメージ運用の標準手順に「再同期」を組み込む。

一歩深掘り：Server 2025 の“変化点”と影響

Server 2025 は、既定のコンピューターアカウントパスワード生成の強化や、パスワード変更経路の堅牢化など、認証面のセキュリティを底上げする変更が多数含まれています。これ自体は望ましい進化ですが、クライアント側の更新実装や環境の暗号設定との相互作用で、ローテーション処理の境界条件にひっかかる端末が一定数出てしまう――というのが、現場で観測されている実情です。

“最小の痛みで最大の効果”を得るまとめ

まずは止血：DC に Refuse、クライアントに Maximum age=0 を GPO で適用し、信頼関係切れの連鎖を止める。
可視化：NETLOGON（DC 5722/5805、端末 3210）と LSASRV（40960/40961）を監視ダッシュボード化。
自己修復：Intune/PowerShell で Test-ComputerSecureChannel -Repair を配布し、現場復帰までの時間を最短化。
撤回を前提に：修正パッチ適用後は必ず“元の既定”へ戻す運用計画をセットで設計。

付録：現場投入できるスクリプト集

1) 端末のセキュアチャンネル健全性チェック

# 正常なら True、破損していれば False を返す
Test-ComputerSecureChannel -Verbose

2) ドメイン資格情報を用いた即時修復

# DC 名を指定して再同期（管理者向け）
Reset-ComputerMachinePassword -Server &lt;DC の FQDN&gt; -Credential &lt;DOM\Account&gt;

3) DC 上で Netlogon 詳細ログを一時有効化

# 調査用にオン → 収集後に必ずオフ
nltest /dbflag:0x2080ffff
# ・・・
nltest /dbflag:0x0

4) 直近の「疑わしい端末」を一覧化（DC 側実行）

$since = (Get-Date).AddDays(-3)
$filter = @{ LogName='System'; ProviderName='NETLOGON'; Id=5722; StartTime=$since }
Get-WinEvent -FilterHashtable $filter |
  ForEach-Object {
    if ($_.Message -match 'computer\s+([A-Za-z0-9\-_]+)\s+failed to authenticate') {
      $client = $matches[1]
      [PSCustomObject]@{ When=$_.TimeCreated; Client=$client; DC=$_.MachineName }
    }
  } | Sort-Object When -Descending | Format-Table -Auto

おわりに

「信頼関係が失われています」は、ユーザー影響が極めて大きいエラーです。Server 2025 のセキュリティ強化は歓迎すべき進化ですが、移行直後の混乱を避けるためには、現実的で後戻り可能な止血策と、見える化＋自動修復の組み合わせが効果的です。本稿の手順を適用すれば、再発頻度を大幅に抑えつつ、恒久修正を安心して待つための“静かな状態”を作れます。修正パッチが提供されたら速やかに GPO を既定へ戻し、正常な 30 日ローテーション運用へ復帰してください。

参考：質問へのダイレクト回答（要点整理）

質問概要に対する回答・解決策（再掲／補足付き）

目的	手順	補足
一次的な安定化	GPO ワークアラウンド 1) DC 向け： `コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカルポリシー → セキュリティオプション` 「Domain controller: Refuse machine account password changes」→ 有効 2) 端末向け：同パスにある「Domain member: Maximum machine account password age」→ 0 日（無期限）	DC 側でパスワード変更を拒否、クライアント側で更新要求を出さない設定に揃えることで、認証エラーの発生源を抑制。「機械アカウントパスワード 30 日更新」はセキュリティ上推奨だが、恒久修正が出るまでの暫定策として容認。
追加のリスク低減	可能なら Server 2022 の DC を 1 台残す混在構成を検討。 Intune／PowerShell で自動修復スクリプトを全端末へ配布。	混在で発生頻度が低下する報告がある一方、暗号方式の違いが別の問題を招く可能性もある。検証→段階展開が必須。
恒久対策の監視	Microsoft の修正パッチを定期確認。修正パッチ適用後は、Refuse＝無効、最大パスワード年齢＝既定 30 日へ必ず戻す。	ワークアラウンドの長期常用は、別の認証エラーやセキュリティリスクを新たに生む可能性がある。

端末側自動修復の最小スクリプト（再掲）

# 失敗時にセキュア チャンネルを再作成
$Computer = $env:COMPUTERNAME
if (-not (Test-ComputerSecureChannel)) {
    Test-ComputerSecureChannel -Repair -Credential (Get-Credential) -Verbose
}

ポイント

KB5055523 は Kerberos まわりの一部不具合を修正するが、本件の根本原因には十分でない環境が実在する。
ワークアラウンドは“止血”と捉え、恒久パッチ適用後に撤回する計画を必ず立てる。

Windows Server 2025で「このワークステーションとプライマリドメインとの信頼関係が失われています」を止める：機械アカウントパスワード更新の不具合とGPO回避策・復旧手順・ロールバック計画

Windows Server 2025 への全面移行後に顕在化する“信頼関係切れ”の正体

なぜ「修復してもまた切れる」のか

まず押さえるべき“症状・環境・既知情報”

運用を安定化させるための優先順位付きプレイブック

一次的な安定化（ワークアラウンド）

注意：この設定は「Disable machine account password changes（無効化）」とは異なる

再発時に備える端末側“自己修復”の配布

発生の有無を素早く見分ける“観測”の作り方

イベントログのシグナル

PowerShell で「問題端末の洗い出し」を自動化

必要に応じて Netlogon ログを有効化

一次安定化を“安全に”広げる：実装とロールバックの設計

GPO 配布の実装ポイント

ロールバック計画（修正パッチ適用後）

よくある質問（FAQ）

Q. KB5055523 を当てても直らないのはなぜ？

Q. クライアントを 24H2 にすれば収まる？

Q. 「Disable machine account password changes（無効化）」を有効にするのはダメ？

Q. 既に「信頼関係切れ」になった端末はどう直せばよい？

運用現場で役立つ“チェックリスト”

適用前（準備）

適用（展開）

適用後（運用）

テクニカルリファレンス（設定とレジストリの対応表）

トラブルの“地雷”を避けるための実践知

一歩深掘り：Server 2025 の“変化点”と影響

“最小の痛みで最大の効果”を得るまとめ

付録：現場投入できるスクリプト集

1) 端末のセキュアチャンネル健全性チェック

2) ドメイン資格情報を用いた即時修復

3) DC 上で Netlogon 詳細ログを一時有効化

4) 直近の「疑わしい端末」を一覧化（DC 側実行）

おわりに

参考：質問へのダイレクト回答（要点整理）

質問概要に対する回答・解決策（再掲／補足付き）

端末側自動修復の最小スクリプト（再掲）

コメント

コメントするコメントをキャンセル

Windows Server 2025で「このワークステーションとプライマリ ドメインとの信頼関係が失われています」を止める：機械アカウント パスワード更新の不具合とGPO回避策・復旧手順・ロールバック計画

Windows Server 2025 への全面移行後に顕在化する“信頼関係切れ”の正体

なぜ「修復してもまた切れる」のか

まず押さえるべき“症状・環境・既知情報”

運用を安定化させるための優先順位付きプレイブック

一次的な安定化（ワークアラウンド）

注意：この設定は「Disable machine account password changes（無効化）」とは異なる

再発時に備える端末側“自己修復”の配布

発生の有無を素早く見分ける“観測”の作り方

イベント ログのシグナル

PowerShell で「問題端末の洗い出し」を自動化

必要に応じて Netlogon ログを有効化

一次安定化を“安全に”広げる：実装とロールバックの設計

GPO 配布の実装ポイント

ロールバック計画（修正パッチ適用後）

よくある質問（FAQ）

Q. KB5055523 を当てても直らないのはなぜ？

Q. クライアントを 24H2 にすれば収まる？

Q. 「Disable machine account password changes（無効化）」を有効にするのはダメ？

Q. 既に「信頼関係切れ」になった端末はどう直せばよい？

運用現場で役立つ“チェックリスト”

適用前（準備）

適用（展開）

適用後（運用）

テクニカル リファレンス（設定とレジストリの対応表）

トラブルの“地雷”を避けるための実践知

一歩深掘り：Server 2025 の“変化点”と影響

“最小の痛みで最大の効果”を得るまとめ

付録：現場投入できるスクリプト集

1) 端末のセキュア チャンネル健全性チェック

2) ドメイン資格情報を用いた即時修復

3) DC 上で Netlogon 詳細ログを一時有効化

4) 直近の「疑わしい端末」を一覧化（DC 側実行）

おわりに

参考：質問へのダイレクト回答（要点整理）

質問概要に対する回答・解決策（再掲／補足付き）

端末側自動修復の最小スクリプト（再掲）

コメント

コメントする コメントをキャンセル

Windows Server 2025で「このワークステーションとプライマリドメインとの信頼関係が失われています」を止める：機械アカウントパスワード更新の不具合とGPO回避策・復旧手順・ロールバック計画

イベントログのシグナル

テクニカルリファレンス（設定とレジストリの対応表）

1) 端末のセキュアチャンネル健全性チェック

コメントするコメントをキャンセル