ある日突然、いつも使っているサーバーにRDPログインしようとすると、こんなエラーが出て弾かれるようになりました。
The trust relationship between this workstation and the primary domain failed
しかも毎日同じサーバーで発生する。ワークグループへの離脱・再参加という重い作業を毎日繰り返すのは限界です。原因を徹底調査した記録をまとめます。
🚨 発生した症状
ドメインユーザーでRDPログインを試みると、冒頭のエラーメッセージが表示されてログインできない状態が続いていました。従来の対処法はワークグループへの離脱と再参加という手順で、再起動が2回必要な重い作業でした。毎日発生するため、もっとスマートな方法がないか調査することにしました。
🔍 調査の流れ
① まずSecure Channelを疑った
trust relationship failed といえばSecure Channelの破損が定番の原因です。以下のコマンドで確認しました。
Test-ComputerSecureChannel -Verbose結果は True。「ドメインとの信頼関係は正常」と表示されました。ここで一瞬詰まりましたが、調査を続けます。
② ドメイン参加状態・ネットワークを確認
(Get-WmiObject Win32_ComputerSystem).PartOfDomain
(Get-WmiObject Win32_ComputerSystem).Domain
nslookup [ドメイン名]
ping [ドメイン名]
nltest /dsgetdc:[ドメイン名]DNS解決・疎通・DCへの接続、すべて正常でした。インフラ起因ではないと判断しました。
③ GPO適用状況で気になる点を発見
gpresult /rGPO自体は正常に適用されていましたが、nltest で検出したDCのホスト名と、GPO適用元のDCのホスト名が1文字異なっていました。DC2台が存在し、役割が分かれている可能性が浮上しました。
④ repadmin で決定的なエラーを確認
repadmin /replsummaryここで原因が確定しました。
LDAP Error 49(0x31): Invalid Credentials
AcceptSecurityContext error, data 52e
The logon attempt failedサーバー自身がDCへのLDAP認証で弾かれていました。つまりコンピューターアカウントのパスワードがDC側と一致していない状態であることが判明しました。
⚠️ なぜ Test-ComputerSecureChannel が True を返したのか
ここが今回の調査で最も重要なポイントです。
Test-ComputerSecureChannel（資格情報なし）
└→ ローカルキャッシュを参照して判定
└→ True（見かけ上は正常）
repadmin /replsummary
└→ 実際にDCへLDAP接続を試みる
└→ Invalid Credentials（実態が露呈）Test-ComputerSecureChannel は資格情報なしで実行するとローカルキャッシュを参照するため、実態と乖離した結果を返すことがあります。真の状態確認には repadmin が有効です。
🎯 原因
直接原因：コンピューターアカウントのパスワード不一致
WindowsサーバーはDCとの間でコンピューターアカウント専用のパスワードを自動管理しています。このパスワードがサーバー側とDC側でズレると、ドメイン認証が通らなくなります。repadmin のLDAP認証エラー（data 52e）がその証拠です。
根本原因：VMスナップショットの自動復元（推定）
毎日同じサーバーで発生していることから、VMスナップショットの自動復元が根本原因として最有力です。スナップショット復元によってサーバー側のコンピューターアカウントパスワードが過去の値に巻き戻る一方、DC側は最新の値を保持し続けるため、毎日ズレが生じます。
毎日スナップショット自動復元
│
▼
サーバー側のコンピューターアカウントPWが過去の値に巻き戻る
│
▼
DC側のPWは最新のまま → 不一致
│
▼
LDAP認証失敗 → trust relationship failed🛠️ 対処方法
即時対処（暫定）：コマンド1つ・再起動1回で完結
ワークグループ経由の手順は不要です。以下のコマンド1つで対処できます。
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)実行するとドメイン管理者の資格情報を求めるポップアップが表示されます。入力後に再起動1回で復旧します。
| 項目 | 従来手順 | 本手順 |
|---|---|---|
| 再起動回数 | 2回 | ✅ 1回 |
| ワークグループ離脱 | 必要 | ✅ 不要 |
| 所要時間 | 30〜60分 | ✅ 10〜15分 |
恒久対処①：パスワード自動更新の無効化（テスト・QA環境限定）
グループポリシーの以下の項目を Enabled に設定します。スナップショット運用が前提の環境ではコンピューターアカウントのパスワードを固定することで、復元後のズレが発生しなくなります。本番環境への適用は推奨しません。
Computer Configuration
└ Windows Settings
└ Security Settings
└ Local Policies
└ Security Options
└ Domain member: Disable machine account password changes
→ Enabled恒久対処②：復元後に自動でRepairを実行する
スナップショット復元後の起動スクリプトに Test-ComputerSecureChannel -Repair を組み込む方法も有効です。資格情報の安全な保存方法と合わせて設計する必要があります。
❓ FAQ
🔸 Test-ComputerSecureChannel -Repair を実行するとパスワードが変わりますか？
人間が使うアカウントのパスワードは一切変わりません。変わるのはサーバー自身のコンピューターアカウントのパスワードのみです。ドメイン管理者・ローカルユーザー・ドメインユーザー全般への影響はありません。
🔸 Test-ComputerSecureChannel が True なのになぜ症状が出るのですか？
資格情報なしで実行した場合、ローカルキャッシュを参照して判定するため実態と乖離することがあります。repadmin /replsummary で実際にDCへ接続確認することで真の状態を把握できます。
🔸 本番環境でも同じ対処でいいですか？
即時対処（-Repairコマンド）は本番環境でも有効です。ただし恒久対処のパスワード自動更新無効化はセキュリティリスクがあるため、本番環境への適用は避けてください。
🔸 毎日発生する場合、何を最初に確認すべきですか？
VM基盤の管理者にスナップショットの自動復元運用が設定されていないか確認することを最初に行ってください。QA・テスト環境では毎朝クリーンな状態に戻す運用が原因となるケースが多いです。
🔸 物理サーバーでも同じ問題は起きますか？
起きます。物理サーバーの場合はスナップショット起因ではなく、長期間のネットワーク断・DCとの時刻ズレ・ADコンピューターアカウントの手動削除が主な原因となります。repadmin /replsummary で同様に確認できます。
✅ まとめ
trust relationship failed はSecure Channelの破損として知られていますが、Test-ComputerSecureChannel だけでは実態を掴めないケースがあります。repadmin /replsummary でLDAP認証エラーを確認することで原因を確定でき、-Repair オプション1つで従来の半分以下の時間で復旧できます。毎日同じサーバーで発生する場合はスナップショットの運用を真っ先に疑ってください。
コメント