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]
アクセスを許可し、認証に成功したことをクライアントに知らせる。
サーバはクライアントから要求されたデータを返す。