TGTからファイル共有へ

社員U-41が社内端末WS-41からファイル共有FS-1へ接続する。ADドメインの認証で、パスワードがファイルサーバへ毎回送られるわけではない。KDCが発行するTGTとサービスチケット、サービスを指すSPN、ディレクトリ照会を行うLDAPの役割を分ければ、どこに失敗や悪用の痕跡が残るか分かる。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語	意味とこの事案での判断の限界
Active Directory Domain Services	ユーザー、コンピューター、グループ、サービスアカウントなどをディレクトリに保持する。ドメインコントローラーが認証とディレクトリサービスを提供する。
KDC	Key Distribution Center。ADではドメインコントローラー上で動作し、認証サービスASとチケット発行サービスTGSの役割を担う。
Kerberosプリンシパル	認証される利用者、端末、サービスの識別主体。認証成功とリソースへのアクセス許可は別で、サービス側のACL評価も必要。
TGT	Ticket Granting Ticket。AS交換の後にクライアントが得て、後続のサービスチケット要求でKDCへ提示する。通常のファイル共有にはTGTそのものを提示しない。
TGS / サービスチケット	TGSはKDC内のチケット発行サービスまたはその交換を指す。そこで取得したサービスチケットを対象サービスへ提示する。『TGS=チケット』と曖昧に書かない。
SPN	Service Principal Name。例えばcifs/fs-1.example.testのようにサービスを識別し、KDCがどのアカウントの鍵でサービスチケットを保護するか決める。登録の重複・誤りは認証失敗を招く。
AP交換	クライアントがサービスチケットと認証子をFS-1へ提示し、サービスが復号・検証する段階。KDCでの発行成功だけではFS-1の受入れやファイル閲覧成功を意味しない。
LDAP / LDAPS	LDAPはディレクトリ検索・更新のプロトコル。LDAPSはTLS開始済み接続でLDAPを運ぶ構成。Kerberosチケット発行とは役割が異なる。389/636の数字だけで保護状態を断定しない。
LDAP署名・チャネルバインディング	LDAP操作の完全性確認やTLSセッションとの結合を強める仕組み。単純Bindの平文送信、署名なし通信、証明書検証不備を区別して対処する。

2. 構成と判断する位置

架空のexample.testドメインにDC-1、WS-41、FS-1がある。U-41は09:00にサインインし、09:04に\\fs-1.example.test\teamへアクセスする。WS-41はDC-1へTGTを要求し、次にcifs/fs-1.example.test向けサービスチケットを要求する。FS-1が受け入れた後、共有とNTFSの権限を評価する。別の資産台帳アプリINV-1はLDAPで利用者所属グループを検索し、TLSと署名設定を確認する。

TGTからファイル共有へ

KDCのチケット発行とサービスの受入れを分ける。

AS交換では利用者の身元を確認してTGTを得る。TGS交換ではサービスを識別するSPNを指定し、FS-1向けチケットを得る。FS-1はチケットを検証し、さらに共有・ファイル権限を評価する。図の最後の応答は認証だけでなく認可の結果を含む。

3. 正常時の処理と管理

WS-41がDC-1と時刻・ドメイン情報を合わせ、U-41のサインインでAS-REQを送る。事前認証と暗号方式の設定を確認する。
DC-1がU-41の認証を確認しAS-REPでTGTと後続交換に必要な情報を返す。TGTはkrbtgt側の鍵で保護される。
WS-41がアクセス先FS-1のSPNを決め、TGTを用いてTGS-REQを送る。KDCはサービスアカウントに対応する鍵で保護したサービスチケットを返す。
WS-41がFS-1へAP-REQを送り、FS-1がチケットの宛先・有効期限・認証子を検証する。相互認証や委任の設定は構成により異なる。
FS-1が共有権限とNTFS ACLを評価する。INV-1のLDAP照会は別経路であり、LDAPSの証明書検証とBind方法も確認する。

TGTを取れたこと、サービスチケットを取れたこと、FS-1が認証したこと、ファイルを閲覧できたことは四つの別の状態である。科目Bの設問では失敗した段階を一つに絞り、その段階の証拠を選ぶ。

4. 設定・記録のフィールドを読む

項目	読み方と注意点
Event 4768	DC側のTGT要求。利用者、クライアント、結果、暗号方式を読む。監査ポリシーが無効なら記録されない場合がある。
Event 4771	Kerberos事前認証失敗。時刻ずれ、誤った資格情報、攻撃試行など原因を分ける。回数だけで侵害確定とはしない。
Event 4769	DC側のサービスチケット要求。Account Name、Service Name、クライアントアドレス、結果、暗号方式を確認。発行とFS-1での利用は別。
SPN / service account	cifs/fs-1.example.testがどのアカウントに登録されるか。重複や誤登録はKDC_ERR_S_PRINCIPAL_UNKNOWN等の原因になる。
ticket lifetime / clock	期限と時刻同期。期限切れ、前後の時刻差、古いキャッシュは認証失敗の原因になる。単独ログの時刻はNTP差を補正する。
LDAP bind / transport	単純BindかSASLか、389/636か、StartTLSか、署名とチャネルバインディングの有無。ポートだけで暗号化と証明書検証を断定しない。
FS-1 access result	サービス側のサインイン結果と共有・NTFS権限の拒否を確認。DCの4769成功だけで実際のファイル操作成功とはしない。

