【図解】Kerberos（ケルベロス）認証とは？チケットの流れとPACを初心者向けに解説

Windowsのドメイン環境で働いていると、「Kerberos（ケルベロス）認証」という言葉を何度も目にします。ファイルサーバにつながらない、SQL Serverの統合認証が通らない、といったトラブルの調査でも「SPN」「チケット」「NTLMに落ちている」といった話がよく出てきます。それでも、チケットが何往復していて、誰が誰にどの鍵で何を暗号化して送っているのかまで説明できる人は多くないと思います。

この記事では、Kerberosが生まれた背景から始めて、6つのメッセージのやり取りを「誰から誰へ」が分かる形で1つずつ追います。そのうえで、チケットに入る所属グループの情報（PAC）、ファイルサーバやデータベースでの使われ方、ドメイン参加・未参加の端末の違い、Kerberosを狙う攻撃までを順に整理します。

Kerberosを一言でいうと

Kerberosは、「チケット」を見せることで本人であることを証明するネットワーク認証プロトコルです。最初に一度だけ信頼できる窓口（KDC）で本人確認を受けてチケットをもらい、あとは使いたいサーバにチケットを見せるだけでアクセスできます。パスワードそのものはネットワークに流れません。

イベント会場の入場をイメージすると分かりやすいです。受付で身分証を見せてリストバンドをもらえば、あとは各ブースでリストバンドを見せるだけで入れます。ブースの係員は受付に毎回電話して確認したりしません。リストバンドが本物かどうかを、その場で見分けられるからです。

登場人物	役割
クライアント	サービスを使いたいユーザーやPC。KDCからもらったチケットを手元（チケットキャッシュ）に保管します。
KDC（Key Distribution Center）	全員の鍵を知っている、信頼された第三者です。初回の本人確認をしてTGTを出すAS（Authentication Service）と、TGTと引き換えに各サービス用のチケットを出すTGS（Ticket-Granting Service）の2つの役割があります。Active Directoryでは、すべてのドメインコントローラ（DC）がKDCを兼ねています。
サーバ	ファイルサーバ、SQL Server、Webサーバなど、アクセスされる側です。KDCとあらかじめ鍵を共有しているので、チケットを自分で開けて確かめられます。

Kerberosはいつ、なぜ生まれたのか

Kerberosは1980年代に、MIT（マサチューセッツ工科大学）のProject Athenaで開発されました。大学のキャンパスに多数の端末とサーバが並び、誰でもネットワークを盗聴できる環境で、パスワードを流さずに本人確認する方法が必要だったのが出発点です。名前は、ギリシャ神話で冥界の門を守る三つ首の犬「ケルベロス」に由来します。3つの頭を、クライアント・サーバ・KDCの3者になぞらえて説明されることもよくあります。

バージョン1〜4はProject Athenaで作られ、現在使われているバージョン5は1993年にRFC 1510として標準化されました。2005年にはRFC 4120に改訂され、これが今の基本仕様です。MicrosoftはWindows 2000でKerberos v5をドメインの既定の認証プロトコルに採用し、それ以前から使われていたNTLMは互換性のために残されました。

NTLMとの違い：チケットを見せるだけ

NTLMでは、サーバはユーザーのパスワード情報を持っていないので、認証のたびにDCへ「この答えは正しいか」を問い合わせます。Kerberosでは、クライアントが最初にKDCからTGT（Ticket-Granting Ticket）をもらい、使いたいサービスが出てくるたびに、TGTを見せてそのサービス用のサービスチケットをもらいます。

サーバは、KDCと共有している自分の鍵でサービスチケットを開けて中身を確かめます。チケットに必要な情報がすべて入っているので、認証のたびにDCへ問い合わせる必要がありません。チケットは有効期限まで使い回せるので、同じサーバに何度つないでもKDCとのやり取りは増えません。

比べる点	NTLM	Kerberos
方式	チャレンジ／レスポンス	チケット（共通鍵暗号）
DCとのやり取り	サーバが認証するたびにDCへ問い合わせ	クライアントがTGTとサービスチケットを取るときだけ。サーバはDCに聞かない
相互認証	できない（サーバは確かめられない）	できる（サーバもチケットを開けられることで本物と分かる）
前提条件	特になし（IPアドレス指定でも動く）	SPN（サービス名）とDNS、時刻同期、KDCへの到達性が必要
主なリスク	NTLMリレー、Pass-the-Hash	サービスアカウントの弱いパスワード、鍵の盗難によるチケット偽造

