【図解】Windowsの認証は何を確かめている？ユーザー・コンピューター・DCが持つ「同じ鍵」と、確かめるもの・払い出すものを初心者向けに解説

Windows の認証を調べていると、「Kerberos 認証」「NTLM 認証」「コンピューターの認証」「パススルー認証」など、いろいろな名前の認証が出てきます。チケットをもらう、トークンを作る、といった言葉も出てきて、ひとつひとつはなんとなく分かっても、「結局、何を確かめているのか」がすっきりしないことがあります。

実は、これらの認証はどれも同じ考え方の上に成り立っています。前もって同じ秘密（鍵）を持っている2人が、その秘密を相手に見せずに「自分も同じ秘密を持っている」と示し合う、という考え方です。この記事では、だれとだれが同じ鍵を持っているのか、その鍵はどうやって同じに保たれているのか、そして認証のたびに何を確かめて何を払い出しているのかに絞って、図とシーケンスで整理します。

認証の正体：同じ秘密を、見せずに証明する

認証とは、「あなたはだれか」を確かめることです。Windows のドメインでは、その確かめ方の土台に「同じ秘密を持っているかどうか」を使います。ユーザーならパスワード、コンピューターなら自動で決まったパスワードが、その秘密です。

ただし、秘密をそのまま相手に送るわけにはいきません。途中で見られたら終わりですし、毎回同じ値を送るなら、それを記録してまねされてしまいます。そこで、次の2つの方法で「秘密を見せずに、持っていることだけを示す」ようにしています。

方法1は「チャレンジレスポンス」と呼ばれ、NTLM とセキュアチャネルが使います。方法2は Kerberos が使う方法です。どちらにも共通するのは、次の3点です。

• 2人は、前もって同じ秘密を持っている
• 秘密そのものは、ネットワークに流さない
• 毎回ちがう値（乱数や時刻）を混ぜるので、前の答えを使い回せない

「同じ鍵で正しく計算できた」「同じ鍵で開けられた」ということは、その鍵を持っているということです。そして、その鍵を持っているのは本人と DC だけなので、本人だと判断できます。認証の仕組みは、突き詰めるとこれだけです。暗号やチャレンジレスポンスの基礎は「暗号の基礎」の記事で説明しています。

だれとだれが同じ鍵を持っているか

では、ドメインの中では、だれとだれが同じ鍵を持っているのでしょうか。ポイントは、鍵の組み合わせは必ず「アカウント」と「DC」だということです。

組み合わせ	秘密のもと	DC 側の持ち方	アカウント側の持ち方
ユーザー と DC	人が決めたパスワード	パスワードから作った鍵（NT ハッシュや Kerberos の鍵）を、AD のデータベースに暗号化して保存する。パスワードそのものは保存しない	保存しない。サインインのたびに、入力したパスワードから同じ計算で鍵を作る
コンピューター と DC	ドメイン参加のときに自動で決まる、長いランダムなパスワード	ユーザーと同じく、鍵として AD に保存する	コンピューター自身の保護された場所に保存する。既定で30日ごとに自分で変える
サービス と DC	サービスを動かすアカウント（コンピューターアカウントやサービスアカウント）のパスワード	同じく AD に保存する	サービスを動かすサーバが持つ
DC と DC	krbtgt アカウントのパスワード	すべての DC が同じ鍵を持つ（AD の複製で配る）	DC のほかには、だれも持たない

ここで大事なのは、DC はすべてのアカウントの鍵を持っていること、そしてPC とサーバのあいだには、長く使う共通の鍵がないことです。PC01 は FS01 の鍵を知らず、FS01 も user01 の鍵を知りません。それでも PC01 が FS01 に自分を証明できるのは、両方の鍵を持っている DC が間を取り持つからです。

Kerberos の「チケット」も、NTLM の「パススルー認証」も、この間の取り持ち方の違いです。Kerberos では DC がチケットを作って PC に持たせ、NTLM ではサーバが DC に答え合わせを頼みます。アカウントの種類については「ユーザー・コンピュータ・サービスアカウントの違い」の記事で説明しています。

同じ鍵はどうやって「そろう」のか

