Netlogonのセキュアチャネルをコマンドで確認したいなら、まずそのサーバーがメンバーサーバー/クライアントなのか、ドメイン コントローラーなのかを分けて考えるのが最短です。メンバーサーバーやクライアントなら Test-ComputerSecureChannel と nltest /sc_query:<ドメイン名> が使いやすく、ドメイン コントローラーなら netdom verify を軸にすると判断を誤りにくくなります。特に Test-ComputerSecureChannel はドメイン メンバー向けで、DC では誤検知を返すことがあるため、ここを取り違えないのが最重要です。 (Microsoft Learn)
この記事では、Netlogonのセキュアチャネルを確認だけで終えるコマンド、修復まで進むコマンド、実行前の前提条件、失敗しやすいポイント、戻し方や代替策まで、実務でそのまま使える形に整理します。 (Microsoft Learn)
Netlogonのセキュアチャネルとは何を見ているのか
セキュアチャネルは、コンピューターとドメイン コントローラーが認証情報をやり取りするための保護された通信経路です。ここが壊れると、ドメイン資格情報でサインインできなくなったり、NETLOGON の Event ID 3210 が出たりします。壊れていても、ローカル ユーザーやキャッシュ済み資格情報では入れることがあります。 (Microsoft Learn)
原因として多いのは、ローカル側のコンピューター パスワードと Active Directory 側の値がずれた状態です。Microsoft のトラブルシューティングでは、クライアント/メンバーサーバー側のパスワードが古い場合と、逆に AD 側のパスワードが古い場合の両方があり、後者は DC を過去状態に戻したケースや AD レプリケーション問題でも起こり得ると整理されています。イベント メッセージ上は、同名の別コンピューターがネットワーク上にいる場合も候補になります。 (Microsoft Learn)
最初に分けるべきなのは「メンバー」か「DC」か
Test-ComputerSecureChannel はローカル コンピューターとドメインの間のチャネルをテストし、正常なら True、異常なら False を返します。ただし Microsoft は、このコマンドレットはドメイン メンバー コンピューターでのみ機能し、DC で実行すると誤検知エラーを返すと明記しています。DC の確認は netdom.exe または nltest.exe を使う前提で考えるのが安全です。 (Microsoft Learn)
この切り分けを最初にやっておくと、「PowerShell で False が出たから壊れている」と早合点する事故を防げます。現場で一番多いハマりどころは、実はコマンドの使い分けミスです。 (Microsoft Learn)
実行前に確認したい前提条件
Netlogon サービスは、コンピューターが Active Directory に参加しているときだけ動作します。Microsoft Entra ID のみに参加している端末では動きません。つまり、そもそも AD 参加でないマシンで Netlogon のセキュアチャネル確認をしても、対象外です。 (Microsoft Learn)
また、netdom verify や netdom reset、netdom resetpwd は、管理者特権のコマンド プロンプトが前提です。netdom は AD DS 役割が入っているサーバー、または RSAT の AD DS ツールが入った端末で使えます。コマンドが見つからない場合は、まずここを疑ってください。 (Microsoft Learn)
ドメイン資格情報でログオンできない状態でも、Microsoft の案内どおり、ローカル アカウントやキャッシュ済み資格情報では入れることがあります。確認や修復に進むときは、まずその方法でサインインできるかを見ます。 (Microsoft Learn)
最初の一手は Netlogon サービスの状態確認
sc query netlogon
sc qc netlogonsc query netlogon はサービス状態の確認、sc qc netlogon は依存関係の確認に使います。Netlogon が起動していない、あるいは依存サービスで止まっているなら、セキュアチャネル以前の問題です。Microsoft は Netlogon の依存関係として Workstation などを挙げており、DC で Netlogon が Paused だと DC Locator 要求に応答せず、NTLM や新しい Kerberos チケットにも使われません。 (Microsoft Learn)
Test-ComputerSecureChannel と NetDom はどちらも NetLogon サービスを使って動作するため、Netlogon が正常でない状態では結果の読み違いが起きやすくなります。先にサービスを見るのが実務では安定です。 (Microsoft Learn)
メンバーサーバー・クライアントで確認する方法
まずは PowerShell で素直に確認する
Test-ComputerSecureChannel -Verboseこのコマンドはローカル コンピューターと参加ドメインの間のチャネルをテストし、正常なら True、異常なら False を返します。-Verbose を付けると、単なる真偽値だけでなく、どの対象に対してチェックしたかも見やすくなります。特定の DC を見たいときは -Server "DC01.contoso.com" のように指定できます。 (Microsoft Learn)
True が返るのにログオンや名前解決で問題が続くなら、Microsoft のガイダンスどおり、DNS や別のネットワーク要因を疑うべき場面です。セキュアチャネルが正常でも、別レイヤーで失敗しているケースはあります。 (Microsoft Learn)
Netlogon 寄りに状態を見たいなら nltest /sc_query
nltest /sc_query:contoso.com/sc_query は、最後に使われたセキュアチャネルの状態を報告し、あわせて問い合わせた DC 名も表示します。Trusted DC Name を見たいときや、「どの DC を相手にしているのか」を素早く把握したいときに便利です。 (Microsoft Learn)
ここで大事なのは、/sc_query は確認専用だという点です。修復はしません。リアルタイム診断の主軸としては Test-ComputerSecureChannel や netdom verify と併用し、nltest /sc_query は DC 名と状態の見取り図を出すコマンドだと考えると混乱しません。 (Microsoft Learn)
コマンド プロンプトだけで済ませたいなら netdom verify
netdom verify SERVER01 /domain:contoso.comnetdom verify は、指定したコンピューターとドメイン コントローラーの間のセキュアチャネルを確認するコマンドです。PowerShell を使わずに確認したいときや、後で同じ流れで netdom reset まで進みたいときに相性がいいコマンドです。管理者特権のコマンド プロンプトが必要で、利用には AD DS 役割または RSAT の AD DS ツールが前提です。 (Microsoft Learn)
Trusted DC Name が怪しいときは nltest /dsgetdc
nltest /dsgetdc:contoso.comこれは DNS に問い合わせて DC を見つけ、接続性も確認するコマンドです。nltest /sc_query で Trusted DC Name が空になる、想定外の DC を向いている、そもそも DC を見つけられていない気配がある、というときに使うと、パスワード不整合なのか、DC 発見/DNS 側なのかを切り分けやすくなります。 (Microsoft Learn)
ドメイン コントローラーで確認する方法
DC では Test-ComputerSecureChannel を基準にしません。ここは迷わず netdom verify を使うほうが安全です。 (Microsoft Learn)
netdom verify DC02 /domain:contoso.comDC02 は確認したい DC のコンピューター名です。/domain: を省略すると現在のコンピューターが属するドメインを使いますが、切り分け中は明示したほうがログを読み返しやすくなります。 (Microsoft Learn)
補助的な確認として、Microsoft Defender for Identity のガイダンスでは、パスワード同期の検証に nltest /SC_VERIFY:<ドメインNetBIOS名> を使い、NERR_Success が出ることを確認する手順も案内されています。NetBIOS 名が分かっているなら、DC 側の補助チェックとして有効です。 (Microsoft Learn)
nltest /SC_VERIFY:CONTOSOCONTOSO には DNS 名ではなく、ドメインの NetBIOS 名を入れるのが Defender for Identity 側の説明です。NetBIOS 名が曖昧な環境では、まず netdom verify を先に使うほうが無難です。 (Microsoft Learn)
出力の読み方で間違えやすいポイント
Test-ComputerSecureChannel は、True ならセキュアチャネル正常、False なら異常または検証失敗と考えて構いません。確認だけが目的なら -Verbose を付け、結果をそのまま記録に残すと後から見返しやすくなります。 (Microsoft Learn)
nltest /sc_query は、最後に使われたチャネル状態を見るコマンドなので、今この瞬間の完全な総合診断というより、直近の状態と相手 DC を見る用途に向きます。ここを見落とすと、「さっきネットワークを直したのに表示が変だ」と感じやすくなります。 (Microsoft Learn)
実務で特に誤解されやすいのが、nltest /sc_query の出力に ERROR_ACCESS_DENIED が出ているのに、最後に The command completed successfully と表示されるケースです。Microsoft のトラブルシューティング例でもこの組み合わせが示されており、成功したのはコマンド実行そのものであって、セキュアチャネルが正常という意味ではありません。 (Microsoft Learn)
失敗しやすいポイント
- DC で
Test-ComputerSecureChannelを基準にしてしまうこと。 これは Microsoft が誤検知ありと明記している代表的な落とし穴です。 (Microsoft Learn) - 確認コマンドと修復コマンドを混同すること。
nltest /sc_queryとnetdom verifyは確認、nltest /sc_resetとnetdom reset、Test-ComputerSecureChannel -Repairは状態変更を伴います。確認だけしたいのに修復コマンドを打つと、切り分けログが汚れます。 (Microsoft Learn) netdomがないのにコマンド例だけ追うこと。netdomは AD DS 役割または RSAT の AD DS ツールが前提です。見つからないときは、Secure Channel の異常ではなく実行環境不足です。 (Microsoft Learn)- DNS/DC 発見の問題を見落とすこと。
Test-ComputerSecureChannelがTrueなら別原因の可能性があり、nltest /dsgetdcで DC 検出と接続性も確認したほうが早い場面があります。 (Microsoft Learn) - 根本原因を直さず再参加だけで終えること。 再参加は有効な解決策ですが、DC 復元や AD レプリケーション問題が背景にあると再発します。 (Microsoft Learn)
修復しても再発するときに見るべき設定場所
Microsoft は、繰り返すセキュアチャネル問題の確認項目として、コンピューター名関連のレジストリ値が実際のコンピューター名であり、FQDN ではないことを挙げています。名前ずれがあると、表面的に修復してもまた壊れます。 (Microsoft Learn)
Reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName /v ComputerName
Reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters /v hostname上の 2 つは、ComputerName と hostname を直接確認するコマンドです。結果が実機のコンピューター名と一致しているか、FQDN になっていないかを見てください。Secure Channel の修復コマンドばかり追うより、ここを見たほうが早く原因に当たることがあります。 (Microsoft Learn)
修復が必要なときのコマンド
メンバーサーバー・クライアントなら、まずは -Repair
Test-ComputerSecureChannel -RepairPowerShell でそのまま直すなら、最初の候補はこれです。Test-ComputerSecureChannel は -Repair を付けると、ローカル コンピューターとドメインの間のチャネル復元を試みます。特定 DC を指定したい、または資格情報を明示したいなら、次のようにします。 (Microsoft Learn)
Test-ComputerSecureChannel -Repair -Server "DC01.contoso.com" -Credential (Get-Credential)PowerShell で修復した後は、再度 Test-ComputerSecureChannel -Verbose を実行して結果を見直すと、確認と修復が一本化できます。 (Microsoft Learn)
コマンド プロンプトで直したいなら netdom reset
netdom reset SERVER01 /domain:contoso.comnetdom reset は、ワークステーションと DC の間のセキュア接続をリセットするコマンドです。PowerShell を使いたくない現場や、netdom verify から同じ系統で続けたいときに扱いやすい方法です。特定 DC に張り替えたいときは /Server: も指定できます。 (Microsoft Learn)
Netlogon 寄りに再構築するなら nltest /sc_reset
nltest /sc_reset:contoso.com/sc_reset は、Netlogon が張っているセキュアチャネルを削除して再構築します。こちらは管理者権限が必要です。nltest /sc_query と名前が似ていますが、こちらは修復コマンドです。確認だけのつもりで打たないようにしてください。 (Microsoft Learn)
コンピューター アカウント パスワードを直接戻す代替策
Reset-ComputerMachinePassword -Server "DC01" -Credential (Get-Credential)Reset-ComputerMachinePassword は、コンピューターがドメイン コントローラーと認証するために使うコンピューター アカウント パスワードを変更します。Test-ComputerSecureChannel -Repair で戻らないときの代替策として有効です。なお、このコマンドは出力を返さないので、実行後に Test-ComputerSecureChannel -Verbose などで再確認するのが実務的です。 (Microsoft Learn)
ドメイン コントローラーは netdom resetpwd を使う
netdom resetpwd /Server:DC01.contoso.com /UserD:CONTOSO\Admin /PasswordD:*netdom resetpwd は、DC のマシン アカウント パスワードをリセットするコマンドです。問題のある DC 自身で実行する必要があり、リモート マシンやメンバーサーバーのリセットには使えません。DC の修復はこれを軸に考えるとブレません。 (Microsoft Learn)
修復後は、netdom verify <DC名> /domain:contoso.com または nltest /SC_VERIFY:CONTOSO で検証をやり直します。特に DC は、直したつもりで AD レプリケーションや DC 発見側の問題を残しやすいので、確認の打ち直しまでを 1 セットで考えるのが安全です。 (Microsoft Learn)
それでも直らないときの最終手段は「再参加」
Microsoft も、壊れたセキュアチャネルに対してドメインから外して再参加する方法は有効だと案内しています。ただし、同時に「繰り返す問題なら根本原因の調査が必要」とも明記しています。つまり、一度だけ早く戻したいなら再参加、何度も起きるなら原因調査という切り分けが実務的です。 (Microsoft Learn)
メンバーサーバーやクライアントを再参加させるなら、ローカル アカウントで入り直し、いったんドメインから外してから再参加します。コマンドでやるなら次の形です。 (Microsoft Learn)
netdom remove %COMPUTERNAME% /domain:contoso.com /userd:CONTOSO\Admin /passwordd:*
netdom join %COMPUTERNAME% /domain:contoso.com /userd:CONTOSO\Admin /passwordd:*remove の後は再起動し、ローカル アカウントで入り直してから join を実行します。なお、この再参加の話はメンバーサーバー/クライアント向けです。DC はまず netdom verify、netdom resetpwd、そして DNS やレプリケーション健全性の確認を優先してください。 (Microsoft Learn)
迷ったらこの順番で進めればよい
- まず
sc query netlogonで Netlogon サービスが動いているかを見る。止まっているなら、Secure Channel より先にサービス/依存関係を直します。 (Microsoft Learn) - メンバーサーバー/クライアントなら
Test-ComputerSecureChannel -Verbose、DC ならnetdom verifyを打ち、役割に合ったコマンドで一次判定します。 (Microsoft Learn) nltest /sc_query:<ドメイン名>で、どの DC を見ているかと直近の Secure Channel 状態を確認します。 (Microsoft Learn)- DC 発見や DNS が怪しければ
nltest /dsgetdc:<ドメイン名>で切り分けます。 (Microsoft Learn) - 修復が必要なら、メンバーは
Test-ComputerSecureChannel -Repairまたはnetdom reset、DC はnetdom resetpwdに進みます。 (Microsoft Learn) - 直した後は必ず同じ系統の確認コマンドを打ち直し、再発するならコンピューター名レジストリ、AD レプリケーション、DC 復元履歴まで掘ります。 (Microsoft Learn)
Netlogonのセキュアチャネル確認は、コマンド自体よりも役割に合ったコマンドを選ぶことで成否が決まります。メンバーなら Test-ComputerSecureChannel、DC なら netdom verify を起点にし、nltest /sc_query で DC 名と状態を補足し、必要なときだけ修復コマンドに進む。この順番で進めれば、余計な変更を入れずに、かなりの確率で短時間に切り分けできます。 (Microsoft Learn)
コメント