ドメイン参加PC/サーバーでログオン時に「このワークステーションとプライマリドメインとの信頼関係に失敗しました」と出る場合、多くはセキュアチャネル（コンピューターアカウントの共有秘密）が不一致になっています。ADUCの「アカウントのリセット」で直らないときに、netdomで確実に復旧する手順・パラメータの意味・確認方法を実務目線で整理します。
「信頼関係が失われました」エラーの正体（セキュアチャネル切れ）
このエラーは、ドメイン参加しているPC/サーバー（例：PC1）が、Active Directory上の「PC1のコンピューターアカウント」とセキュアチャネル（安全な通信路）を確立できないときに発生します。具体的には、PC1が保持している「コンピューターアカウントのパスワード（共有秘密）」と、AD側に保存されている値が一致しない状態です。
ここが重要なのですが、ADユーザーとコンピューター（ADUC）の「アカウントのリセット」は、AD側のコンピューターアカウントをリセットする操作であり、PC1ローカル側が保持している共有秘密まで自動的に揃えてくれるとは限りません。結果として、ADUCでリセットしてもPC側が直らず、ログオンエラーが継続することがあります。
よくある発生パターン
- 同名コンピューターを再参加（既存アカウントをリセットして参加し直す、クローンPCに同名を付ける、など）
- VMスナップショットの巻き戻し／システム復元でローカルの情報だけ過去に戻った
- DC間レプリケーションの遅延／不整合（DC1とDC2で見ている情報が瞬間的にズレる）
- 一時的なネットワーク断やDNS不調をきっかけに、以後復旧しない状態に固定化
- 稀にディスク障害・強制電断などでローカル側の保持情報が壊れた
結論：netdomは「原則、問題が起きているPC/サーバー側」で実行する
最も分かりやすく、現場で成功率が高いのは、信頼関係が切れている当事者（PC1）に入って、管理者権限のコマンドプロンプト（またはPowerShell）から netdom resetpwd を実行する方法です。
一方で netdom reset は「対象マシン名を指定してセキュア接続をリセットする」性格があり、到達性（名前解決・FW・RPCなど）や権限の影響を受けやすいことがあります。復旧作業としては、まず resetpwd を第一候補にするのが実務的です。
最短復旧フロー（手順だけ先に知りたい人向け）
- PC1にローカル管理者でサインイン（ドメインログオンできない場合の定番）
- 管理者としてコマンドプロンプトを起動
- DNSとDC疎通を軽く確認（例：
nslookup、ping、nltest） netdom resetpwdを実行（パスワードは対話入力）- 再起動（切り分けと反映のため推奨）
Test-ComputerSecureChannel/nltest/netdom verifyで確認
事前チェック（失敗の多いポイントを先に潰す）
| チェック項目 | 確認例 | NGのときの対処 |
|---|---|---|
| DNSがドメインDNSを向いているか | ipconfig /all でDNSサーバー確認 | 社内DNS（AD統合DNS）に修正、VPN配下なら分岐DNSも確認 |
| DCに名前解決できるか | nslookup dc1.domain.com | DNS修正、hosts固定は最終手段（恒久対策はDNSで） |
| DCへ通信できるか | ping dc1、Test-NetConnection（PS） | FW/ルーティング/VPN/プロキシなどを確認 |
| 時刻差が大きくないか | w32tm /query /status | 時刻同期を修正（Kerberosは時刻差に弱い） |
| PC1のコンピューターアカウントが存在し有効か | ADUCでPC1を検索（無効化/削除に注意） | 必要に応じて復元・再作成・OU権限を確認 |
まず一番よく使う復旧コマンド：netdom resetpwd（メンバーPC/サーバー向け）
信頼関係が切れた PC1側で、管理者権限のコマンドプロンプトから実行します。ドメインログオンできない場合は、ローカル管理者でサインインして実行してください。
定番コマンド（そのままテンプレとして使える形）
netdom resetpwd /s:dc1.domain.com /ud:domain\domain_admin /pd:*/pd:* は、パスワードを対話入力にする指定です。コマンドラインに平文で書かないのが基本です。
各パラメータの意味（/Domain や /Server に何を入れるかが分かる）
| 指定 | 意味 | 何を入れる？（例） | 実務上のコツ |
|---|---|---|---|
/s:（/server:） | 接続先ドメインコントローラー | dc1.domain.com（FQDN推奨） | 複数DCがあるなら「疎通が確実なDC」を明示。可能なら書き込み可能DCを指定 |
/ud:（/userd:） | ドメイン側の認証に使うユーザー | DOMAIN\Administrator など | まずはドメイン管理者でOK。恒久運用では委任権限（最小権限）も検討 |
/pd:（/passwordd:） | 上記ユーザーのパスワード | *（対話入力） | *でプロンプト入力にし、履歴・ログ・監査で平文が残る事故を防ぐ |
ポイントとして、/s:は「接続先DC」です。ドメイン内で自動選択させるより、トラブル時は明示した方が切り分けが早くなります（DNSやサイト間通信が怪しい状況ほど効果的です）。
netdomはどこで実行する？（PC側・DC側の違い）
おすすめは「対象PC/サーバー側（PC1）で実行」です。理由は単純で、PC1が保持しているセキュアチャネル情報を“その場で”更新できるためです。
| やり方 | 実行場所 | 向いているケース | 詰まりやすいポイント |
|---|---|---|---|
netdom resetpwd | 基本：対象PC（PC1） | ログオンできない／確実に直したい／切り分けを短くしたい | DC疎通とドメイン資格情報が必要 |
netdom reset | 環境次第（対象PCで実行が無難） | “対象マシン名を指定して”セキュア接続を操作したい | 名前解決・FW・RPCなどで失敗しやすい。到達性に左右される |
「/Domain」や「/Server」に何を入れる？迷いがちな指定ルール
復旧作業で迷いやすいのがドメイン名とDC指定です。結論から言うと、トラブル時は曖昧さを排除するのが正解です。
/Domain（/d:）に入れるもの
- 基本：DNSドメイン名（FQDN）を使う（例：
domain.com/corp.example.local） - 環境によってはNETBIOS名（例：
DOMAIN）でも動くが、混在環境では誤爆しやすい - 子ドメイン／複数ドメインがある場合は、必ず対象を明示する
/Server（/s:）に入れるもの
- 復旧させたいドメインのDC（例：
dc1.domain.com） - 可能ならFQDN指定（DNSが怪しいなら、まずDNSを直すのが本筋）
- RODCがある環境では、トラブル時は書き込み可能DCを指定した方が安心な場面がある
/UserO（/UserD）はドメイン管理者でよい？最小権限の考え方
まず復旧を優先するなら、ドメイン管理者（Domain Admins）で問題ありません。ただし運用としては、常にドメイン管理者を使うのは避けたいのも事実です。
実務での使い分け
- 緊急対応／一次復旧：ドメイン管理者で実施（確実性優先）
- 手順の標準化・恒久運用：OU単位で「対象コンピューターのパスワード更新（セキュアチャネル復旧）」に必要な権限だけを委任した運用アカウントを用意
なお、resetpwdでよく使うのは /UserD（省略形の /ud）です。/UserO はサブコマンドによって登場する“操作用（Operator）”のアカウント指定で、どちらもドメイン側の権限があるアカウントを使う、という理解でOKです。
/SecurePasswordPrompt は必要？（パスワードを安全に扱うコツ）
結論として、基本は/pd:*（または /p:*）で対話入力にすれば十分です。/SecurePasswordPrompt は「パスワードを安全に入力させる」目的のオプションとして紹介されることがありますが、現場ではまず * を使う運用が分かりやすく事故が少ないです。
避けたい運用は次の2つです。
- コマンドラインに平文パスワードを書く（端末の履歴・監査ログ・画面キャプチャに残る）
- 手順書に平文パスワード例をそのまま載せる（横展開事故の元）
netdom reset を使う場合（“対象マシン名”を指定してセキュア接続をリセット）
netdom reset は、指定したコンピューター（例：PC1）とドメイン間のセキュア接続をリセットする用途で使われます。書き方の一例は次の通りです。
netdom reset PC1 /d:domain.com /s:dc1 /u:domain\X /p:*ただし、reset は“相手マシン名を指定して操作する”性格があるため、ネットワーク到達性や権限、名前解決の状態によっては詰まりやすいです。現場では「まずresetpwd」→「難しければreset」→「最終手段で再参加」の順が安定します。
reset と resetpwd の違い（結局どっちを使えばいい？）
どちらも「信頼関係（セキュアチャネル）を直す」目的で使われますが、実務上は次の理解が役に立ちます。
| コマンド | 何を“直接”直すか | 特徴 | おすすめシーン |
|---|---|---|---|
netdom resetpwd | コンピューターアカウントのパスワード（共有秘密） | 復旧の王道。対象PC上で実行すると成功率が高い | まず最初に試す（特にログオン不可のケース） |
netdom reset | ワークステーションとDC間のセキュア接続 | 対象名指定の性格が強く、環境条件の影響を受けやすい | resetpwdが通らない／別観点でリセットしたい |
まとめると、迷ったら resetpwd を先にです。復旧の確度と切り分けの速さで優位です。
直ったかどうかの確認方法（ログオンできた、だけで終わらせない）
「とりあえずログオンできた」で終えると、別の要因が残っていた場合に再発します。復旧後は、セキュアチャネルを明示的に検証しておくと安心です。
確認コマンド早見表
| 確認方法 | コマンド例 | 期待結果 | 備考 |
|---|---|---|---|
| PowerShell（推奨） | Test-ComputerSecureChannel | True | Trueならセキュアチャネルは基本OK |
| nltest | nltest /sc_verify:domain.com | SUCCESS / 成功メッセージ | クライアント側で実行 |
| netdom verify | netdom verify /d:domain.com PC1 | 検証成功 | 補助検証として有用 |
おすすめの確認手順（現場でミスが少ない順）
Test-ComputerSecureChannelがTrueになるか確認nltest /sc_verify:domain.comを実行して、ドメインへのセキュアチャネル検証が成功するか確認- 必要に応じて再起動後も同じ結果になるか（再起動で再発するなら根本要因が残っている可能性）
うまくいかないときのトラブルシューティング（エラー別の当たりどころ）
netdomは“正しい方向性”でも、前提条件が満たされていないと失敗します。よくある詰まりを、原因と対処でまとめます。
| 症状／エラーの雰囲気 | ありがちな原因 | 対処（現場で効く順） |
|---|---|---|
| DC名が解決できない／ドメインに到達できない | DNSが外部DNSになっている、VPN分岐が不適切 | DNSをドメインDNSへ。nslookupでSRV/名前解決も確認 |
| 資格情報が通らない（パスワード間違い等） | ドメイン名の指定ミス、アカウントロック、UAC/入力ミス | DOMAIN\user形式に統一。ロック/期限/多要素要件を確認 |
| Access is denied | 権限不足、対象PCのローカルで管理者実行していない | 管理者として実行。まずDomain Adminで試し、成功後に権限制御を再設計 |
| 指定したDCで失敗するが、別DCなら成功 | DC固有の問題（レプリケーション、サイト間、サービス不調） | 別DCを/s:で指定。並行してrepadminやイベントログ確認 |
| 何度直しても短時間で再発 | VMの巻き戻し運用、クローン展開の設計ミス、時刻同期不良 | スナップショット運用の見直し、Sysprep/テンプレ運用、時刻同期の統一 |
「OSは直ったのに、特定アプリだけ“信頼関係がない”」と言う場合
復旧後に Test-ComputerSecureChannel が True になっているのに、バックアップエージェントや資産管理ツール、監視ツールなど特定アプリだけが「信頼関係が確立されていない」と出すケースがあります。
この場合、OSのセキュアチャネルではなく、アプリ側の仕組み（例：エージェント登録、証明書、サービスアカウント、独自の鍵、APIトークン等）が別問題になっていることが多いです。対処の方向性は次の通りです。
- エージェントの再登録／再プッシュ（管理サーバー側から再配布）
- アプリが使っているサービスアカウントの資格情報（パスワード変更・ロック・権限）を点検
- 証明書やTLS設定（更新期限・信頼ストア・相互認証）を確認
- アプリのキャッシュ情報をクリアし、サービス再起動
ポイント：「ドメインの信頼関係」と「アプリの信頼・登録」は別物です。OSレベルが正常なら、アプリ側の“再ペアリング”作業に切り替えるのが近道です。
再発防止：信頼関係が壊れる原因と、運用で効くチェックリスト
一度直しても再発する環境は、ほぼ例外なく“運用要因”が混ざっています。原因を潰しておくと、次の夜間障害が減ります。
典型原因（現場で多い順）
- 同名コンピューター再参加（既存アカウントをリセットして参加、クローンで同名など）
- VMスナップショットの巻き戻し（特にドメイン参加後の巻き戻し）
- DC間レプリケーション遅延／不整合（サイト間回線が細い、停止していたDCが復帰した等）
- 時刻同期の設計不備（NTPがバラバラ）
- DNS設計ミス（クライアントが外部DNSへ流れる）
再発防止チェック（運用に落とし込める形）
| チェック項目 | 推奨 | やってはいけない例 |
|---|---|---|
| テンプレ／クローン運用 | Sysprep前提、ドメイン参加は個別に実施 | ドメイン参加済みVMを複製して同名運用 |
| スナップショット運用 | ドメイン参加・運用開始後の巻き戻しを禁止（代替：バックアップ復元設計） | 運用中サーバーを日常的に巻き戻す |
| DNS設計 | クライアントはAD DNSを参照、分岐DNSは設計で担保 | DHCPで外部DNSを配布、端末が勝手に8.8.8.8へ |
| DC健全性 | レプリケーション監視、イベントログ監視、サイトリンク設計 | 停止していたDCを急に復帰させ、放置 |
| 時刻同期 | ドメイン階層（PDCエミュレーター基準）で統一 | 各サーバーが別々のNTPに同期 |
それでも直らない場合の最終手段（再参加の判断基準）
netdomで直らない（または直ったり直らなかったりする）場合、状況によっては「ドメイン再参加」が最短になることもあります。ただし、再参加には副作用もあるため、判断基準を持っておくのが大切です。
再参加を検討してよいサイン
- コンピューターアカウントが削除／重複／大きく壊れている
- ポリシーやセキュリティ製品でnetdom系の操作が強く制限されている
- 復旧後にすぐ再発し、根本原因が運用設計にある（スナップショット運用等）
再参加の注意点（やり直しでハマるポイント）
- 暗号化（EFS/一部の資格情報/アプリの鍵管理）が絡むと、再参加でアクセス不能になるケースがある
- サービスとして動くアプリが「ドメインアカウント」で動作していると、資格情報の再設定が必要になることがある
- 「再参加すれば全部解決」というより、根本原因（クローン運用・巻き戻し運用）を直さない限り再発する
まとめ：netdomで“安全に・確実に”復旧するための要点
- 信頼関係エラーの多くはセキュアチャネル（コンピューターアカウント秘密）の不一致
- 実行場所は原則「当事者のPC/サーバー上」。ローカル管理者で入って管理者実行
- まず試すのは
netdom resetpwd（成功率が高く、切り分けが早い） /s:（DC）と/ud:（ドメイン資格情報）を明示し、/pd:*で安全に入力- 復旧後は
Test-ComputerSecureChannelやnltestで“正常を確認してから”クローズ - OSが正常でもアプリだけ失敗するなら、アプリ側の再登録・証明書・サービスアカウントを疑う
コメント