アカウントと DC が同じ鍵を持つには、どこかで鍵をそろえる必要があります。ここでよく誤解されるのが、「認証のたびに鍵を同期している」というイメージです。実際は、鍵がそろうのはパスワードを決めたとき・変えたときだけです。認証のたびに鍵を送り合うことはありません。

ユーザーのパスワード

ユーザーのパスワードは、管理者がアカウントを作ったときや、利用者が自分で変えたときに DC に届きます。DC はそのパスワードから鍵を作って保存します。PC 側は鍵を保存しておく必要がありません。サインインのたびに、入力されたパスワードから同じ計算で鍵を作れるからです。

パスワードの変更を受け付けた DC は、変更をすぐに PDC エミュレータ（ドメインに1台だけある、パスワードの変更を優先的に受け取る役割の DC）に知らせます。ほかの DC には、AD の複製で少し遅れて伝わります。複製が届く前に、まだ古い鍵しか持たない DC でサインインしようとした場合は、その DC が PDC エミュレータに確認を回すので、ふつうは新しいパスワードで入れます。

コンピューターのパスワード

コンピューターのパスワードは人が決めません。ドメイン参加のときに自動で決まり、その後はコンピューター自身が既定で30日ごとに新しいパスワードを作り、DC に書き込みます。

コンピューターは、「今のパスワード」と「1つ前のパスワード」の2つを持っておきます。変更がまだ届いていない相手とやり取りするときは、1つ前のパスワードを使えるようにするためです。変更に成功すると、そのコンピューターのシステムのイベントログに、Netlogon のイベント 5823 が記録されます。

この「変更はコンピューターから始まる」という点が、トラブルの原因にもなります。たとえば、仮想マシンを古いスナップショットに戻すと、コンピューターは古いパスワードに戻りますが、DC はその後に変えた新しいパスワードを持ったままです。2つより多くずれると、1つ前のパスワードでも合わなくなり、「このワークステーションとプライマリ ドメインの信頼関係に失敗しました」になります。直し方は「Netlogonとセキュアチャネル」の記事で説明しています。

krbtgt の鍵

krbtgt は、TGT（チケットを頼むためのチケット）に封をするための特別なアカウントです。この鍵を持つのは DC だけで、すべての DC が同じ鍵を持っています。krbtgt の鍵は、AD の複製で DC どうしに配られます。

認証が起きるタイミング

ここからは、実際の認証の中身を見ていきます。その前に、PC を起動してファイル共有を開くまでに、どの認証がどの鍵で起きているかを並べておきます。

見落としやすいのは①です。人がサインインする前に、コンピューターもアカウントとして DC に名乗っています。PC01 は起動すると、PC01$ の鍵で自分の TGT をもらい、DC とのセキュアチャネルを作ります。グループポリシーを読み込むときなどには、このコンピューターの資格情報が使われます。

Kerberos：何を確かめて、何を払い出すか

Kerberos では、DC（KDC）がチケットを作って PC に持たせます。まず、どれがだれの鍵で封をされていて、だれが開けられるのかを押さえておくと、流れが追いやすくなります。

封の考え方はシンプルです。受け取る相手が開けられる鍵で封をする。TGT は DC が受け取るので krbtgt の鍵で、サービスチケットは FS01 が受け取るので FS01$ の鍵で封をします。PC01 はどちらのチケットも開けられず、運ぶだけです。PC01 が開けられるのは、自分あての「包み」だけで、その中にセッション鍵（その場限りの鍵）が入っています。

① サインイン（AS 交換）

DC は、user01 の鍵で暗号化された時刻を、自分が持つ user01 の鍵で開けます。開けられて、時刻のずれが5分以内なら、user01 のパスワードを知っている本人だと判断します。払い出すのは TGT と、ログオンセッション鍵です。ログオンセッション鍵は user01 の鍵で封をしてあるので、PC01 は入力されたパスワードから作った鍵で開けられます。時刻がずれていると、この時点で失敗します。時刻の話は「Windowsの時刻同期とは？」の記事で説明しています。

コンピューターの起動のときも同じ流れで、user01 の鍵の代わりに PC01$ の鍵を使います。

② サービスチケットをもらう（TGS 交換）