チケットのやり取りをシーケンスで追う

ここからが本題です。Kerberosのやり取りは、AS交換・TGS交換・AP交換の3段階、合計6つのメッセージでできています。まず全体をシーケンス図で見て、そのあと1つずつ「誰から誰へ、何を送っているか」を追います。メッセージ名はRFC 4120の呼び方で、Wiresharkでキャプチャするとこの名前で表示されます。

まず「鍵」を押さえる

シーケンスを追う前に、登場する鍵を整理しておきます。Kerberosの仕組みは、「誰がどの鍵を持っているか」が分かれば、ほとんど理解できます。長く使う鍵が3種類、その場限りで作る鍵が2種類あります。

鍵	中身	持っている人
ユーザー鍵	ユーザーのパスワードから作った鍵	ユーザー（入力したパスワードから計算）とKDC
krbtgtの鍵	ADのkrbtgtアカウントの鍵。TGTの暗号化に使う	KDCだけ
サーバの鍵	サービスを動かしているアカウント（コンピュータアカウントやサービスアカウント）の鍵	サーバとKDC
ログオンセッション鍵	AS交換でKDCが作る一時的な鍵	クライアントとKDC（TGTの中）
サービスセッション鍵	TGS交換でKDCが作る一時的な鍵	クライアントとサーバ（サービスチケットの中）

ポイントは、チケットは「受け取る相手の鍵」で暗号化されていることです。TGTはKDC（krbtgt）の鍵、サービスチケットはサーバの鍵で暗号化されているので、クライアントは中身を読めず、改ざんもできません。クライアントは、一緒に届くセッション鍵を使って「チケットの正当な持ち主は自分だ」と示します。

以下の図では、上の段に「誰から誰へ送るか」と、運ばれるもの（チケットは券の形、暗号化した包みは封筒の形）を描き、下の段にそれぞれの中身を並べています。関係しない登場人物は薄く表示しています。

KRB_AS_REQ：クライアントがKDCに名乗る

Windowsにサインインすると、クライアントはKDCのAS（UDP/TCP 88番）にKRB_AS_REQを送ります。中身はユーザー名と、「TGTが欲しい」という要求です。

あわせて、今の時刻をユーザー鍵で暗号化した「事前認証データ」を付けます。KDCは自分が持っているユーザー鍵で開け、時刻が正しければ「この人はパスワードを知っている本人だ」と判断します。RFC 4120では事前認証は使うべき（SHOULD）という扱いですが、Active Directoryでは既定で必須になっています。

KRB_AS_REP：KDCがTGTを返す

本人確認ができると、KDCはログオンセッション鍵を作り、2つの包みに入れてクライアントに返します。1つはkrbtgtの鍵で暗号化したTGTで、中にはユーザー名、ログオンセッション鍵、有効期限、そしてPAC（ユーザーと所属グループの情報。後で詳しく説明します）が入っています。もう1つはユーザー鍵で暗号化した包みで、中身はクライアント用のログオンセッション鍵です。

クライアントはパスワードから作った鍵で2つめの包みを開け、ログオンセッション鍵を取り出します。TGTは開けられないので、そのまま保管します。ここから先はパスワードの鍵を使わず、ログオンセッション鍵だけでやり取りを進めます。ADの既定では、TGTの有効期限は10時間、更新できる期間は7日です。

KRB_TGS_REQ：クライアントがサービスチケットを頼む

ファイル共有を開くなど、サービスにアクセスするときは、クライアントからKDCのTGSにKRB_TGS_REQを送ります。中身は3つです。欲しいサービスを表すSPN（Service Principal Name、例：cifs/fs01.corp.example）、STEP 2でもらったTGT、そしてログオンセッション鍵で「ユーザー名と今の時刻」を暗号化したオーセンティケータです。

KDCはkrbtgtの鍵でTGTを開け、中からログオンセッション鍵を取り出します。その鍵でオーセンティケータを開けて、ユーザー名がTGTと一致し、時刻が新しければ正当な要求と判断します。ネットワーク上でTGTだけを盗み見た人はログオンセッション鍵を知らないので、正しいオーセンティケータを作れません。

KRB_TGS_REP：KDCがサービスチケットを返す

