Active Directoryで壊れたセキュアチャネルをPowerShellで見つける最短ルートは、メンバーサーバーやクライアントで Test-ComputerSecureChannel -Verbose を実行することです。結果が True なら少なくともその端末とドメインの関係は生きており、False なら信頼関係の破損を疑えます。複数のドメイン コントローラーがある環境では -Server で確認先DCを固定すると切り分けが速くなります。なお、このコマンドはドメイン コントローラーでは誤検知になるため、DCだけは netdom verify や nltest に切り替えるのが正解です。 (Microsoft Learn)
セキュアチャネルの問題は、単に「ログオンできない」で終わりません。原因がネットワーク断なのか、コンピューター アカウント パスワードの不一致なのか、あるいはADレプリケーションの乱れなのかで、打つべき手が変わります。この記事では、PowerShellでの見つけ方を軸に、実行前の前提条件、複数台の調査方法、失敗しやすいポイント、修復の順番、そしてPowerShellでは扱いにくいDCの代替手順まで、実務で迷わない形に整理します。 (Microsoft Learn)
セキュアチャネルが壊れると何が起きるのか
ドメイン参加しているWindowsデバイスは、それぞれがコンピューター アカウントとパスワードを持ち、既定では約30日ごとにそのパスワードを変更します。これがドメイン コントローラー側の認識とズレると、端末とドメインの信頼関係が崩れ、「The trust relationship between this workstation and the primary domain failed.」 のようなエラーや、NETLOGON の Event ID 3210 が出ることがあります。ドメイン資格情報でサインインできなくても、ローカルユーザーやキャッシュされた資格情報では入れる場合があるのも典型的な症状です。 (Microsoft Learn)
まず使うコマンドを間違えない
| 対象 | 最初に使う方法 | 使いどころ |
|---|---|---|
| メンバーサーバー / クライアント | Test-ComputerSecureChannel -Verbose | ローカル コンピューターとドメインの関係を True / False で素早く確認できます。必要なら -Server で確認先DCを固定できます。 (Microsoft Learn) |
| メンバーサーバー / クライアントの修復 | Test-ComputerSecureChannel -Repair または Reset-ComputerMachinePassword | まず軽く直すなら -Repair、それで戻らないならコンピューター アカウント パスワードの再設定に進みます。 (Microsoft Learn) |
| ドメイン コントローラー | netdom verify / nltest /sc_query:<DomainName> | Test-ComputerSecureChannel はDCでは誤検知があるため不向きです。 (Microsoft Learn) |
実行前に押さえたい前提条件
Test-ComputerSecureChannel はドメイン メンバー コンピューター専用です。つまり、メンバーサーバーやクライアントの確認には向いていますが、DCの確認には使いません。さらに、Microsoftのトラブルシュートでは、確認や修復は管理者権限のPowerShellで行う前提になっています。ドメイン資格情報で入れない場合は、ローカル管理者またはキャッシュ済み資格情報でログオンして作業するのが現実的です。 (Microsoft Learn)
また、Test-ComputerSecureChannel の構文には -ComputerName がなく、対象はあくまでその場で実行しているローカル コンピューターです。複数台を一括確認したい場合は、各端末上で実行させる必要があるため、PowerShell Remoting の Invoke-Command を使う構成にします。Invoke-Command は複数台への同時実行に対応しており、PowerShell Remoting は Windows Server 2012 以降で既定有効です。必要なら Enable-PSRemoting で受信設定を有効化します。 (Microsoft Learn)
単体のサーバーやPCで壊れたセキュアチャネルを見つける手順
まず、どのDCを見ているかと疎通を確認する
最初に、端末が見ているログオン サーバーと基本的な通信を確認します。疎通がないのにセキュアチャネル修復へ進むと、原因の切り分けがぼやけます。
set | find /i "LOGONSERVER"
Test-Connection -ComputerName "dc01.contoso.local" -Count 2Microsoftのトラブルシュートでも、まず LOGONSERVER を確認し、そのDCへの接続性を Test-Connection などで確認する流れが案内されています。ここで通信に失敗するなら、壊れているのはセキュアチャネル以前に、DNS・ネットワーク経路・ファイアウォール・対象DCの健全性の可能性があります。 (Microsoft Learn)
PowerShellでセキュアチャネルを確認する
単体確認なら、まずはこれで十分です。
Test-ComputerSecureChannel -VerboseTest-ComputerSecureChannel は、ローカル コンピューターとドメイン間のチャネルを確認し、正常なら True、問題があれば False を返します。-Verbose を付けると、「どの相手に対して確認したか」「セキュアチャネルが生きているか」といったメッセージが出るため、実運用ではほぼ付けた方が分かりやすいです。 (Microsoft Learn)
複数DCがあるなら、確認先DCを固定する
「あるときだけ失敗する」「DCによって挙動が違う」と感じるなら、確認先DCを固定して見ます。
Test-ComputerSecureChannel -Server "dc01.contoso.local" -Verbose-Server を使うと、確認先のDCを明示できます。通常のテストで True でも、特定DCを固定すると問題が出るなら、そのDC側の健全性やレプリケーション、DNS登録の偏りを疑った方が早いです。 (Microsoft Learn)
複数台をPowerShellで洗い出す方法
複数台を見つけたいときは、各端末で Test-ComputerSecureChannel を実行させる形にします。以下は、指定したDCに対して複数台を順番に検査する例です。
$computers = @(
'APP01',
'FILE01',
'WEB01'
)
$dc = 'dc01.contoso.local'
$cred = Get-Credential
Invoke-Command -ComputerName $computers -Credential $cred -ScriptBlock {
param($PreferredDC)
try {
$ok = Test-ComputerSecureChannel -Server $PreferredDC -Verbose:$false -ErrorAction Stop
[pscustomobject]@{
ComputerName = $env:COMPUTERNAME
PreferredDC = $PreferredDC
SecureChannel = if ($ok) { 'OK' } else { 'Broken' }
}
}
catch {
[pscustomobject]@{
ComputerName = $env:COMPUTERNAME
PreferredDC = $PreferredDC
SecureChannel = 'CheckFailed'
Error = $_.Exception.Message
}
}
} -ArgumentList $dc | Sort-Object SecureChannel, ComputerNameこの形が実務向きなのは、Test-ComputerSecureChannel 自体がローカル対象だからです。Invoke-Command は複数台のリモート実行に対応しており、サーバー系なら PowerShell Remoting が既定で有効なケースが多いため、そのまま運用に載せやすい方法です。逆に CheckFailed が多いときは、壊れているのがセキュアチャネルではなく、WinRM設定・権限・対象がオフラインといった別問題の可能性があります。 (Microsoft Learn)
PowerShell Remoting を使えない環境では、PowerShell一本にこだわらない方が早いこともあります。たとえば netdom query /domain:contoso.local SERVER /verify を使えば、列挙したサーバーのセキュアチャネル シークレットをまとめて検証できます。PowerShellではありませんが、中央から俯瞰したい場面の代替策として覚えておく価値があります。 (Microsoft Learn)
結果の読み方で判断を誤らない
| 結果 | 意味 | 次にやること |
|---|---|---|
True | 少なくとも、確認した関係ではセキュアチャネルは生きています。 (Microsoft Learn) | それでも症状があるなら、特定DCを -Server で固定し、DC側の健全性やレプリケーションも見ます。 (Microsoft Learn) |
False | 信頼関係の破損やコンピューター アカウント パスワード不一致を疑います。 (Microsoft Learn) | まず疎通とAD側の正常性を確認し、その後に -Repair か Reset-ComputerMachinePassword を使います。 (Microsoft Learn) |
CheckFailed | スクリプト上の判定失敗です。 | WinRM、権限、対象の起動状態、ローカル/ドメイン認証の可否を切り分けます。 |
特に重要なのは、False を見た瞬間に直しに行かないことです。根本原因がネットワーク断やADレプリケーション不整合なら、端末側だけ修復しても再発したり、別のDCへ当たったときに同じ問題が出たりします。 (Microsoft Learn)
修復前に切り分けたい典型原因
| 典型原因 | 見えやすい兆候 | 先に確認すること |
|---|---|---|
| 古いVMスナップショットへのロールバック | システムログの時刻が飛ぶ、稼働履歴に不自然な空白がある。 (Microsoft Learn) | 端末の時系列、起動履歴、AD側の pwdLastSet とのズレを疑います。 |
| ADレプリケーションの問題、バックアップから復旧したDC | DCによって成功/失敗が分かれる、クライアント側だけ直しても安定しない。 (Microsoft Learn) | AD側を先に正常化します。Microsoftも、AD側の問題はクライアントだけでは解決できないと案内しています。 (Microsoft Learn) |
| ネットワーク断、DNSずれ、DC不達 | LOGONSERVER は分かるが疎通しない、DC名指定でだけ失敗する。 (Microsoft Learn) | まずネットワーク経路とDNSを直してから再確認します。 |
ここで押さえたいのは、セキュアチャネル破損は結果であって原因ではないことがあるという点です。特に仮想基盤で「戻せば何とかなる」と考えて古いスナップショットへ戻すと、かえってコンピューター アカウント パスワードの不一致を広げることがあります。戻し方を安易に「スナップショットへ戻す」にしない方が安全です。 (Microsoft Learn)
壊れていた場合の直し方
まずは -Repair を試す
疎通とAD側の正常性に問題がないなら、最初は Test-ComputerSecureChannel -Repair が最短です。
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)Microsoftのトラブルシュートでも、AD側の問題を解消したあとに Test-ComputerSecureChannel -Repair を実行し、その後に再起動して確認する流れが案内されています。資格情報が必要な環境では -Credential を付けておく方が安全です。 (Microsoft Learn)
戻らないなら、コンピューター アカウント パスワードをリセットする
-Repair で戻らない場合は、ローカル コンピューターのコンピューター アカウント パスワードを再設定します。
Reset-ComputerMachinePassword -Server "dc01.contoso.local" -Credential (Get-Credential)Reset-ComputerMachinePassword は、端末がドメイン コントローラーへの認証に使うコンピューター アカウント パスワードを変更するコマンドです。現在のユーザー資格情報でも実行できますが、運用では -Server で対象DCを固定し、必要に応じて -Credential を明示した方が切り分けしやすくなります。 (Microsoft Learn)
最後の手段は、ドメイン離脱と再参加
修復もパスワード再設定も効かないなら、最後の手段としてドメイン離脱と再参加を検討します。Microsoftの案内でも、-Repair や Reset-ComputerMachinePassword で復旧しない場合の最終手段として、ドメイン再参加が位置付けられています。つまり、実務でいう「戻し方」は、修復を元に戻すことよりも、再参加で状態を作り直せるように準備しておくことです。 (Microsoft Learn)
ドメイン コントローラーだけはPowerShellの流儀を変える
DCで Test-ComputerSecureChannel を使うのは避けます。Microsoft Learn でも、DCでは誤検知が返るため、確認やリセットには netdom.exe または nltest.exe を使うよう明記されています。 (Microsoft Learn)
確認の基本は次のいずれかです。
netdom verify DC01 /domain:contoso.local
nltest /sc_query:contoso.localnetdom verify は、指定したコンピューターとDCの間のセキュアチャネルを検証するコマンドで、管理者特権のコマンド プロンプトから実行します。nltest /sc_query でもセキュアチャネルの状態確認が可能です。 (Microsoft Learn)
DCの修復が必要なら、netdom resetpwd を問題が出ているDC上で、管理者特権のコマンド プロンプトから実行します。
netdom resetpwd /server:DC02 /userd:contoso\administrator /passwordd:*netdom resetpwd はDCのマシン アカウント パスワード、つまりDCのセキュアチャネル パスワードをリセットするためのコマンドです。レプリケーションの失敗や Access is denied が絡む場合は、Microsoftは DCDIAG /TEST:CheckSecurityError やレプリケーション確認も併せて案内しています。DCの問題をメンバーサーバーと同じ感覚で片付けないことが重要です。 (Microsoft Learn)
失敗しやすいポイント
| ありがちな失敗 | なぜ危ないか | 実務での対処 |
|---|---|---|
DCにも Test-ComputerSecureChannel を使う | 誤検知の可能性があります。 (Microsoft Learn) | DCは netdom verify / nltest に切り替えます。 |
疎通未確認のまま -Repair を打つ | ネットワーク断やDC不達が原因だと空振りしやすいです。 (Microsoft Learn) | 先に LOGONSERVER と Test-Connection を確認します。 |
| ADレプリケーション不整合を放置して端末だけ直す | AD側が不整合のままだと再発しやすいです。 (Microsoft Learn) | まずDC側の正常化を優先します。 |
| 古いスナップショットへ安易に戻す | コンピューター パスワードのズレを広げる原因になります。 (Microsoft Learn) | 時系列確認とAD側の整合性確認を先に行います。 |
| いきなりドメイン再参加する | 直ることはありますが、原因を見失います。 (Microsoft Learn) | -Repair → パスワード再設定 → 再参加、の順で進めます。 |
迷ったときは、この順番で進めれば外しにくい
まず、対象がメンバーサーバー/クライアントなのか、DCなのかを分けます。メンバー側なら、管理者権限のPowerShellで LOGONSERVER と疎通を見てから Test-ComputerSecureChannel -Verbose を実行します。複数台なら Invoke-Command で各端末上に実行させます。False が出ても、ネットワークやADレプリケーションが怪しいなら、先にそこを直します。問題がなければ -Repair、だめなら Reset-ComputerMachinePassword、それでも戻らなければ再参加です。DCなら最初から netdom verify や nltest に切り替えます。 (Microsoft Learn)
今すぐ1台を確認したいなら、最初の一手はこれで十分です。
Test-ComputerSecureChannel -Verbose複数台の調査に進むのは、その1台で「何が壊れているのか」の見え方を掴んでからで遅くありません。Active Directoryで壊れたセキュアチャネルをPowerShellで見つけるときは、コマンド自体よりも、対象の種類と修復の順番を間違えないことが、最短で復旧するいちばんの近道です。 (Microsoft Learn)
コメント