【図解】Netlogonとセキュアチャネルとは？NTLMのパススルー認証と「信頼関係に失敗しました」の直し方

ドメインに参加したPCやサーバは、DCとの間に「セキュアチャネル」という守られた通り道を持っています。この通り道を作って管理しているのが、Netlogon というサービスです。ふだんは意識しませんが、NTLM で認証するときや、「このワークステーションとプライマリ ドメインとの信頼関係に失敗しました」というエラーが出たときに、このしくみが関わっています。この記事では、セキュアチャネルとは何かを説明したうえで、NTLM のパススルー認証の流れと、信頼関係が壊れたときの直し方を説明します。

この記事でわかること
  1. Netlogon とセキュアチャネルが、何のためにあるのか
  2. NTLM のパススルー認証で、サーバが DC にどうやって確かめるのか
  3. 「信頼関係が壊れた」状態の原因と、直し方

セキュアチャネルとは

ドメインに参加したコンピュータには、コンピュータアカウント（FS01 なら FS01$）があり、そのパスワードをコンピュータ自身とDCの両方が持っています。コンピュータアカウントとそのパスワードについては「ユーザー・コンピュータ・サービスアカウントの違い」の記事で説明しています。

Netlogon サービスは、このパスワードを使ってDCと「おたがいに同じパスワードを知っているか」を確かめ合い、そのうえで守られた RPC の通り道を作ります。これがセキュアチャネルです。

FS01メンバーサーバLSAシークレットFS01$ のパスワードDC01ドメインコントローラADのデータベースFS01$ のパスワードセキュアチャネル（Netlogon）同じパスワードを知っていることを確かめ合うそのうえで、守られた通り道で話すセキュアチャネルを通るもの・NTLM のパススルー認証（FS01 が DC に「この応答は正しい？」と確かめる）・コンピュータアカウントのパスワードの変更（既定で30日ごと）など
図1　セキュアチャネル
セキュアチャネルを使う場面内容
NTLM のパススルー認証サーバが受け取った NTLM の応答を、DC に送って正しいか確かめてもらう（次の節で説明します）
パスワードの変更コンピュータアカウントのパスワードを、既定で30日ごとに自動で変える
ドメイン間の信頼信頼関係のあるドメインの DC どうしも、信頼のためのアカウントのパスワードでセキュアチャネルを作り、認証を回したり、ユーザーやグループの SID を確かめたりする

PC やサーバは、起動したときに DC を探してセキュアチャネルを作ります。DC を探すしくみ（DC Locator）も Netlogon サービスの一部です。

Windows Server 2025 での変化

Windows Server 2025 からは、セキュアチャネルを Kerberos で作るしくみが加わりました。Kerberos に対応したメンバー（Windows Server 2025 など）は、まず Kerberos でセキュアチャネルを作ろうとし、相手の DC が対応していなければ従来の方法に戻ります。

もう1つの変化は、名前と SID の変換（LSA の Name/SID Lookup）です。ACL には名前ではなく SID が書かれているので、ファイルのプロパティの「セキュリティ」タブを開くと、Windows は SID を「CORP\user01」のような名前に変換して表示します。逆に、アクセス許可にユーザーを追加するときは、入力した名前を SID に変換します。ドメインのアカウントの変換はDCに問い合わせて行い、相手が別のドメインのアカウントなら、DC がその問い合わせを相手のドメインの DC へ回します。この「回す」通り道に、これまではセキュアチャネルが使われていましたが、Windows Server 2025 では Kerberos で認証した通信が使われるようになりました。古い OS と組み合わせるときは、従来のセキュアチャネルも使われます。SID については「SIDとは？」の記事で説明しています。

NTLM のパススルー認証

Kerberos では、ユーザーは DC からもらったチケットをサーバに見せるので、サーバが DC に問い合わせる必要はありません。いっぽう NTLM では、ユーザーはサーバのチャレンジ（ランダムな値）にパスワードから計算した応答を返すだけです。ところがサーバの FS01 は user01 のパスワードを知らないので、その応答が正しいかを自分では確かめられません。そこで FS01 は、チャレンジと応答をセキュアチャネルで DC に送り、確かめてもらいます。これがパススルー認証です。