ここでは、user01 の鍵（パスワード）はもう使いません。DC は、krbtgt の鍵で TGT を開けられることで「自分たち DC が作った本物の TGT だ」と分かり、TGT の中に書いておいたログオンセッション鍵でオーセンティケータを開けることで「TGT を持ってきたのは、そのセッション鍵を持つ本人だ」と分かります。そのうえで、SPN の持ち主（ここでは FS01$）の鍵で封をしたサービスチケットを払い出します。SPN については「SPNとは？」の記事で説明しています。

③ サーバに見せる（AP 交換）

FS01 は、自分の鍵でサービスチケットを開けます。FS01$ の鍵を持っているのは FS01 と DC だけなので、開けられたということは、DC が FS01 のために作ったチケットだということです。だから FS01 は、DC に問い合わせなくても、チケットの中身（だれなのか、どのグループに入っているか）を信じられます。

FS01 が最後に払い出すのは、アクセストークンです。チケットの中の PAC（ユーザーと所属グループの SID）をもとに作り、このトークンでファイルのアクセス許可を判断します。アクセストークンについては「アクセストークンとACLとは？」の記事で説明しています。

NTLM：何を確かめて、何を払い出すか

IP アドレスで共有を開いたときなど、Kerberos を使えないときは NTLM になります。NTLM は方法1（問題と答え）を使います。

Kerberos との大きな違いは、サーバが自分では確かめられないことです。答えを確かめるには user01 の鍵が必要ですが、FS01 はそれを持っていません。そこで FS01 は、出した乱数と返ってきた答えを DC に送り、DC が自分の持つ user01 の鍵で同じ計算をして、一致するかを確かめます（パススルー認証）。一致すれば、DC は user01 の SID や所属グループなどの情報を FS01 に返し、FS01 はそれをもとにアクセストークンを作ります。

FS01 から DC への問い合わせは、次に説明するセキュアチャネルを通ります。つまり NTLM の答え合わせは、FS01$ の鍵で守られた通り道の上で行われています。NTLM の詳しい流れは「NTLM認証とは？」の記事で説明しています。

セキュアチャネル：コンピューターと DC の確かめ合い

セキュアチャネルは、コンピューターと DC が、コンピューターアカウントのパスワードを使っておたがいを確かめ、守られた通り道を作るしくみです。Kerberos の AS 交換とちがい、両方が問題を出し合うので、DC が本物かどうかもコンピューター側で確かめられます。

PC01 と DC01 は、まずおたがいに乱数を送り合います。次に、両方がそれぞれ「2つの乱数」と「PC01$ のパスワード」から、同じセッション鍵を計算します。セッション鍵そのものはネットワークに流れません。そのうえで、PC01 はセッション鍵から計算した答えを送り、DC01 が確かめます。DC01 も答えを返し、PC01 が確かめます。PC01$ のパスワードを知らない相手は正しい答えを作れないので、両方が本物だと分かります。

払い出すのは、このセッション鍵です。以降の Netlogon のやり取り（NTLM のパススルー認証や、コンピューターのパスワードの変更など）は、この鍵で守られます。なお Windows Server 2025 からは、セキュアチャネルを Kerberos で作るしくみも加わっています。

3つの方式を並べると

場面	使う鍵	確かめること	払い出すもの
Kerberos の AS 交換	ユーザー（またはコンピューター）の鍵	暗号化された時刻を開けられるか。時刻のずれが5分以内か	TGT と、ログオンセッション鍵
Kerberos の TGS 交換	krbtgt の鍵、ログオンセッション鍵	TGT が本物か。オーセンティケータの名前と時刻が合うか。SPN の持ち主がいるか	サービスチケットと、サービスセッション鍵
Kerberos の AP 交換	サーバの鍵、サービスセッション鍵	チケットを開けられるか。期限内か。オーセンティケータの名前と時刻が合うか	アクセストークン（PAC から作る）
NTLM	ユーザーの鍵（DC だけが使う）	サーバの乱数への答えが、DC の計算と一致するか	ユーザーの情報（DC → サーバ）。サーバがアクセストークンを作る
セキュアチャネル	コンピューターのパスワード	おたがいの答えが、自分の計算と一致するか（両方向）	セッション鍵（Netlogon の通信を守る）