KDCはSPNから、そのサービスを動かしているアカウントを探します。見つかれば、クライアントとサーバが共有するためのサービスセッション鍵を作り、ここでも2つの包みにしてクライアントに返します。

1つはサーバの鍵で暗号化したサービスチケットで、ユーザー名、サービスセッション鍵、有効期限、TGTから引き継いだPACが入っています。もう1つはログオンセッション鍵で暗号化した包みで、クライアント用のサービスセッション鍵が入っています。SPNがどのアカウントにも登録されていなければ、ここでエラー（KDC_ERR_S_PRINCIPAL_UNKNOWN）になります。

KRB_AP_REQ：クライアントがサーバにチケットを見せる

クライアントは、サーバに直接KRB_AP_REQを送ります。中身はサービスチケットと、サービスセッション鍵で暗号化したオーセンティケータです。単独のメッセージとして送るのではなく、SMBのセッション確立やHTTPのヘッダなど、各プロトコルの認証の中に入れて運ばれます。

サーバは自分の鍵でサービスチケットを開け、サービスセッション鍵とPACを取り出します。その鍵でオーセンティケータを開け、ユーザー名と時刻を確かめます。図のとおり、このステップにKDCは関わっていません。

KRB_AP_REP：サーバが本物だと示す

クライアントが相互認証を求めた場合（AP-REQにMUTUAL-REQUIREDのフラグを立てた場合）、サーバはクライアントにKRB_AP_REPを返します。中身は、受け取ったオーセンティケータの時刻などを、サービスセッション鍵で暗号化したものです。

サービスセッション鍵は、サーバの鍵でサービスチケットを開けなければ手に入りません。つまり、正しいAP-REPを返せること自体が、相手がKDCに登録された本物のサーバである証拠になります。NTLMにはない、この「サーバ側の本人確認」がKerberosの大きな特徴です。

クライアントでチケットを確かめる

Windowsでは、klist コマンドで手元のチケットを確認できます。動作確認やトラブルの切り分けでは、次のコマンドをよく使います。

クライアント（コマンドプロンプト）

C:\> klist
C:\> klist get cifs/fs01.corp.example
C:\> klist purge

コマンド	何がわかるか
klist	キャッシュにあるチケットの一覧。krbtgt/… がTGT、cifs/… などがサービスチケットです。有効期限や暗号化方式（AESなど）も表示されます。
klist get <SPN>	指定したSPNのサービスチケットを取りにいきます。SPNの登録漏れや重複を切り分けるときに使います。
klist purge	キャッシュのチケットを消します。グループを変えたあと、新しいPACで取り直したいときなどに使います。

PAC：チケットに入る「所属グループの証明」

RFC 4120のKerberosは「この人は誰か」を確かめる仕組みで、「この人に何を許すか」に使う情報は決めていません。Active Directoryでは、チケットの中にPAC（Privilege Attribute Certificate）というMicrosoft独自のデータを入れて、ユーザーのSIDや所属グループの情報を運んでいます。ファイルサーバのアクセス権がグループで決まるのは、このPACのおかげです。

PACはチケットのどこに入っているか

チケットには、レルム名やSPNのような平文の部分と、受け取る相手の鍵で暗号化された部分があります。PACは暗号化された部分の中の、authorization-data（認可データ）という欄に入っています。そのため、クライアントはPACを読んだり書き換えたりできません。PACの形式は、Microsoftの仕様書MS-PACで公開されています。

PACの中身

PACは、種類ごとに分かれた複数のデータの集まりです。中心になるのは「ログオン情報」で、ユーザーのSID、プライマリグループ、所属するグループの一覧が入っています。グループは「ドメインのSID＋グループの番号（RID）」の形で持ち、ほかのドメインのグループなどはExtraSidsという欄に入ります。パスワードの最終変更日時やアカウントの属性も含まれます。

データ	中身と使い道
ログオン情報	ユーザーSID、所属グループ、アカウントの属性。サーバはこれでアクセストークンを作ります。NTLMでDCがサーバに返すユーザー情報と同じ系統の構造です。
クライアント情報	ユーザー名とチケットの発行時刻。チケットとPACの組み合わせが正しいかの確認に使います。
UPN・DNS情報	ユーザーのUPNと、ドメインのDNS名。
クレーム・デバイス情報	ダイナミックアクセス制御で使うユーザーや端末の属性。使っている環境でだけ入ります。
要求者のSID	このPACをどのアカウントのために作ったか。2021年のセキュリティ更新で追加され、なりすましによる権限昇格を防いでいます。
署名（4種類）	サーバ署名、KDC署名、チケット署名、拡張KDC署名。PACやチケットが書き換えられていないことを確かめるために使います。

