Kerberos認証
Kerberos認証の概要Kerberos認証の構成KDCプリンシパルレルム認証手順動作の詳細① KDCの認証サーバへ認証のリクエスト[AS_REQ]② KDCの認証サーバからTGTを受け取る [AS_REP]③ KDCのチケット発行サーバへTGTを送る[TGS_REQ]④ KDCのチケット発行サーバからservice ticketを受け取る [TGS_REP]⑤ 通信対象サーバへservice ticketを送る [AP_REQ]⑥ 通信対象サーバと通信する [AP_REP]
Kerberos認証の概要
Kerberos（ケロベロス）認証とは、ネットワーク認証方式の1つで、サーバとクライアント間の身元確認のために使用するプロトコル。
Windows Serverの「Active Directory」で利用されている認証方式として有名。
1度ログインを実行すると、次回のログイン時にID/パスワードを再度入力する必要がなく、シングルサインオンを実現する方式の一種として注目されている。
Kerberos認証の構成
Keroberosは、認証される対象の機器を「プリンシパル」と呼び、認証を実施するシステムを「KDC」と呼ぶ。
構成に関わるワードを以降で説明する。
KDC
KDC（Key Distribution Center）とは、サーバとユーザに関する信頼関係の情報を一括管理する中央データベース。
Active Directoryでは「ドメインコントローラ」とよばれるシステムのこと。
下記の2つのサーバとしての機能を持つ。
- （：Authentication Server） クライアントからの認証を受け付ける。
- （：Ticket Granted Service） 各サーバを利用するためのチケットを発行する。
プリンシパル
プリンシパル（Principal）とは、KDCが認証を行う全てのクライアント・サーバのこと。
プリンシパルはさらに「ユーザプリンシパル」と「サービスプリンシパル」に分けられる
- サービスを利用する側であるクライアントのこと。
サービスを提供する側であるサーバのこと。 プリンシパル内のサーバにはSPN(Service Principal Name)という識別子が割り振られている
レルム
同じKDCの配下にあるシステムをグループとして定義する論理ネットワーク。
Active Directoryの場合はドメインと一致する。
認証手順
Kerberos認証では、2種類のチケット「TGT」と「service ticket」を用いてアクセス許可の状態を管理する。
- (Ticket Granting Ticket)：ユーザ本人であることを証明するチケット。
- ：サーバのサービスにアクセスを許可するチケット。
クライアントが同一のレルム内のサーバと通信する際の認証手順は下記の図の通り。（下図の番号と対応）
① KDCの認証サーバへ認証のリクエスト
② KDCの認証サーバからTGTを受け取る
③ KDCのチケット発行サーバへTGTを送る
④ KDCのチケット発行サーバからservice ticketを受け取る
⑤ 通信対象サーバへservice ticketを送る
⑥ 通信対象サーバと通信する
以降では、上記の各認証フロー①〜⑥の詳細について解説します。
動作の詳細
① KDCの認証サーバへ認証のリクエスト[AS_REQ]
クライアントからKDCの認証サーバ（AS：Authentication Server）へ「AS_REQ」(Authentication Server Request)と呼ばれるパケットを送信する。
クライアントから送信するデータ
- ユーザ名・パスワードをハッシュ化し、NTLMハッシュを生成し、そのNTLMハッシュでタイムスタンプを暗号化して送信する。
KDCの認証サーバで検証する内容
- NTLMハッシュによって復号が成功するか？
- タイムスタンプが複製されたもので無いか？
② KDCの認証サーバからTGTを受け取る [AS_REP]
KDCの認証サーバは、「AS_REP」(Authentication Server Reply)パケットで TGTを送信する。
TGTに含まれるもの
- session key（パスワードハッシュで暗号化）
- グループ情報
- ドメイン
- タイムスタンプ
- クライアントのIPアドレス
KDCはTGT発行の際、KDCのみが知る秘密鍵（アカウントkrbtgtのパスワードパスワードハッシュ）でTGTを暗号化する。
TGTはデフォルトで10時間有効。
③ KDCのチケット発行サーバへTGTを送る[TGS_REQ]
クライアントはドメイン内のサーバへアクセスしたい時、KDCのチケット発行サーバ（TGS：Ticket Granted Service）へリクエストを送り、TGSを要求する。
Ticket Granting Service Request（TGS_REQ）と呼ばれるパケットを送る。
クライアントが送信するデータ
- 現在のユーザ名
- タイムスタンプ（session keyで暗号化）
- リソースのSPN
- TGT（暗号化）
KDCからservice ticketをリクエストする際には、ユーザの権限は検証されないため、SPNさえ知っていればTGSを取得可能。
KDCは指定されたSPNが存在すれば、TGTをKDCの秘密鍵で復号化し、session keyを抽出する。
session keyを使ってユーザ名とタイムスタンプを復号する。
KDCのチケット発行サーバで検証する内容
- TGTのタイムスタンプの有効期限は切れていないか？
- TGTのユーザ名と送られたユーザ名は一致しているか？
- TGTのIPとクライアントのIPは一致しているか？
④ KDCのチケット発行サーバからservice ticketを受け取る [TGS_REP]
Ticket Granting Server Reply（TGS_REP）のパケットの中身
- アクセスを許可するSPN
- クライアントとSPN間で使われるsession key
- service ticket（SPNのパスワードハッシュで暗号化）
- ユーザ名
- group memberships
- 新しいsession key
⑤ 通信対象サーバへservice ticketを送る [AP_REQ]
application request (AP_REQ)のパケットの中身
- ユーザ名
- タイムスタンプ（session keyで暗号化）
通信対象サーバで検証する内容
- service accountのパスワードハッシュでservice ticketを復号化し、ユーザ名とタイムスタンプを取得する。
service accountに紐付き実行されるアプリケーションは、service ticket内のgroup membershipからユーザの権限をチェックする。そのため、ユーザやグループの権限はチェックしない。
⑥ 通信対象サーバと通信する [AP_REP]
アクセスを許可し、認証に成功したことをクライアントに知らせる。
サーバはクライアントから要求されたデータを返す。