はじめに
Linuxエンジニアにとって Kerberos は「SSSD (System Security Services Daemon) や Winbind の設定で苦労するもの」あるいは「Hadoop や SAP 認証で使う難しいやつ」というイメージかもしれません。しかし Windows/AD 環境ではこれがデフォルトの認証プロトコルです。
前回解説した NTLM と比較しながら、パケットの流れを追ってその仕組みを解剖します。
1. Kerberos とは：「信頼できる第三者」による認証
Kerberos の語源はギリシャ神話の地獄の番犬ですが、プロトコルとしては「クライアント」「サーバー」「KDC（鍵配布センター）」の3者間で認証を成立させる仕組みです。
NTLM が「パスワードを知っているか？」というチャレンジ／レスポンスだったのに対し、Kerberos は 「信頼できる第三者（KDC）が発行したチケットを持っているか？」 という考え方に基づいています。
| 比較項目 | NTLM | Kerberos |
|---|---|---|
| 信頼の仲介 | なし（クライアント↔サーバー直接） | KDC が仲介 |
| 暗号化 | MD4 ハッシュ（ソルトなし） | AES 共通鍵暗号 |
| 相互認証 | なし（サーバーの正当性を検証できない） | あり（偽サーバーへの接続を防ぐ） |
| DC への問い合わせ | 認証のたびに必要 | TGT 取得後は期限内 DC 不要 |
| 主な攻撃手法 | Pass-the-Hash | Kerberoasting、Golden Ticket |
AD 環境では Kerberos が利用可能であれば優先され、失敗した場合のみ NTLM にフォールバックします。意図せず NTLM にフォールバックしている状態は現代のネットワークでは脆弱性とみなすべきです（後述）。
2. 認証フロー：3フェーズで理解する
Kerberos の認証は大きく3段階に分かれます。Wireshark などでパケットを観察すると、以下の順でやり取りが見えます。
クライアント KDC (DC) ファイルサーバー
│ │ │
│──── ① AS_REQ ────────────▶│ │
│◀─── ① AS_REP (TGT) ───────│ │
│ │ │
│──── ② TGS_REQ (TGT+SPN) ─▶│ │
│◀─── ② TGS_REP (ST) ────────│ │
│ │ │
│──── ③ AP_REQ (ST) ────────────────────────────────────▶│
│◀─── ③ AP_REP (成功) ──────────────────────────────────│
① AS 交換（Authentication Service）：TGT の取得
「自分はドメインユーザーである」ことを KDC に証明し、TGT（Ticket Granting Ticket） を受け取るフェーズです。
- AS_REQ： クライアントが自分のユーザー名と、現在時刻をパスワードハッシュで暗号化したデータを送信します。タイムスタンプはリプレイ攻撃の防止に使われます。
- AS_REP： KDC がパスワードハッシュで復号に成功すれば、TGT を返します。TGT は KDC だけが持つ秘密鍵で暗号化されており、クライアントは中身を読めません。
Linux との対応：
kinit username@DOMAIN.COMがこのフェーズに相当します。
② TGS 交換（Ticket Granting Service）：サービスチケットの取得
「このサービスにアクセスしたい」と申請し、サービスチケット（ST） を受け取るフェーズです。
- TGS_REQ： クライアントが「TGT」と「アクセスしたいサービスの識別子（SPN）」を KDC に送信します。
- TGS_REP： KDC が TGT を検証し、対象サービス用のチケット（ST）を返します。ST は 対象サービスのパスワードハッシュで暗号化されています。
③ CS 交換（Client/Server）：実際のアクセス
- AP_REQ： クライアントが ST をサービス（ファイルサーバー等）に提示します。
- AP_REP： サービスが自分のパスワードハッシュで ST を復号し、正規 KDC 発行のチケットであることを確認してアクセスを許可します。
このフェーズでは DC に問い合わせが不要です。サービス自身が検証できるため、DC が落ちていてもすでに ST を持っていればアクセスできます。
3. Linux エンジニアがハマる AD Kerberos の落とし穴
概念は標準的な Kerberos と同じでも、AD 環境固有の挙動が多くあります。
SPN（Service Principal Name）の登録ミス
Windows では「どのサービスか」を HTTP/webserver01.example.com のような形式の SPN で識別します。この SPN が AD のユーザー・コンピューターオブジェクトに正しく登録されていないと、Kerberos 認証は即座に失敗し NTLM へフォールバックします。
# SPN の一覧を確認する
setspn -L DOMAIN\serviceaccount
# SPN を登録する
setspn -A HTTP/webserver01.example.com DOMAIN\serviceaccount
Linux 側から AD サービスにアクセスする場合も、SPN の不整合はよくあるトラブル原因です。
時刻同期（±5分の壁）
Kerberos のタイムスタンプは DC との時刻差が 5 分を超えると認証を拒否します。ntpd や chronyd が止まっていたり、VM のスナップショット復元後に時刻がズレたりするケースで一切のログインができなくなります。
# Linux 側の時刻確認
timedatectl status
# DC との時刻差を確認する（AD 参加済みの場合）
w32tm /stripchart /computer:dc01.example.com /samples:3
Keytab ファイルの扱い
Linux サーバーを AD に参加させる際に ktpass などで生成する Keytab ファイルは、Windows の「コンピューターアカウントのパスワード」をファイルに書き出したものです。
# Keytab を使った kinit（Linux での AD 認証）
kinit -kt /etc/krb5.keytab host/linuxserver01.example.com@EXAMPLE.COM
# Keytab の内容確認
klist -kt /etc/krb5.keytab
Keytab が漏洩するとサーバーへのなりすましが可能になります。ファイルのパーミッションは 600、所有者はサービスアカウントに限定してください。
4. 攻撃者が悪用するポイント
Kerberos の仕組みを理解することは、AD に対する代表的な攻撃手法を理解することとほぼ同義です。
| 攻撃手法 | 悪用するフェーズ | 概要 |
|---|---|---|
| Kerberoasting | ② TGS 交換 | ST はサービスアカウントのパスワードハッシュで暗号化されているため、ST を取得してオフラインでパスワードをブルートフォースできる |
| AS-REP Roasting | ① AS 交換 | 事前認証が無効なアカウントは TGT の一部をオフライン解析できる |
| Golden Ticket | TGT の偽造 | KDC の秘密鍵（krbtgt アカウントのハッシュ）を入手すれば任意の TGT を偽造可能。DC 再建まで有効 |
| Silver Ticket | ST の偽造 | サービスアカウントのハッシュを入手すれば ST を偽造可能。KDC を介さないため検知が難しい |
| Pass-the-Ticket | ③ CS 交換 | メモリから ST/TGT を抜き取り、別マシンで再利用する |
守る側の観点では、まず正常なチケットの流れを把握した上で、異常なチケット発行（大量の TGS_REQ、krbtgt パスワードの変更履歴）をイベントログで監視することが基本になります。
5. 実践：コマンドでチケットを観察する
Linux でお馴染みの klist は Windows でもそのまま使えます。
# 現在保持しているキャッシュチケットを表示する
klist
# チケットをすべて破棄する（再認証をテストしたいときに便利）
klist purge
klist の出力にある Ticket Flags を見ると、チケットの属性が確認できます。
| フラグ | 意味 |
|---|---|
FORWARDABLE |
チケットを別のサービスに転送可能（委任認証で使われる） |
RENEWABLE |
期限切れ前に更新可能 |
PRE-AUTHENT |
事前認証を経て発行されたチケット（AS-REP Roasting 対策済み） |
NTLM フォールバックを検出する
Kerberos のつもりが NTLM で認証されていないか確認するには、イベントログを確認します。
# セキュリティログから NTLM 認証イベントを抽出する（イベント ID 4776）
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4776} |
Select-Object TimeCreated, Message -First 20
LogonType や AuthenticationPackageName が NTLM になっているイベントが頻出する場合は、SPN の登録漏れや DNS 解決の問題を疑います。
まとめ
| 観点 | 内容 |
|---|---|
| 認証の仕組み | TGT → ST の2段階チケット方式 |
| 強み | 相互認証、DC 不要の検証、SSO の基盤 |
| 代表的な落とし穴 | SPN 未登録→NTLM フォールバック、時刻ズレ→認証不能 |
| 代表的な攻撃 | Kerberoasting、Golden Ticket、Pass-the-Ticket |
| 監視ポイント | イベント ID 4768/4769（TGT/ST 発行）、4776（NTLM 認証） |
Kerberos の3フェーズと「チケットの暗号化を誰が持つ鍵で行うか」さえ押さえれば、AD 認証のトラブルシューティングも攻撃の検知も、格段にアプローチしやすくなります。
次回、第7回は「グループポリシーの仕組み —— Ansible/Chef との比較で理解する Windows 構成管理」 です。