PACはいつ作られ、どう運ばれるか

PACを作るのはKDCです。STEP 1〜2のAS交換で、KDCはADからユーザーの所属グループなどを読み出してPACを作り、TGTの中に入れます。STEP 3〜4のTGS交換では、KDCがTGTのPACを検証してサービスチケットに引き継ぎ、サーバ向けの署名を付け直します（サーバのドメイン側の情報が加わることもあります）。

このため、ユーザーを新しいグループに追加しても、すでに持っているTGTのPACには反映されません。新しいグループの権限が効くのは、TGTを取り直したとき（サインインし直す、klist purge でチケットを消すなど）です。「グループに入れたのにアクセスできない」という問い合わせの多くは、これが原因です。

サーバはPACでアクセスを決める

サーバはSTEP 5でサービスチケットを開け、中のPACからアクセストークンを作ります。アクセストークンには、ユーザーのSIDと所属グループのSIDが並んでいて、フォルダやデータベースのACL（アクセス制御リスト）と照合することで、許可するかどうかを決めます。グループの情報がチケットに入っているので、認証のたびにDCへ所属グループを聞きに行く必要がありません。

PACの署名と検証

PACには、書き換えを見つけるための署名が付いています。サーバ署名はサーバの鍵で、KDC署名はkrbtgtの鍵で作られます。サーバは自分の鍵でサーバ署名を確かめられますが、krbtgtの鍵は持っていないので、KDC署名は自分では確かめられません。必要なときは、NetlogonでDCにKDC署名の確認を頼みます。これをPAC検証といい、行うかどうかはサービスの種類や設定によって変わります。

チケット署名と拡張KDC署名は、チケットやPACが途中で組み替えられていないかを確かめるために、あとから追加されたものです。過去には、KDCが署名を正しく確認しないためにPACを偽造できる脆弱性（2014年のMS14-068）もありました。PACは「この人は管理者グループのメンバーだ」という情報そのものなので、署名と検証が守りの要になっています。

エンタープライズでの主なユースケース

ADのドメイン環境では、Windowsの統合認証（Windows Integrated Authentication）を使うサービスの多くが、裏でKerberosを使っています。どのサービスでも、クライアントがSPNを組み立ててサービスチケットを要求し、サーバに見せるという流れは同じです。違うのは、SPNの形と、チケットを運ぶプロトコルです。

ファイルサーバ（SMB）

いちばん身近な例です。\\fs01.corp.example\share を開くと、クライアントはSPN cifs/fs01.corp.example のサービスチケットを取り、SMBのセッション確立の中でサーバに渡します。Windowsのファイルサーバでは、ドメイン参加時にコンピュータアカウントへ登録される HOST/… のSPNが cifs を兼ねるので、個別に登録しなくても動きます。

認証の結果できたセッション鍵は、SMB署名やSMB暗号化の鍵を作る材料にも使われます。Windows Server 2025では、SMBの送信側の接続で署名が既定で必須になりました。

データベース（SQL Server）

SQL Serverの「Windows認証」もKerberosを使います。アプリケーションの接続文字列にパスワードを書かずに、実行しているユーザーやサービスアカウントの権限で接続できます。SPNは MSSQLSvc/sql01.corp.example:1433 のように、ホスト名とポート番号で表します。

SPNは、SQL Serverのサービスを動かしているアカウントに登録します。サービスアカウントを変えたのにSPNが古いアカウントに残っていると、Kerberosが使えずにNTLMで接続されたり、「Cannot generate SSPI context」のエラーになったりします。

WebアプリとプロキシのHTTP認証（Negotiate）

IISの統合Windows認証や、社内のWebプロキシの認証でもKerberosが使われます。HTTPでは、SPNEGO（Negotiate）という仕組みでKerberosのトークンをHTTPヘッダに入れて運びます。RFC 4559に、この「Negotiate」認証の形式が書かれています。