NTLM で FS01 の共有フォルダを開くパススルー認証（Netlogon のセキュアチャネルで DC に確かめる）PC01user01FS01パスワードを知らないDC01パスワードを知っているNEGOTIATECHALLENGE（ランダムな値）AUTHENTICATE（応答）パスワードから計算した値この応答は正しい？チャレンジと応答をそのまま渡すuser01 のパスワードから計算し直して比べる（イベント 4776）正しい。user01 のグループはこれ成功FS01 はグループ情報からトークンを作る
図2　NTLM のパススルー認証
流れ何が起きるか
① チャレンジと応答PC01 と FS01 の間で、NEGOTIATE、CHALLENGE、AUTHENTICATE の3つのメッセージをやり取りする
② DC に確かめるFS01 の Netlogon が、受け取ったチャレンジと応答を、セキュアチャネルで DC01 に送る
③ DC が判定するDC01 は user01 のパスワードから応答を計算し直して比べる。DC のセキュリティログにはイベントID 4776 が記録される
④ 結果を返す正しければ、user01 のグループなどの情報を FS01 に返す。FS01 はそれをもとにトークンを作る

パススルー認証は、FS01 と DC のセキュアチャネルが正常でないと動きません。逆に言えば、セキュアチャネルが壊れたサーバでは、NTLM での認証がすべて失敗します。NTLM の流れそのものは「NTLM認証とは？」の記事で説明しています。

別のドメインのユーザーのとき

ここまでは、ユーザーとサーバが同じドメインにいる場合でした。会社によっては、1つのフォレスト（ドメインの集まり）の中に、複数のドメインを作っていることがあります。ここでは、次の構成で考えます。

ドメインあるもの
本社ドメイン
（corp.example.com）		最初に作ったドメイン。本社の社員のアカウント（user01）と、本社のDCがある
大阪ドメイン
（osaka.corp.example.com）		本社ドメインの下に作った子ドメイン。大阪拠点のファイルサーバ（FS02）と、大阪のDCがある

同じフォレストのドメインどうしは、ドメインを作ったときに自動で信頼関係が結ばれ、DC どうしの間にも信頼関係のためのセキュアチャネルができます。そのため、本社の user01 は、アクセス許可さえあれば、大阪の FS02 の共有フォルダも使えます。この user01 が FS02 に NTLM でアクセスすると、ユーザーのパスワードを知っている本社の DC まで、次のように認証が回されます。

フォレスト（corp.example.com）本社ドメイン大阪ドメインuser01本社のDCuser01 のパスワードを知る大阪のDCFS02② セキュアチャネル③ 信頼関係のセキュアチャネル① user01 が FS02 に NTLM でアクセス② FS02 は、ふだん話している自分のドメインの DC（大阪）に確かめを頼む③ 大阪の DC は user01 のパスワードを知らないので、信頼関係をたどって本社の DC に回す
図3　別のドメインのユーザーのパススルー認証

メンバーのコンピュータは、ユーザーがどのドメインの人でも、まず自分のドメインの DC に確かめを頼みます。大阪の DC は user01 のパスワードを知らないので、信頼関係のセキュアチャネルを通じて本社の DC に回します。信頼関係については「グループの種類とスコープ」の記事で説明しています。

セキュアチャネルを狙った脆弱性

2020年には、セキュアチャネルを作る手順の弱点を突いて DC を乗っ取れる「Zerologon」（CVE-2020-1472）という脆弱性が見つかり、更新プログラムで修正されました。2022年にも、信頼関係や RODC を経由したパススルー認証の確認を強める更新（CVE-2022-21857）が出ています。セキュアチャネルは DC の守りに直結するので、DC とメンバーの更新プログラムは欠かさず適用してください。

「信頼関係が壊れた」とは

セキュアチャネルは、コンピュータと DC が同じパスワードを持っていることを前提にしています。この2つがずれると、セキュアチャネルを作れなくなります。これが、よく「信頼関係が壊れた」と呼ばれる状態です。

FS01 が持つパスワードDC が持つ FS01$ のパスワード① ふだんAA一致② 30日後に変更BB一致③ FS01 を古いスナップショットに戻すAB不一致④ パスワードをリセットCC一致③ の状態では FS01 は DC とセキュアチャネルを作れず、ドメインのアカウントでのサインインやNTLM のパススルー認証が失敗する。これが「信頼関係が壊れた」状態
図4　信頼関係が壊れる例（スナップショットに戻したとき）

よくある原因