表を縦に見ると、払い出すものには2種類あることが分かります。1つは次の相手に見せるためのもの（TGT、サービスチケット）、もう1つはその場限りの鍵（セッション鍵）です。そして最後に、サーバの中でアクセストークンができ、ここで初めて「何をしてよいか」の判断（認可）に移ります。認証と認可の違いは「認証と認可の違いとは？」の記事で説明しています。

鍵がずれると何が起きるか

認証は「両方が同じ鍵を持っている」ことが前提なので、鍵がずれると失敗します。よくあるずれ方を並べておきます。

ずれ方	起きること	直し方
コンピューターを古いスナップショットやバックアップに戻した	DC とセキュアチャネルを作れない。「信頼関係に失敗しました」	コンピューターのパスワードをリセットし直す（Test-ComputerSecureChannel -Repair など）
サービスアカウントのパスワードを AD だけで変え、サーバ側の設定を変え忘れた	サービスの起動時にログオンできない。チケットを開けず、KRB_AP_ERR_MODIFIED になることもある	サーバ側の設定も新しいパスワードにする。gMSA なら自動でそろう
パスワードを変えたが、古いパスワードを覚えたアプリやドライブの割り当てが残っている	古いパスワードで何度も試され、アカウントがロックされる	古い資格情報を使っている場所を探して直す
PC と DC の時刻がずれている	Kerberos の時刻の確認（5分）で失敗する	時刻同期を直す

確認に使うコマンド

PC01（コマンドプロンプト）：サインインしたユーザーが持っているチケット（TGT とサービスチケット）を表示する

klist

PC01（コマンドプロンプト・管理者）：コンピューター（PC01$）が持っているチケットを表示する

klist -li 0x3e7

PC01（PowerShell・管理者）：DC とのセキュアチャネルが正しく作れるかを確かめる

Test-ComputerSecureChannel -Verbose

PC01（コマンドプロンプト・管理者）：セキュアチャネルの状態を確かめる

nltest /sc_verify:corp.example.com

PC01（PowerShell・管理者）：コンピューターのパスワードを変更したときのイベント（5823）を表示する

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

DC01（PowerShell・管理者）：コンピューターとユーザーのパスワードを最後に変えた日時を表示する

Get-ADComputer PC01 -Properties PasswordLastSet | Select-Object Name, PasswordLastSet
Get-ADUser user01 -Properties PasswordLastSet | Select-Object Name, PasswordLastSet

まとめ

項目	ひとことで
認証の正体	同じ秘密を持つ2人が、秘密を見せずに「持っている」ことを示し合う
鍵の組み合わせ	いつも「アカウント と DC」。DC は全員の鍵を持ち、PC とサーバのあいだには共通の鍵がない
鍵がそろうとき	パスワードを決めたとき・変えたときだけ。ユーザーは入力から毎回計算、コンピューターは自分で30日ごとに変える
Kerberos	DC が「受け取る相手の鍵」で封をしたチケットを作り、PC はそれを運ぶ。サーバは自分の鍵で開けられれば本物と分かる
NTLM	サーバは鍵を持たないので、DC に答え合わせを頼む
セキュアチャネル	コンピューターと DC が問題を出し合い、おたがいを確かめてセッション鍵を作る
払い出すもの	次の相手に見せるもの（チケット）と、その場限りの鍵（セッション鍵）。最後にサーバでアクセストークンができる

「〇〇認証」という名前がたくさんあっても、やっていることは「だれとだれが同じ鍵を持っていて、それをどう見せずに示すか」の組み合わせです。新しい認証の仕組みに出会ったときも、「この鍵はだれとだれが持っているのか」「何を確かめて、何を払い出しているのか」の2つを問いかけると、全体の流れがつかみやすくなります。

関連記事：【図解】Kerberos（ケルベロス）認証とは？／【図解】NTLM認証とは？／【図解】Netlogonとセキュアチャネルとは？／【図解】ユーザー・コンピュータ・サービスアカウントの違い／【図解】暗号の基礎／【図解】アクセストークンとACLとは？／【図解】認証と認可の違いとは？／【図解】Windowsの時刻同期とは？