サーバが 401 Unauthorized と WWW-Authenticate: Negotiate を返すと、ブラウザは HTTP/web.corp.example のサービスチケットを取り、AP-REQを含むトークンを Authorization: Negotiate ヘッダに入れて送り直します。ブラウザのイントラネットゾーンの設定によっては自動で送られないこともあり、その場合はユーザー名とパスワードの入力画面が出ます。プロキシの認証でNTLMが残りやすい理由は、NTLMの記事で解説しています。

SPNが合わないとNTLMに落ちる

Windowsの多くのアプリは、認証方式を直接指定せずにNegotiateを使います。Negotiateはまず Kerberos を試し、使えなければ黙ってNTLMで認証します。つながってはいるけれど実はNTLMだった、ということが起きやすいのはこのためです。よくある原因を表にまとめます。

状況	起きること	確認すること
IPアドレスでアクセス	Windowsは既定でIPアドレス宛てにKerberosを試さず、NTLMになります	FQDNで指定しているか。IPで使う必要があるなら TryIPSPN 設定とIPのSPN登録を検討します
SPNが未登録	TGS交換でエラーになり、NTLMになります	setspn -Q <SPN> で登録先を確認します
SPNが重複	KDCが1つに決められずエラーになります	setspn -X で重複を探します
別名（CNAME）でアクセス	クライアントが組み立てるSPNと登録したSPNが食い違うことがあります	別名のSPNを登録するか、実ホスト名でアクセスします
時刻がずれている	KRB_AP_ERR_SKEWなどで失敗します	クライアント・サーバ・DCの時刻を確認します

ドメイン参加・未参加で何が変わるか

同じファイルサーバにアクセスする場合でも、クライアントがドメインに参加しているかどうかで、TGTを取るタイミングや、そもそもKerberosが使えるかが変わります。

ADドメイン参加端末

ドメイン参加端末は、Kerberosがいちばん素直に動く形です。端末自身もコンピュータアカウントとしてADに登録されていて、起動時にDCと通信しています。ユーザーがパスワードやスマートカードでサインインすると、LSASS（ローカルセキュリティ機関）がKRB_AS_REQを送ってTGTを取り、メモリに保管します。

あとは共有フォルダを開くたびに、LSASSが裏でTGS交換をしてサービスチケットを取り、SMBの中でサーバに渡します。ユーザーは何も入力しません。これがドメイン環境のシングルサインオンの正体です。DCに届かないとき（社外で、VPNもつないでいないときなど）は、キャッシュされた資格情報でWindowsへのサインインはできますが、新しいチケットは取れません。

ドメインに参加していない端末

ワークグループのPCや、持ち込みのPCなど、ドメインに参加していない端末は、サインイン時にTGTを持っていません。ローカルアカウントでサインインしているので、ADのKDCとは何の関係もない状態です。

この端末からファイルサーバにアクセスすると、多くの場合はNTLMで認証されます。ドメインのアカウントを明示して（例：net use \\fs01.corp.example\share /user:corp.example\user01）、サーバをFQDNで指定し、端末がDNSでDCを見つけて通信できる場合は、その場でAS交換からやり直してKerberosが使われることもあります。どちらになったかは、klist でチケットがあるかを見ると確かめられます。

ドメインのアカウントの形は、CORP\user01 のようなNetBIOS名より、corp.example\user01 や user01@corp.example のようにDNSのドメイン名を使う方が、ドメインに参加していない端末からDCを見つけやすくなります。

Kerberosを狙う攻撃と対策

Kerberosの仕組みそのものは堅牢ですが、攻撃者は「パスワードから作った鍵で暗号化されたデータ」と「チケットを作るための鍵」を狙います。前者は持ち帰って総当たりし、後者を盗めばチケットとPACを好きなように偽造できます。代表的な4つの攻撃を見ていきます。

Kerberoasting

ドメインの一般ユーザーなら誰でも、SPNを指定してサービスチケットを取れます。サービスチケットはサービスアカウントの鍵で暗号化されているので、攻撃者はこれを持ち帰り、サービスアカウントのパスワードを総当たりで割り出そうとします。人が決めた短いパスワードのサービスアカウントは、特に狙われます。

対策は、SPNを持つユーザーアカウントに長くランダムなパスワードを設定することです。可能ならgMSA（グループの管理されたサービスアカウント）を使い、パスワードの生成と更新をADに任せます。gMSAのパスワードは240バイトのランダムな値で、30日ごとに自動で変わります。暗号化はRC4ではなくAESにそろえます（Windows Server 2025では、KerberosでのRC4の利用が非推奨になりました）。

