ドメイン参加PCで信頼関係エラーが出たときは、最初からワークグループへ離脱しないでください。承認済みのローカル管理者でサインインし、DNS、時刻、ドメインコントローラーへの到達性を確認したうえで、Test-ComputerSecureChannelを使ってセキュアチャネルを検査します。Falseなら、ドメイン離脱をせずに-Repairまたはコンピューターアカウントパスワードのリセットを試すのが現在の安全な順序です。
ドメイン離脱・再参加は最後の手段です。先に離脱すると、有効なローカル管理者がない、BitLocker回復キーがない、証明書ベースのWi-FiやVPNへ接続できない、Intuneなどの管理状態を失う、といった別の問題を起こす可能性があります。Active Directoryのコンピューターオブジェクト削除や、回復環境を使った認証回避も標準手順にしてはいけません。
エラーメッセージで最初の分岐を決める
| 表示・症状 | 考えられる範囲 | 最初の確認 |
|---|---|---|
| このワークステーションとプライマリドメインとの信頼関係に失敗しました | コンピューターアカウントと端末側秘密情報の不一致 | Test-ComputerSecureChannel |
| The security database on the server does not have a computer account… | コンピューターアカウント不存在、破損、名前や属性の不整合 | ADオブジェクトの存在と端末名を管理者が確認 |
| 現在ログオン要求を処理できるログオンサーバーがありません | DNS、ネットワーク、DC停止、サイト、ファイアウォール | IP・DNS・時刻・DC到達性 |
| ローカルアカウントでもサインインできない | 信頼関係とは別のローカル資格情報・アカウント状態 | .\ユーザー名でローカルアカウントを明示 |
| 複数PCで同時発生 | DC、DNS、レプリケーション、ネットワークの共通障害 | 個別再参加をせずインフラ側を確認 |
似たログオンエラーでも原因は同じではありません。DNSやDC障害なのに端末を再参加させると、原因を直さないまま影響端末だけを増やします。逆に、セキュアチャネルがFalseなら、端末とADが保持するコンピューターアカウントの秘密情報を同期し直す必要があります。
信頼関係が壊れる仕組み
Active Directoryへ参加したWindows端末には、ユーザーアカウントとは別にコンピューターアカウントがあります。端末とドメインは共有するパスワードを使ってセキュアチャネルを作り、認証情報を安全に交換します。ドメインメンバーは既定で約30日ごとにコンピューターアカウントパスワードを変更します。
端末を古いスナップショットやバックアップへ戻した、同じ名前・同じイメージを不適切に複製した、AD側のコンピューターオブジェクトを削除・再作成した、DC間のレプリケーションに問題がある、といった場合、端末とADの値が食い違います。その結果、ユーザー名とパスワードが正しくても、PC自身がドメインから信頼されずログオンできません。
DNSや時刻の問題は、セキュアチャネル自体が正常でもドメインコントローラーを見つけられない、Kerberos認証を完了できないという症状を起こします。そのため、エラーメッセージだけで「コンピューターパスワードが壊れた」と断定せず、検査結果を基準にします。
復旧前にそろえるもの
- 組織が管理する有効なローカル管理者アカウント。Windows LAPSを使う環境では、権限を持つ管理者が現在のパスワードを取得します。
- BitLocker回復キー。起動構成や回復操作が必要になった場合に備えます。
- 端末名、ドメインDNS名、利用すべきドメインコントローラー、IP設定、設置サイト。
- コンピューターアカウントの修復権限を委任された資格情報。Domain Adminを障害端末へ常用しません。
- Intune、Configuration Manager、証明書、802.1X、VPNなど端末管理・接続要件の記録。
ローカル管理者でサインインするときは、サインイン名に.\LocalAdminまたはCOMPUTERNAME\LocalAdminの形式を使い、ドメインアカウントと区別します。LANケーブルを抜くことはローカル認証の必須条件ではありません。診断にはネットワークが必要なので、物理切断を前提にしないでください。
安全な復旧手順
1. IP、DNS、時刻を記録する
管理者のコマンドプロンプトまたはPowerShellで、現在の設定を確認します。変更前の状態を保存しておけば、誤ったDNSやDHCP、VPNアダプターの影響を追跡できます。
ipconfig /all
w32tm /query /statusDNSサーバーには組織が指定するActive Directory対応DNSが設定されている必要があります。外部のパブリックDNSだけを指定した状態では、ADのサービスレコードを正しく見つけられません。時刻ソースが不明、同期していない、大きくずれている場合は、組織の時刻設計に沿って先に修正します。端末だけに任意の公開NTPサーバーを設定しないでください。
2. セキュアチャネルを検査する
対象がドメインメンバーPCまたはメンバーサーバーであることを確認し、管理者のPowerShellで次を実行します。
Test-ComputerSecureChannel -VerboseTrueならセキュアチャネルは正常です。ワークグループへ離脱せず、DNS、ネットワーク、DC選択、ユーザー資格情報、ログオン権限を調査します。Falseなら次の修復へ進みます。このコマンドはドメインコントローラー上では偽の失敗を返すことがあるため、DCの検査には使用しません。
3. ドメイン離脱をせずに修復する
コンピューターアカウントの修復を委任された資格情報を用意し、対象PC自身で実行します。例のドメイン名とアカウント名は実環境へ置き換えます。
$cred = Get-Credential 'CONTOSO\DelegatedRepairAccount'
Test-ComputerSecureChannel -Repair -Credential $cred -Verbose成功したらPCを通常再起動し、ローカル管理者で再度サインインしてTest-ComputerSecureChannel -Verboseを実行します。Trueになったことを確認してから、一般のドメインユーザーでサインインします。修復成功メッセージだけで終了せず、再起動後の検査まで行ってください。
4. コンピューターアカウントパスワードをリセットする
-Repairが失敗し、DNSとDC到達性に問題がない場合は、対象PCのコンピューターアカウントパスワードを指定DCと同期し直します。DC名を推測せず、管理者が正常なDCを確認して指定します。
$cred = Get-Credential 'CONTOSO\DelegatedRepairAccount'
Reset-ComputerMachinePassword -Server 'dc01.contoso.com' -Credential $cred
Restart-Computer再起動後にTest-ComputerSecureChannelを再実行します。複数DCがあり、あるDCでは成功し別のDCでは失敗する場合、端末を再参加させる前にADレプリケーションとサイト構成を調査します。
5. netdom resetを代替として使う
AD DS管理ツールまたはRSATが利用できる管理環境では、netdom resetでワークステーションとDC間のセキュア接続をリセットできます。管理者のコマンドプロンプトで実行し、パスワードをコマンド行へ直接書かず、アスタリスクで安全な入力を求めます。
netdom reset %COMPUTERNAME% /domain:contoso.com /server:dc01.contoso.com /usero:CONTOSO\DelegatedRepairAccount /passwordo:*netdomが見つからないPCへ非公式サイトから実行ファイルをコピーしてはいけません。組織が管理するRSATまたは管理端末を使います。成功後は再起動とセキュアチャネルの再検査を行います。
6. 再参加はすべての修復が失敗した場合だけ
DNS、時刻、DC、レプリケーションが正常で、セキュアチャネル修復とパスワードリセットが失敗したときに限り、ワークグループ離脱とドメイン再参加を検討します。実施前に、有効なローカル管理者、回復キー、参加権限、証明書、VPN、MDM、ユーザープロファイルへの影響を確認します。
ADのコンピューターオブジェクトは、単に削除して作り直すのではなく、所属OU、グループ、委任、証明書、自動展開との関係を管理者が確認します。既存オブジェクトのリセットで足りる場合は、削除を避けます。再参加後は、正しいOU、グループポリシー、管理エージェント、証明書、ネットワーク接続を確認してください。
修復できない場合の分岐
Test-ComputerSecureChannelがTrueなのにログオンできない
信頼関係以外を調べます。ユーザーアカウントのロック、パスワード期限、ログオン権限、キャッシュ資格情報、条件付きアクセス、DC発見、DNS、時刻を確認します。「ログオンサーバーがない」エラーなら、特にネットワークとDNSを優先します。
-Repairがアクセス拒否になる
資格情報に必要な委任権限がない、対象ADオブジェクトのACLが異なる、別ドメインのアカウントを使っている可能性があります。Domain Adminを安易に使うのではなく、AD管理者が対象オブジェクトと委任を確認します。
DCを指定すると結果が変わる
ADレプリケーション、サイト、DNSの不整合を疑います。端末を何度も再参加させず、管理者がdcdiagやrepadminなどの公式管理ツールでDC側を調査します。複数端末で同時発生している場合は特にインフラ障害を優先します。
ローカル管理者が使えない
回復環境からアカウントを勝手に有効化したり、認証を迂回したりしません。Windows LAPS、ヘルプデスクの本人確認、承認済みブレークグラス、再イメージ化など、組織の回復手順を使います。ローカル回復手段を事前に整備することが再発時の重要な備えです。
再発防止
コンピューターアカウントパスワードを無効化しない
Microsoftは最大コンピューターアカウントパスワード有効期間を約30日にすることを推奨しています。変更を無効化したり、期間を大幅に延ばしたりすると、攻撃者が機械アカウントのパスワードを推測できる期間が延びます。信頼関係エラーの回避策として無効化しないでください。
クローンとスナップショットの運用を決める
ドメイン参加済み端末をそのまま複製せず、Windowsのサポートされる展開方法と一意の端末ID・コンピューター名を使います。古いスナップショットへの復元を日常的なロールバックにしません。復元が必要な場合は、バックアップ製品、ハイパーバイザー、Active Directoryの公式ガイダンスに従い、復元後にセキュアチャネルを検査します。
共通障害を監視する
DNS、時刻、ADレプリケーション、重複コンピューター名、スナップショットやイメージ復元履歴を監視します。完全にDCへ到達できない長期オフライン自体では、通常、機械アカウントの不整合になりません。ただし、オフライン端末を削除・無効化する運用、またはDCへの部分的・断続的な通信がある場合は別です。同一拠点で複数件が発生したら、端末ごとの再参加ではなくDCとネットワークを調査します。イベントログと発生時刻を残すと、どのDCとの通信で不一致が起きたかを追いやすくなります。
よくある質問
ネットワークケーブルを抜く必要はありますか
ローカルアカウントを使うための必須条件ではありません。.\LocalAdminのようにサインイン先を明示します。診断にはDNSやDCへの通信が必要なので、通常は接続を維持します。
ドメインから抜ければ必ず直りますか
必ずではありません。DNS、DC、レプリケーションが原因なら再参加も失敗します。さらに管理・証明書・接続状態へ影響するため、インプレース修復を先に行います。
ADのコンピューターアカウントを削除してよいですか
標準手順として削除しません。グループ所属、委任、管理情報を失う可能性があります。リセットやセキュアチャネル修復を優先し、削除は影響を把握したAD管理者だけが判断します。
Domain Adminで修復すれば早いですか
高権限資格情報を障害端末へ入力するリスクが大きいため推奨しません。必要な操作だけを委任した専用アカウントを使います。
Test-ComputerSecureChannelをDCで使えますか
使いません。ドメインコントローラーでは偽の失敗を返すことがあります。DCのセキュアチャネルはnetdomやnltestなど、MicrosoftがDC向けに案内する方法で管理者が診断します。
パスワード変更間隔を長くすれば再発しませんか
再発防止にならず、セキュリティを弱めます。既定約30日を維持し、レプリケーション、古いスナップショット、複製を見直します。完全にDCへ到達できない長期オフライン自体では通常不整合になりません。ただし、オフライン端末を削除・無効化する運用、またはDCへの部分的・断続的な通信がある場合は別です。
公式情報
- Microsoft Learn：Join a computer to a domain
- Microsoft Learn：Test-ComputerSecureChannel
- Microsoft Learn：Reset-ComputerMachinePassword
- Microsoft Learn：netdom reset
- Microsoft Learn：Domain member maximum machine account password age
- Microsoft Tech Community：Secure Channel/Expired Machine Account Password Concerns – Revisited
まとめ
ドメイン参加PCの信頼関係エラーでは、ローカル管理者と回復手段を確保し、DNS・時刻・DC到達性を確認してからTest-ComputerSecureChannelで検査します。Falseなら-Repair、Reset-ComputerMachinePassword、netdom resetの順に、ドメイン離脱をせず修復します。再参加は最後の手段です。ADオブジェクト削除、認証回避、Domain Adminの常用、機械アカウントパスワード変更の無効化を避け、複製・スナップショット・レプリケーションの根本原因を管理してください。
コメント