Kerberos認証
cover
おすすめ
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つのサーバとしての機能を持つ。
認証サーバ（AS：Authentication Server） クライアントからの認証を受け付ける。
チケット発行サーバ（TGS：Ticket Granted Service） 各サーバを利用するためのチケットを発行する。
プリンシパル
プリンシパル（Principal）とは、KDCが認証を行う全てのクライアント・サーバのこと。
プリンシパルはさらに「ユーザプリンシパル」と「サービスプリンシパル」に分けられる
ユーザプリンシパルサービスを利用する側であるクライアントのこと。
サービスプリンシパルサービスを提供する側であるサーバのこと。 プリンシパル内のサーバにはSPN(Service Principal Name)という識別子が割り振られている
JavaScript
レルム
同じKDCの配下にあるシステムをグループとして定義する論理ネットワーク。
Active Directoryの場合はドメインと一致する。
認証手順
Kerberos認証では、2種類のチケット「TGT」と「service ticket」を用いてアクセス許可の状態を管理する。
TGT(Ticket Granting Ticket)：ユーザ本人であることを証明するチケット。
service 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]
アクセスを許可し、認証に成功したことをクライアントに知らせる。
サーバはクライアントから要求されたデータを返す。