ドメイン参加PCで信頼関係エラーが出たときは、最初からワークグループへ離脱しないでください。承認済みのローカル管理者でサインインし、DNS、時刻、ドメインコントローラーへの到達性を確認したうえで、Test-ComputerSecureChannelを使ってセキュアチャネルを検査します。Falseでも原因をパスワード不一致と即断せず、通信・ADオブジェクト・権限を切り分けます。不一致が疑われる場合に、承認された範囲で-Repairまたはコンピューターアカウントパスワードのリセットを検討します。
ドメイン離脱・再参加は最後の手段です。先に離脱すると、有効なローカル管理者がない、BitLocker回復キーがない、証明書ベースのWi-FiやVPNへ接続できない、Intuneなどの管理状態を失う、といった別の問題を起こす可能性があります。Active Directoryのコンピューターオブジェクト削除や、回復環境を使った認証回避も標準手順にしてはいけません。
対象はオンプレミスActive Directory Domain Services（AD DS）のメンバーPC・メンバーサーバーです。ドメインコントローラー（DC）、Microsoft Entra IDへの参加のみの端末、ワークグループ端末には、この修復手順をそのまま適用しません。Windows PowerShell 5.1を管理者として開き、対象端末自身で作業します。サーバーの再起動はサービス停止を伴うため、保守時間と復旧経路を先に確保してください。
エラーメッセージで最初の分岐を決める
| 表示・症状 | 考えられる範囲 | 最初の確認 |
|---|---|---|
| このワークステーションとプライマリドメインとの信頼関係に失敗しました | コンピューターアカウントと端末側秘密情報の不一致 | 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はセキュアチャネルの検査が成功しなかった結果であり、原因の確定ではありません。エラー本文、対象DC、イベントログを確認し、名前解決や接続の失敗と、機械アカウントの不整合を区別してください。
信頼関係が壊れる仕組み
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. セキュアチャネルを検査する
まず次の読み取りで対象端末名・参加先・役割を確認します。DomainRoleが1はメンバーPC、3はメンバーサーバーです。4または5はDCなのでここで止め、DC向けの診断をAD管理者へ依頼します。PartOfDomainがFalse、または参加先が想定と違う場合も修復へ進みません。
Get-CimInstance -ClassName Win32_ComputerSystem |
Select-Object Name, Domain, PartOfDomain, DomainRole対象が確認できたら、セキュアチャネルを検査します。例外はFalseと同一視せず、そのエラーを先に調べます。
Test-ComputerSecureChannel -Verbose -ErrorAction StopTrueなら、その検査で使用したDCとのセキュアチャネルは正常です。すべてのDCやユーザーログオンの正常性を保証する結果ではありません。ワークグループへ離脱せず、DNS、ネットワーク、DC選択、ユーザー資格情報、ログオン権限を調査します。FalseならDNS・到達性・時刻・ADオブジェクトの存在を再確認し、不整合が疑われる場合に次の修復を検討します。このコマンドはドメインコントローラー上では偽の失敗を返すことがあるため、DCの検査には使用しません。
3. ドメイン離脱をせずに修復する
ローカル管理者権限で昇格したWindows PowerShellと、対象ADコンピューターアカウントの修復権限を持つ資格情報の両方が必要です。対象PC自身で、例のドメイン名とアカウント名を実環境へ置き換えて実行します。資格情報が不明なら推測して繰り返し入力せず、アカウントロックを避けるため管理者へ確認します。侵害の疑いがある端末には高権限資格情報を入力しません。
$cred = Get-Credential 'CONTOSO\DelegatedRepairAccount'
if ($null -eq $cred) { throw '資格情報の入力がキャンセルされました。' }
$repaired = Test-ComputerSecureChannel -Repair -Credential $cred -Verbose -ErrorAction Stop
if (-not $repaired) { throw '修復は成功していません。エラーと接続条件を調査してください。' }
Test-ComputerSecureChannel -Verbose -ErrorAction Stop修復後にTrueを確認したら、別のリセットを追加で実行する必要はありません。未保存作業を保存し、必要な通常再起動は承認された保守時間に実施します。再起動する場合はローカル管理者で再び入れることを確認してから行い、再起動後のセキュアチャネルと一般のドメインユーザーのサインインも確認します。成功表示だけで再参加へ進まず、Falseや例外が残れば原因調査へ戻ります。
4. コンピューターアカウントパスワードをリセットする
-Repairが失敗しても、無条件に次の変更を重ねません。DNS・時刻・DC到達性・修復権限・ADオブジェクトを確認し、機械アカウントの不整合が残る場合に、管理者の判断でパスワードリセットを代替として使います。これは実行しているローカル端末のパスワードを変更するコマンドで、-Serverは修復対象PCではなく書き込み先のDCです。正常な書き込み可能DCを管理者が確認して指定します。
$cred = Get-Credential 'CONTOSO\DelegatedRepairAccount'
if ($null -eq $cred) { throw '資格情報の入力がキャンセルされました。' }
Reset-ComputerMachinePassword -Server 'dc01.contoso.com' -Credential $cred -ErrorAction Stop
Test-ComputerSecureChannel -Server 'dc01.contoso.com' -Verbose -ErrorAction StopReset-ComputerMachinePasswordは通常、成功時に結果オブジェクトを出力しません。無出力だけで成功とせず、直後の検査と、保守時間に通常再起動した後のTest-ComputerSecureChannelで確認します。複数DCがあり、あるDCでは成功し別のDCでは失敗する場合、何度もパスワードを変える前にADレプリケーションとサイト構成を調査します。
5. netdom resetを代替として使う
AD DS管理ツールまたはRSATが利用できる場合、netdom resetも代替です。以下は修復対象のメンバーPC自身の、管理者コマンドプロンプト（cmd.exe）で実行する例です。%COMPUTERNAME%はコマンドを実行している端末名なので、管理端末からそのまま使うと別端末を対象にしてしまいます。/useroは対象コンピューターへの接続に使うアカウントです。AD側の委任だけで足りると考えず、対象端末への必要な権限も確認します。パスワードは直書きせず、*で入力を求めます。
netdom reset %COMPUTERNAME% /domain:contoso.com /server:dc01.contoso.com /usero:CONTOSO\DelegatedRepairAccount /passwordo:*netdomが見つからないPCへ非公式サイトから実行ファイルをコピーしてはいけません。管理端末を使う場合は、対象名を明示し、その接続権限を確認した別手順として扱います。終了メッセージと終了コードを確認し、失敗時は止めます。成功後にセキュアチャネルを再検査し、再起動が必要なら保守時間に行います。netdom resetと、DCの機械パスワード復旧で使うnetdom resetpwdは同じコマンドではありません。
6. 再参加は影響と復旧経路を確認してから
再参加は有効な復旧方法ですが、すべてのリセットコマンドを順番に実行することが前提ではありません。インプレース修復が適用できない・解決しない理由を管理者が確認し、DNS、時刻、DC、レプリケーションを整えてから検討します。離脱前にローカル管理者のサインインを実際に確認し、回復キー、参加権限、証明書、VPN、MDM、ユーザープロファイルへの影響を記録します。ドメイン認証だけに頼るリモート接続しかない場合は、現地または承認済みの別アクセス手段を確保するまで離脱・再起動しません。
ADのコンピューターオブジェクトは、単に削除して作り直すのではなく、所属OU、グループ、委任、証明書、自動展開との関係を管理者が確認します。既存オブジェクトを再利用できる場合は削除を避け、必要なリセット・再参加を一連の承認済み手順で行います。AD管理ツールでオブジェクトをリセットするだけでは、端末側の秘密情報まで同期されるわけではありません。再参加後は、正しいOU、グループポリシー、管理エージェント、証明書、ネットワーク接続を確認してください。
再参加では、既存のコンピューターアカウントを再利用する際のセキュリティ強化（KB5020276）により、権限があるように見えても拒否される場合があります。0xaacやNERR_AccountReuseBlockedByPolicyが出たら、C:\Windows\Debug\netsetup.logと既存オブジェクトの所有者・再利用ポリシーをAD管理者が確認します。先に離脱してから考えるのではなく、再利用条件を事前確認してください。古いNetJoinLegacyAccountReuseレジストリによる回避は現在サポートされず、Domain Adminへの昇格やオブジェクト削除で安易に回避しません。
修復できない場合の分岐
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へ流用しません。DCの診断・復旧はAD管理者が担当し、MicrosoftのDC専用手順で、正常な相手DC、レプリケーション、KDC、Kerberosチケット、再起動の影響を確認します。単にコマンド名をnetdomへ変えるだけでは十分ではありません。
パスワード変更間隔を長くすれば再発しませんか
再発防止にならず、セキュリティを弱めます。既定約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
追加確認日：2026年10月20日。以下の公式資料を含め、コマンドの対象・引数と再参加時の制約を確認しました。
- Microsoft Learn：メンバー端末の信頼関係障害の切り分け
- Microsoft Learn：DCの機械アカウントパスワード復旧（本記事とは別手順）
- Microsoft Support：KB5020276と既存コンピューターアカウント再利用
- Microsoft Learn：Win32_ComputerSystemのDomainRole
まとめ
ドメイン参加PCの信頼関係エラーでは、ローカル管理者と回復手段を確保し、DNS・時刻・DC到達性を確認してからTest-ComputerSecureChannelで検査します。Falseや例外の原因を切り分け、対象と権限を確認したうえで-Repairを検討します。Reset-ComputerMachinePasswordやnetdom resetは代替手段で、成功後にすべて実行する必要はありません。再参加は最後の手段です。ADオブジェクト削除、認証回避、Domain Adminの常用、機械アカウントパスワード変更の無効化を避け、複製・スナップショット・レプリケーションの根本原因を管理してください。
コメント