Active Directory の Kerberos 認証

概要

Kerberos は Active Directory で標準的に使われるチケット型の認証プロトコルです。サービスにパスワードを直接送らず、KDC（Domain Controller）から取得したチケットで認証します。クライアント・KDC・サービス間で共有鍵暗号を用いたチケットとセッションキーをやり取りし、相互認証とシングルサインオンを実現します。

主要な登場要素

クライアント: 認証を行うユーザーや端末。ローカル LSA にチケットキャッシュを保持する。
サービス：認証先のサーバーやアプリケーション（IIS、SMB、SQL など）。サービスアカウントまたは computer account の鍵でチケットを復号します。
KDC: Domain Controller 上の認証サービス。AS（Authentication Service）と TGS（Ticket Granting Service）を提供する。
キー素材: ドメインユーザー/コンピュータ/サービスアカウントの NT ハッシュから派生する長期鍵。チケット内のセッションキーは短期鍵。

チケットと鍵の種類

TGT (Ticket Granting Ticket): KDC の krbtgt アカウントの鍵で暗号化される。クライアントは TGS 取得にのみ利用。
サービステケット: 特定 SPN 用。対応サービスアカウントの鍵で暗号化される。
PAC (Privilege Attribute Certificate): チケット内に埋め込まれるユーザーの SID/グループ/権限情報。サービスは PAC を検証してアクセストークンを組み立てる。
セッションキー: クライアントと KDC、またはクライアントとサービス間で使用する短期共有鍵。
暗号スイート: AES256/AES128/RC4 など。近年は AES 系が推奨。

認証の流れ

AS-REQ: クライアントは自分のユーザー名とタイムスタンプ（pre-auth データ）を送り、TGT を要求。タイムスタンプはクライアント鍵で暗号化。
AS-REP: KDC は pre-auth を検証し、TGT とクライアント/KDC 間セッションキーを返す。TGT は krbtgt 鍵で暗号化され、クライアント側では内容は読めない。
TGS-REQ: クライアントは保持している TGT と、アクセスしたい SPN を提示し、サービステケットを要求。リクエストは TGT から得たセッションキーで保護される。
TGS-REP: KDC は TGT を krbtgt 鍵で復号し、SPN 対応のサービステケットとクライアント/サービス間セッションキーを返す。
AP-REQ: クライアントはサービステケットと Authenticator（セッションキーで暗号化されたタイムスタンプ・ユーザー名）をサービスへ送信。
AP-REP（相互認証時）: サービスはサービステケットを自分の鍵で復号し、Authenticator をセッションキーで復号してタイムスタンプ検証。成功時は応答を返し、クライアントとサービスが同一セッションキーを共有する。
アクセストークン生成: サービスは PAC を検証し、Windows の場合は LSA がローカルトークンに変換してアクセス制御（ACL）判定に使う。

シーケンス図（AS/TGS/AP）

sequenceDiagram
    actor Client
    participant DC as KDC (AS/TGS)
    participant Service
    Client->>DC: AS-REQ (pre-auth タイムスタンプ)
    DC-->>Client: AS-REP (TGT + セッションキー)
    Client->>DC: TGS-REQ (TGT + SPN)
    DC-->>Client: TGS-REP (サービステケット + セッションキー)
    Client->>Service: AP-REQ (サービステケット + Authenticator)
    Service-->>Client: AP-REP (相互認証が必要な場合)
    Service-->Service: PAC 検証→アクセストークン生成

TGT の意味と扱い

TGT は「KDC に対する身分証」。サービスには送らない（TGS-REQ にのみ使用）。
有効期間: 既定で 10 時間程度。更新期限（Renewal）も別に持つ。
KDC ごとに kvno（Key Version Number）を確認し、パスワード変更後の鍵でも復号できるように kvno が一致する必要がある。
キャッシュ: Windows では klist で確認/削除できる。ローカル再起動でキャッシュは消えるが、ローミングプロファイルでは持ち越さない。

SPN（Service Principal Name）

形式: <ServiceClass>/<Hostname>:<Port>/<ServiceName>。例: HTTP/web.contoso.com, MSSQLSvc/sql.contoso.com:1433, HOST/file01.
種類・クラス: SMB は CIFS/HOST、IIS は HTTP、SQL Server は MSSQLSvc など。HOST は汎用クラスで多くのサービスが自動登録する。
登録主体: computer account は HOST/CIFS を自動登録。サービスアカウントで動かす場合は setspn -S で重複なしに手動登録が必要。
重複・欠落の影響: 重複 SPN はチケット取得失敗の原因。SPN 未登録は Kerberos 失敗→NTLM フォールバックを招く。
特殊 SPN krbtgt/<REALM>: KDC が TGT を暗号化するためのアカウント（krbtgt）に紐づく。通常は DC 自動管理で手動変更不要。誤って削除・変更すると全 TGT 発行/検証が失敗するため触らない。

krbtgt パスワードローテーションと kvno