以下は架空の認証記録。監査ポリシーは4768/4769を有効にしている。イベントの項目名や表示はWindowsの版と収集方法で異なるため、この記録は説明用に簡略化した。

text

09:00 DC-1 event=4768 account=U-41 client=WS-41 result=success
09:04 DC-1 event=4769 account=U-41
  service=cifs/fs-1.example.test client=WS-41 result=success
09:04 FS-1 auth=Kerberos user=U-41 result=success
09:04 FS-1 path=\\fs-1\team\budget.xlsx result=denied
09:06 INV-1 ldap_bind=unsigned port=389 result=success

U-41はTGTとFS-1向けサービスチケットを取得し、FS-1でKerberos認証も通った。しかしbudget.xlsxはACLで拒否されており、認証失敗ではない。INV-1の署名なしLDAP Bindは別の管理課題で、ファイル拒否の原因と短絡しない。LDAP側はBind方式、TLS、署名要件の実設定を調べる。

5. 異常が成立する条件と証拠

状態・攻撃	成立条件、証拠、対策の位置
TGTの窃取	端末上のチケットが奪われると有効期間中のサービスチケット要求に悪用され得る。端末保護、特権分離、チケット利用の監視が必要。
サービスチケットの窃取	FS-1向けチケットは指定サービスへの悪用に使われ得る。チケットの宛先と期限を確認し、TGTとの権限範囲の違いを説明する。
SPN誤設定	重複・別アカウントへの割当でサービスが復号できない。SPN登録、サービス実行アカウント、KDCとサーバのエラーを照合する。
LDAPの平文Bind	TLSなしの単純Bindは資格情報を保護できない。LDAPSまたはStartTLSと証明書検証、必要に応じた署名を適用する。
LDAP中間者	暗号化だけでクライアントが偽証明書を受け入れると保護が崩れる。信頼チェーン、名前、チャネルバインディング設定を確認する。
NTLMへのフォールバック	SPNや名前解決の失敗で想定外の認証方式へ移る場合がある。サービス側の認証方式を確認し、安易な互換設定変更を避ける。

Kerberosはパスワードを各サービスに渡さずに認証するが、チケットやサービスアカウント鍵の窃取には別の対策が要る。LDAPはディレクトリの照会・更新プロトコルであり、Kerberosの代名詞ではない。LDAP BindにKerberosを使う構成もある。

6. 調査で結論を強くする順序

判定段階	必要な証拠と結論の上限
サインインしたか	DCの4768、4771、端末サインインを照合。TGT取得と端末ログオンは同じログだけで完結しない。
何にアクセスしたか	4769のSPNとFS-1側のログを結ぶ。4769成功はチケット発行で、ファイル閲覧成功ではない。
どの方式か	FS-1の認証パッケージを確認。Kerberos、NTLM、匿名やキャッシュ認証を混同しない。
なぜ拒否されたか	共有権限、NTFS ACL、グループ、SID、条件付きアクセスを確認。認証と認可を分離する。
LDAPは安全か	Bind方式、TLS証明書、LDAP署名・チャネルバインディング、旧クライアントへの影響を試験する。

TGTはKDCにサービスチケットを求めるための資格であり、通常はFS-1へ直接提示しない。サービスチケットはFS-1のSPNに対応するサービスアカウント鍵で保護される。『TGTを取ったから全共有へ入れる』とは言えず、サービス側の認証とACL評価が後続する。

Kerberosの認証子は単純なチケット再送を避けるための時刻情報などを持つ。時刻同期が大きくずれると正しい資格情報でも拒否され得る。一方、時刻ずれのエラーだけで攻撃と断定せず、端末時計、DCのNTP、チケット期限を確認する。

SPNはホスト名・サービス種別とアカウントの対応である。cifs/fs-1.example.test向けのサービスチケットを取得する際、KDCは登録先アカウントを使う。FS-1の実行アカウントと違えば復号できず、KRB_AP_ERR_MODIFIEDなどが発生し得る。DNS名とSPNを一緒に点検する。

ADのグループ情報はチケット内の認可データにも反映され得る。グループ変更直後に古いチケットが残ると権限がすぐ変わらない場合がある。権限剥奪時はアカウント無効化だけでなく、チケットの有効期間、セッション、サービス接続を確認する。

LDAPの389番は平文だけと決め付けない。StartTLSで暗号化する構成もある。636番のLDAPSでも、証明書名・有効期限・信頼チェーンを検証しなければなりすましに弱い。署名、TLS、チャネルバインディングは互いに関連するが同義ではない。

4768と4769はドメインコントローラーの監査設定やイベント版に依存する。収集されていない記録の不存在を『要求がなかった』証拠にしない。DCが複数ある場合は全DCのログを集め、時刻、アカウント、クライアントアドレス、SPNを結ぶ。