どちらが新しいかよくある原因
AD のほうが新しい仮想マシンを古いスナップショットに戻した、バックアップから戻した、システムの復元をした、パスワード変更の直後に電源が落ちた。VDI のプール型デスクトップで、イメージに戻るたびに古いパスワードになる場合もある
コンピュータのほうが新しいDC をバックアップから戻した、AD の複製がうまくいっていない、コンピュータのオブジェクトを Authoritative Restore した

出てくる症状

  • ドメインのアカウントでサインインできず、「このワークステーションとプライマリ ドメインとの信頼関係に失敗しました」と表示される（ローカルアカウントや、キャッシュされた資格情報ならサインインできる）
  • コンピュータのシステムログに、NETLOGON のイベントID 3210 が記録される
  • nltest /sc_query を実行すると、接続の状態が「ERROR_ACCESS_DENIED」になる
  • DC 側では、NETLOGON のイベントID 5722 が記録されることがある

直し方

どちらの原因でも、最後はコンピュータのパスワードをリセットして、両方を同じ新しいパスワードにそろえます。ドメインの管理者の資格情報で、コンピュータ側で次のどちらかを実行し、再起動します。

  • PowerShell：Test-ComputerSecureChannel -Repair -Credential *
  • コマンドプロンプト：nltest /sc_reset:corp.example.com

ただし、コンピュータのほうが新しい（AD 側が古い）場合は、先に AD の複製や DC の状態を直す必要があります。AD 側の問題を残したままリセットしても、またずれる可能性があるからです。ドメインから外して参加し直す方法でも直りますが、何度も起きる場合は、どちらのパスワードが新しいかを調べて原因を探します。調べるには、コンピュータのシステムログにある NETLOGON のイベントID 5823（パスワードを変えたときの記録）と、AD のコンピュータアカウントの pwdLastSet を比べます。

スナップショットを使うときの注意

仮想マシンを長い期間のあとで古いスナップショットに戻すと、その間にコンピュータのパスワードが変わっていれば、戻した時点でずれが起きます。検証環境でよく見かけるトラブルなので、スナップショットに戻したあとは Test-ComputerSecureChannel で状態を確かめておくと安心です。

確認に使うコマンド

PC・サーバ（PowerShell）：DC とのセキュアチャネルが正常かを確かめる

Test-ComputerSecureChannel -Verbose

PC・サーバ（コマンドプロンプト）：セキュアチャネルの相手の DC と状態を表示する

nltest /sc_query:corp.example.com

PC・サーバ（コマンドプロンプト・管理者）：セキュアチャネルを作り直す

nltest /sc_reset:corp.example.com

PC・サーバ（PowerShell・管理者）：セキュアチャネルを修復する

Test-ComputerSecureChannel -Repair -Credential *

PC・サーバ（PowerShell・管理者）：コンピュータアカウントのパスワードをリセットする

Reset-ComputerMachinePassword -Credential (Get-Credential)

管理用PC（PowerShell）：AD 側でコンピュータのパスワードを最後に変えた日時を表示する

Get-ADComputer -Identity FS01 -Properties PasswordLastSet | Select-Object Name, PasswordLastSet

PC・サーバ（PowerShell）：コンピュータのパスワード変更の記録（イベントID 5823）を表示する

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=5823} -MaxEvents 5

まとめ

項目ひとことで
NetlogonDC を探し、セキュアチャネルを作り、NTLM の認証を DC に回すサービス
セキュアチャネルコンピュータアカウントのパスワードを確かめ合ってから作る、DC との守られた通り道
パススルー認証NTLM の応答を、サーバがセキュアチャネルで DC に送って確かめてもらうしくみ。別ドメインのユーザーなら、信頼関係をたどって回す
信頼関係が壊れるコンピュータと DC のパスワードがずれた状態。スナップショットやバックアップから戻したときに起きやすい
直し方Test-ComputerSecureChannel -Repair などでパスワードをそろえる。AD 側が古いときは、先に AD を直す

「信頼関係に失敗しました」は、ドメインに参加したコンピュータでよく見かけるエラーです。セキュアチャネルがコンピュータのパスワードの上に成り立っていると分かっていれば、原因の見当が付けやすくなります。

参考にした資料

関連記事：【図解】ユーザー・コンピュータ・サービスアカウントの違い／【図解】NTLM認証とは？／【図解】ADのグループの種類とスコープとは？／【図解】ドメインコントローラの種類とは？／【図解】LSASS・SSPI・Negotiateとは？／Active Directory ユーザ追加と端末のドメイン参加

コメント