kvno (Key Version Number): チケットに埋め込まれる鍵の世代番号。チケットを復号するときに KDC/サービスは kvno に対応する鍵を選択する。
krbtgt ローテーションの目的: DC 認証キーを更新し、古い krbtgt 鍵で偽造された Golden Ticket を無効化する。通常のパスワード変更と同様に kvno がインクリメントされる。
Windows DC は krbtgt の直近 2 世代の鍵を保持できるため、ローテーションは「2 回実施」が推奨。1 回目で次の kvno を導入し、チケット有効期間とレプリケーションが行き渡った後、2 回目でさらに kvno を進め古い鍵を退役させる。
タイミングの目安: ドメインの TGT 最大存続期間（既定 10h）＋更新期間（既定 7d）＋ DC レプリケーション時間を考慮し、1 回目と 2 回目の間隔を設定する。
実施上の注意:
- PDC エミュレータで Set-ADAccountPassword -Identity krbtgt を実行し、十分なレプリケーション完了を待つ。
- ローテーション中に長時間稼働セッションは再認証を求められる場合がある。重要システムは計画停止かメンテナンス告知を行う。
- kvno 不一致で TGT が復号できないと AS-REP/TGS-REP で失敗する。必要に応じて古い kvno を保持している DC にレプリケーションが行き渡っているか確認する。
- 信頼 (trust) ドメイン/フォレストにも krbtgt 相当の信頼キーがあるため、クロスフォレスト認証に影響が出ないようレプリケーションと時間を確保する。

時刻同期が必須な理由

チケット・Authenticator に時刻を埋め込み、リプレイ攻撃を防ぐ。許容スキューは既定 ±5 分（MaxSkew）。超過すると KRB_AP_ERR_SKEW。
Pre-auth タイムスタンプ検証にも時刻が必要。時刻ずれで AS-REQ 失敗→NTLM フォールバックやログオン不可になる。
KDC とクライアント・サービス間で NTP/W32Time による同期が必須。フォレスト間トラストでも同様。

チケット取得後の利用

セッション確立: AP-REQ/AP-REP の後、クライアントとサービスはセッションキーでメッセージ署名/暗号化（SMB 署名、LDAP Signing など）を行う。
キャッシュ再利用: 同一 SPN へのアクセスはキャッシュ済みサービステケットを再利用し、再度 TGS-REQ を送らない。
チケット更新: TGT の有効期間が切れそうな場合、更新期限内であれば自動更新。サービステケットは基本的に再取得。
ログオンセッション: PAC 情報から生成されたトークンはプロセスに紐づく。グループ変更は新しいログオンが必要。

委任と関連機能

非制約委任（Unconstrained Delegation）: サービスは受け取った TGT をキャッシュし、バックエンドへの TGS-REQ に使用できる。リスクが高い。
制約付き委任（Constrained Delegation/Kerberos Only）: 事前に許可した SPN へのみ委任可能。TGS は forwardable フラグ付き。
リソースベース制約付き委任（Resource-Based Constrained Delegation, RBCD）: バックエンドサービス側が委任を許可するモデル（msDS-AllowedToActOnBehalfOfOtherIdentity）。
S4U (Service for User): S4U2self でユーザー代理のサービステケット取得、S4U2proxy で委任先へのサービステケット取得。IIS/SSO/印刷サービスなどで利用。

委任シナリオのシーケンス（S4U2self/S4U2proxy）

sequenceDiagram
    actor User
    participant Front as フロントサービス (委任許可済み)
    participant DC as KDC (TGS)
    participant Back as バックエンドサービス
    User->>Front: AP-REQ (ユーザーチケット)
    Front->>DC: TGS-REQ S4U2self (User→Front 用)
    DC-->>Front: TGS-REP (User→Front サービステケット)
    Front->>DC: TGS-REQ S4U2proxy (User→Back, forwardable)
    DC-->>Front: TGS-REP (User→Back サービステケット)
    Front->>Back: AP-REQ (User→Back サービステケット + Authenticator)
    Back-->>Front: AP-REP (相互認証が必要な場合) / PAC 検証

klist と setspn の基本操作

klist: チケットキャッシュ確認/削除。
- klist（無引数）: 取得済み TGT とサービステケット一覧を表示。
- klist tickets / klist tgt: サービステケットのみ / TGT のみを確認。
- klist purge: すべてのチケットを削除（再認証が必要になるので影響範囲に注意）。
- klist get <SPN>: 指定 SPN のサービステケットを事前取得（Prefetch）。事前検証や接続前テストに有用。
- 典型出力例:
```
Current LogonId is 0:0x3e7
Service Name           : krbtgt/CONTOSO.COM
  Ticket Flags         : 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
  Start Time           : 9/1/2024 10:00:00 (local)
  End Time             : 9/1/2024 20:00:00 (local)
  Renew Time           : 9/8/2024 10:00:00 (local)
```
setspn: SPN の確認・登録・重複検出。
- setspn -L <Account>: 指定アカウント（サービス/コンピュータ）の SPN 一覧を表示。
- setspn -S <SPN> <Account>: SPN を重複チェックしながら登録。重複があるとエラーで停止するため安全。
- setspn -D <SPN> <Account>: SPN を削除。
- setspn -Q <SPN>: SPN の所有者を検索（重複や誤登録の調査に使用）。
- setspn -X: 重複 SPN を全検索。定期的なヘルスチェックに有効。

運用とトラブルシュート

DNS 依存: Kerberos は FQDN/SPN で動く。名前解決失敗は NTLM フォールバックや KRB_AP_ERR_MODIFIED に直結。
イベントログ: DC の System/Security ログ（4768 AS、4769 TGS、4771 失敗、4776 NTLM）で追跡する。
ツール: klist, setspn, nltest /dsgetdc, w32tm /query /status が基本。Wireshark で kerberos フィルタを使うとフロー確認が容易。
セキュリティ注意: RC4 無効化、AES 優先、krbtgt パスワードの定期ローテーション、不要な委任の削除、SPN 重複チェックを推奨。