Kerberos認証

おすすめ
 

Kerberos認証の概要

Kerberos(ケロベロス)認証とは、ネットワーク認証方式の1つで、サーバとクライアント間の身元確認のために使用するプロトコル。
Windows Serverの「Active Directory」で利用されている認証方式として有名。
1度ログインを実行すると、次回のログイン時にID/パスワードを再度入力する必要がなく、シングルサインオンを実現する方式の一種として注目されている。
仕様は RFC 4120で標準化されており、公式のリファレンスは「http://web.mit.edu/kerberos/」となる。

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]

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