セキュリティー -> Kerberos

Kerberos (ケルベロス)

概要

KDCの構成

KDCに関する用語は以下の通りである

	
KDC Key Distribution Center  
AS Authentication Server 認証サーバ
TGS Ticket Granting Server 発行サーバ
TGT Ticket Granting Tiket ユーザチケット
 Sevice Ticket サービスチケット
※ 日本語(認証サーバ、発行サーバ、ユーザチケット)での呼び名は多々あるがここではこれに統一する。

認証プロセス

      (1) クライアントが KDC に対してユーザチケット(TGT)の要求を行う。

          チケットの取得時に唯一パスワードが要求される。パスワードが要求されるタイミングは、
          Linuxの場合はチケット要求 "kinit" コマンド入力時、Windowsの場合はActiveDrecotryへのログオン時である。
          認証が成功した場合、kerberos対応のサービス利用する際、パスワードを入力する必要はない。
          これによりkerberos認証によるシングルサインオン機能の実現が可能となる。

      (2) KDCの認証サーバ(AS)がクライアントに対してユーザチケット(TGT)を発行する。

          認証サーバ(AS)からクライアントへは、ユーザチケット(TGT)とセッション鍵Aがの2つ送信される。
          ユーザチケット(TGT)はユーザが入力したパスワードで暗号化されている。
          セッション鍵は、発行サーバ(TGS)との暗号化通信で利用する。

          Linuxの場合 "klist"コマンドで取得したユーザチケット(TGT)の表示ができる。
          Windowsの場合は、ActiveDirectory(=KDC)にログオン時ここまでの処理が内部で行われている。

          以降の処理はkerberos認証に対応したサービス利用時に行われる。(例:ファイルサーバ等)

      (3) クライアントが認証サーバ(AS)から受け取ったユーザチケット(TGT)を 発行サーバ(TGS)に提示する。
          この処理は、クライアントが目的の(ファイルサーバ利用等)サービスチケットを要求した場合に行われる。
          クライアントと発行サーバとの通信は、(2)で受け取ったセッション鍵Aを使用して暗号化される。

      (4) 発行サーバ(TGS)はクライアントから受け取ったサービスチケット(TGT)を調べてサービスチケットを発行する。

          発行サーバ(TGS)はクライアントに、サービスチケットとサービス提供サーバとの暗号化通信に利用する
          セッション鍵Bの2つ送信する

          (2)のセッション鍵A( クライアント - TGS 間 ) と 
          (3)のセッション鍵B( クライアント - サービス提供サーバ間 ) は同じものではない。

      (5) クライアントはサービスチケットを利用してサービス提供サーバにアクセスする。

          クライアントは、サービスチケットをサービス提供サーバに提示する。
          この間の通信は、セッション鍵Bを利用して暗号化される。

kerberos利用にあたり理解しておく事

    実際の設定に当たって理解すべき内容について記述する。

    キーワード:レルム名、プリンシパル

    クライアント(Linuxの場合)が "kinit" コマンドを実行しユーザチケットを要求した際を例に説明する。
    ユーザ名           ( jal1014  )
    クライアント       ( nikkou   )
    サービス提供サーバ ( haneda   )
    利用サービス名     ( rw34lapr )
    KDCサーバ          ( contorol ) 
    レルム名           ( TRANSPORT.COM )

    ユーザ( jal1014 )がユーザチケットの要求を行を行う場合

    $kinit jal1014 
    Password for jal1014@TRANSPORT.COM: ****** ←パスワード入力 
    
    この場合どうやって KDC を探すのか?
    クライアント(nikkou)/etc/krb5.donfの記述にレルム名(ドメイン名のようなもの)が記述してある。
    これを見れば KDCサーバがどれなのかがわかる。

       TRANSPOTION.COM { 
             kdc = tktower.transport.com 
       } 

       ※ krb.confに記述するレルム名は KDCサーバ、サービス提供サーバ、クライアント全てに必要である。
       ※ サーバ名(kttower.transport.com)を /etc/hosts 又は DNS を登録しておくこと。
       ※ Windowsの場合は ActiveDirectory に ドメイン参加していればよい。

    サービスチケットの要求に当たって当然、KDC に利用ユーザが認識されていなければならない。
    これは、プリンシパルによって行われる
    サービス提供サーバ、利用サービスも同じ事である。

    まず、ユーザプリンシパルは以下の名前になる
    jal1014@TRANSPORT.COM  (ユーザ名@レルム名)

    サービス提供サーバ( haneda )であるホストプリンシパルは以下の通り
    host/haneda.transport.com@TRANSPORT.COM     ( host/サービス提供サーバ名/FQDN@レルム名 )

    利用サービス名( rw34lapr )であるサービスプリンシパルは以下の通り
    rw34lapr/haneda.transport.com@TRANSPORT.COM ( 利用サービス名/サービス提供サーバ名/FQDN@レルム名 )
    * FQDN: 完全修飾ドメイン名

    以上の3つのプリンシパルを KDC のデータベースに登録する。

    プリンシパル(サービスチケット)の確認をする場合 "klist" コマンドで確認するが、
    "klist"では、利用中のサービス提供サーバのホストプリンシパル(ユーザチケット)及び 
    "kinit"で取得したユーザチケット(TGT)のみが表示される。

    * ユーザチケット(TGT)    krbtgt/TRANSPORT.COM         

    登録されているプリンシパルを確認するには "kadmin" コマンドにより参照する。

    コマンドについては以降で説明する。

      Document-Folder          一覧
HP-UX
HULFT
JAVA
JP1
JavaScript
Linux
MAC
PHP
Perl
Python
Ruby
SOA
Solaris
Unix全般
Windows
XML
エクセル
スタイルシート
セキュリティー
データベース
ネットワーク
パソコン
ブラウザ
プログラム構文
仮想化
          RSS-Folder
ニュース
   アットマーク・アイティ(@IT)
   シンクイット(ThinkIT)
   インターネットコム
   インターネットウォッチ
   日経IT-Pro
   日経パソコン
   CNET Japan
   ZD-NetJapan
   MYCOM
   RBB-Today
ベンダー
   日本IBM
   日本HP
   サンマイクロシステムズ
   NEC
   富士通
   日立
ソフトウェア
   マイクロソフト
   トレンドマイクロ
   オラクル
   サイボウズ
   Mozilla
   野村総合研究所
   (その他ソフトウェア企業)
更新履歴 一覧
 07/08 PERF
プログラム構文
 07/07 PERF
プログラム構文
 06/25 オブジェクトプログラミング2
Perl>サンプル
 07/12 クローン作成
仮想化>vCenter
 07/12 vyatta設定
ネットワーク>vyatta
 07/12 vyattaインストール
ネットワーク>vyatta
 07/12 リポジトリサーバ
Linux>サーバ構築
 07/05 VMwareのインストール
仮想化>VMware
 07/05 PXEブート
仮想化>KVM
 07/01 DHCPでのPXEブート
仮想化>KVM
 06/27 qcow2仮想DISK作成
仮想化>KVM
 06/13 NWの設定
仮想化>VMwareEsxi
 06/13 IPアドレスの変更
仮想化>VMwareEsxi
 06/12 自動ssh
Unix全般>シェル>Bash
 06/12 diffプログラミング
Python
Google