サービスアカウントを一般利用者と同じ短いパスワードで運用すると、発行されたサービスチケットからのオフライン推測の対象になり得る。適切な長さのランダム秘密、管理対象サービスアカウント、不要SPNの除去、暗号方式の更新を検討する。これはKerberosの正常なTGS交換自体を止める話ではない。

7. 変更・障害・例外運用

運用場面	崩れやすい条件と確認
DC障害	新規チケット発行の失敗と、既存チケットによるサービス利用継続を区別。全DCの状態、DNS、レプリケーションを確認する。
SPN変更	旧名・別名・重複登録、サービスアカウントの変更、既存チケットの残存を検証し、切替中の失敗を追う。
LDAP強制設定	署名・チャネルバインディングを強制する前に旧クライアントをイベントで発見し、LDAPS/StartTLSと証明書を試験する。
グループ変更	権限付与・剥奪後の既存チケットとセッションを考慮し、共有・NTFS権限の実効値を確認する。
時間ずれ	WS、DC、FSの時刻源を確認し、ログの時差補正とチケット有効期間を区別する。

Kerberosの失敗を一律にパスワード再設定で解決しない。DNS/SPN、時刻、暗号方式、サービスアカウント、ACL、LDAPの保護設定は異なる層の問題である。層ごとの証拠で原因を絞る。

8. 封じ込めと復旧条件

AD認証異常の切分け

1. TGT確認：対応 AS交換を照合／確認する証跡 4768・4771
2. SPN確認：対応チケット要求を追う／確認する証跡 4769とSPN
3. サービス確認：対応 FSの認証を照合／確認する証跡 FS側ログ
4. 権限確認：対応 ACLとグループを照合／確認する証跡アクセス結果

発行・提示・認可の順に原因を狭める。

最初に失敗した段階を特定すると、パスワード、SPN、サービス鍵、ファイル権限のどれを直すべきか決まる。不審な認証があれば保全・封じ込めも並行し、設定変更だけで証拠を消さない。

DC-1、WS-41、FS-1の時刻と監査設定を確認し、4768・4769とFS側結果を保全する。
アカウント、SPN、サービスアカウント、DNS名、チケット期限を照合して発行・提示の失敗点を絞る。
侵害の疑いがあれば端末を調査し、チケットとセッションの残存、サービスアカウント秘密の保護を評価する。
必要な設定変更を検証環境で試し、共有権限とNTFS ACL、LDAPクライアントの動作を確認する。
正規利用者で再認証・ファイルアクセス・LDAP照会を試験し、全DCで異常が収束したことを確認する。

DCのサービスチケット発行成功だけをもって復旧完了としない。FS-1がチケットを受け入れ、権限に応じた操作が正しく許可・拒否され、LDAP利用アプリも安全なBindで動くことまで確認する。

9. 科目B（午後）の解答手順

時系列にAS-REQ/AS-REP、TGS-REQ/TGS-REP、AP-REQ、アクセス権評価を書き分ける。設問のログがDC側かサービス側かを先に特定し、観測できない段階を推測で埋めない。LDAPはディレクトリ照会として別に読む。

TGT、TGS交換、サービスチケットの語を区別する。
SPNとサービスアカウント鍵の対応を追う。
4768、4769、サービスログ、ACL結果の証拠範囲を分ける。
LDAPのTLS、署名、チャネルバインディングを混同しない。

10. 短答演習

演習1：4769成功

条件：DC-1がFS-1向けチケットを発行。

質問：ファイル閲覧は成功したか。

解答：不明。FS-1の認証結果とACLを確認する。

誤答の理由：チケット発行をアクセス許可と混同している。

演習2：ACL拒否

条件：FS-1認証成功、budget.xlsxはdenied。

質問：Kerberos障害か。

解答：認証は通っている。共有・NTFS権限を調べる。

誤答の理由：認可の拒否を認証失敗と扱っている。

演習3：SPN重複

条件：cifs/fs-1.example.testが複数アカウントに登録。

質問：何が起こり得るか。

解答：KDCの宛先解決やサービスでの復号に失敗し得る。

誤答の理由：SPNを単なる表示名とみなしている。

演習4：LDAP 389

条件：INV-1が389番へ接続。

質問：必ず平文か。

解答：断定できない。StartTLS、Bind方式、署名設定を確認する。

誤答の理由：ポート番号だけで保護状態を決めている。

演習5：チケット期限

条件：U-41のグループを削除した。

質問：既存アクセスも直ちに消えるか。

解答：既存チケットとセッションが残り得るため、その失効・再認証を確認する。

誤答の理由：ディレクトリ変更と発行済み資格の寿命を混同している。

演習6：LDAP強制

条件：DCで署名必須に変更予定。

質問：事前に何を調べるか。

解答：署名なしBindの利用者・アプリを監査し、TLS・証明書・互換性を試験する。

誤答の理由：設定変更による旧アプリ停止を考慮していない。

11. 一次資料

Microsoft：Kerberos authentication overview

Microsoft：KDCとAS/TGS

Microsoft：AD監査イベント4768・4769

Microsoft：LDAP署名とチャネルバインディング

Kerberos・Active Directory・LDAP認証の仕組み