AS-REP Roasting

事前認証を無効にしたアカウント（「Kerberos事前認証を不要とする」が有効）は、パスワードを知らなくてもAS-REQに応答が返ります。応答の中のユーザー鍵で暗号化された部分を持ち帰れば、Kerberoastingと同じように総当たりできます。事前認証は既定の「必須」のままにし、無効になっているアカウントがないか定期的に確認します。

ゴールデンチケット

krbtgtの鍵を盗まれると、攻撃者はKDCを通さずにTGTを自分で作れます。TGTの中のPACも好きなように書けるので、存在しないユーザーをDomain Adminsのメンバーにする、有効期限を長くする、といったことができてしまいます。krbtgtの鍵を盗むにはドメイン管理者の権限が必要なので、侵入の最終段階で、居座り続けるために使われます。

対策は、DCとドメイン管理者アカウントを最も重要な資産として守ることです。侵害が疑われるときは、krbtgtのパスワードを2回リセットします。チケットの有効期限（既定10時間）より長い間隔をあけて2回変えることで、古い鍵で作られたチケットを使えなくします。Microsoft Defender for Identityなどの製品は、ゴールデンチケットの特徴を持つ通信を検知できます。

シルバーチケット

サービスアカウントやサーバのコンピュータアカウントの鍵を盗まれると、攻撃者はそのサービス向けのサービスチケットを自分で作れます。サービスチケットはDCを通らずにサーバへ直接渡すので、DCのログに残りにくいのが特徴です。中のPACも偽造できるため、そのサーバの中では管理者として振る舞えます。

対策は、サービスアカウントの鍵を強くし、定期的に変えることです（gMSAならパスワードが自動で変わります）。重要なサービスでは、PAC検証でKDC署名をDCに確認させることも有効です。

攻撃	狙うもの	主な対策
Kerberoasting	サービスチケット（サービスアカウントの鍵で暗号化）	長くランダムなパスワード、gMSA、AESへの統一
AS-REP Roasting	事前認証を無効にしたアカウントのAS-REP	事前認証を必須のままにする
ゴールデンチケット	krbtgtの鍵（TGTとPACを偽造）	DCと特権アカウントの保護、krbtgtのパスワードを2回リセット、検知製品
シルバーチケット	サービスの鍵（サービスチケットとPACを偽造）	サービスアカウントの鍵の強化と定期変更、PAC検証

まとめ

Kerberosは、最初に一度だけKDCで本人確認を受け、あとはチケットを見せてサービスを使う認証です。チケットは受け取る相手の鍵で暗号化され、一時的なセッション鍵で持ち主であることを示すので、パスワードを流さず、サーバはDCに問い合わせずに、互いに本物だと確かめられます。

項目	押さえておくこと
AS交換（①②）	クライアント ⇄ KDC。サインイン時に1回。事前認証で本人確認し、TGTとログオンセッション鍵をもらう
TGS交換（③④）	クライアント ⇄ KDC。サービスごと。TGTとSPNを見せて、サービスチケットとサービスセッション鍵をもらう
AP交換（⑤⑥）	クライアント ⇄ サーバ。サーバは自分の鍵で開けて確認し、求められればAP-REPで自分も本物だと示す
PAC	KDCがAS交換で作り、TGTからサービスチケットへ引き継がれる所属グループの情報。サーバはこれでACLを判断する
SPNとFQDN	サービスをSPNで特定する。IP指定やSPNの不備はNTLMへのフォールバックの原因になる
ドメイン参加・未参加	参加端末はサインイン時にTGTを取る。未参加端末は多くがNTLM
攻撃	弱いサービスアカウントのパスワードと、krbtgt・サービスの鍵の盗難に注意する

Kerberosのトラブルは、「どのSPNのチケットを取ろうとして、どこで失敗したか」をシーケンスに当てはめると切り分けやすくなります。次の記事では、オンプレミスのADに参加していないEntra参加端末が、どうやってこのチケットを手に入れるのかを見ていきます。

シリーズ：①【図解】NTLM認証とは？／③【図解】Microsoft Entra Kerberosとは？
関連記事：【図解】LDAPとは？仕組みと必要な理由／【図解】RADIUSプロトコルがよくわかる！／Microsoft Entra IDと Active Diretory ざっくりの違いは？／Active Directory ユーザ追加と端末のドメイン参加