ポイント

●ケルベロス(Kerberos)認証とは,複数のサーバーと複数のユーザーの認証情報を一元管理するのに適したしくみである。やりとりする通信を暗号化する機能もある

●ケルベロス認証を実装するには,コンポーネント間で時刻同期が必要
●シングルサインオンとは,1回の認証で複数のサービスを利用できるようにするしくみのこと

 これまでにネットワーク環境で利用されている認証方式を見てきましたが,今回はケルベロス認証という技術を学びます。ユーザー情報を一元管理し,一度受けた認証情報をほかのサーバーへアクセスするときにも引き継げるようにする仕組みです。社内ネットなどに多数のユーザーとサーバーが存在し,個々のユーザーは同時に複数台のサーバーへアクセスする必要がある時に威力を発揮します。

PPPやRADIUSとは違う

 前回までネットワーク環境で利用される認証方式をいくつか紹介してきました。ここで簡単に整理をしておきましょう。

 前々回(第2章の6回目「PPPで使われるPAPとCHAP 」)に学んだPPP(Point to Point Protocol)は,PAPやCHAPというプロトコルを利用して,ユーザーとサーバーが1対1の関係で認証するしくみでした。

 前回(第2章の7回目「RADIUSとAAAサービス」)で学んだRADIUSは,認証のための情報をRADIUSサーバーが一元管理することにより,ユーザーはどこのアクセス・ポイントのサーバーへも同じIDとパスワードで認証を受けることができるしくみでした。

 今回勉強するケルベロス認証は,複数のユーザーそれぞれが,複数のネットワーク・リソース(サーバー)を利用するようなケースにおいて,一度だけ認証を受ければ複数のサービスを利用できるようにするしくみです。

複数サーバーに複数のユーザーがアクセス

 例えば,企業ネットにおけるファイル・サーバーの利用を考えてみましょう。ファイルサーバーが1台あり,これにアクセスを許された社員が10人いたとします。この程度でしたら,管理者の負担はそれほど多くはありません。また,ユーザーはあらかじめ割り振られているIDとパスワードを利用して,ファイル・サーバーにアクセスすればよいので,ユーザーにとってもそれほど不便ではありません。

 ところが,ファイル・サーバーが10台,社員が1000名になったとします。管理者は,誰がどこのサーバーにアクセスしてよいのかの組み合わせを把握するのはもちろん,必要な認証情報の登録・削除作業を間違いなく処理する必要があります。先ほどの例と比較すると,単に仕事量が増えるだけではなく,管理が複雑かつ煩雑になり,負担が大きくなります。また,ユーザーはアクセスするサーバーごとにパスワードやIDを使い分けなければならず,とても不便です。

 仮にすべてのファイル・サーバーに同じIDとパスワードを登録しておいたとしても,ユーザーは新しいファイル・サーバーへアクセスするたびに,ログインする必要が出てきます。管理者にとっても,ユーザーを1人追加するのに,10台のファイル・サーバーに登録する必要があります。

 ケルベロス認証では,KDCと呼ばれる機関(サーバー)を用意し,そこに認証情報を一元管理させます。認証情報を一元管理するだけなら,RADIUSサーバーでもできますが,ケルベロス認証はそれだけではありません。

 ユーザーが複数サーバーを利用する場合,一度認証を受けるだけで,ほかのサーバーへもアクセスできるようになり,何度もログインする必要がなくなります。

ケルベロス認証にかかわる登場人物

 ケルベロス認証は,RFC4120やRFC4121で規定されています。認証のほかに通信を暗号化する機能もあり,プロトコルはかなり複雑です。また,ちょっと耳慣れない用語も出てきます。ここでは,基本的なしくみを確認していきましょう。まず,ケルベロス認証に関係するコンポーネントを見てみます(図1)。

図1 ケルベロス認証に関係するコンポーネントとその名称

 サーバーやユーザーに関しての信頼関係の情報を一括して管理する機関を「KDC(Key Distribution Center)」といいます。KDCにはいくつかの機能があり,ユーザーからの認証を受け付ける「AS(Authentication Server)」,各サーバーを利用するためのチケットを発行する「TGS(Ticket Granting Server)」などがあります。

 KDCが認証するサーバーやユーザーのことを「プリンシパル」と呼びます。そして,これらを一つのかたまりとして扱い,そのかたまりを「レルム」と呼びます。

認証を受けたらチケットをもらう

 次に,ユーザーAがファイル・サーバーFを利用するときのシーケンスを追いかけてみましょう(図2)。

図2 ケルベロス認証の流れ

 まずユーザーAは,KDCのASに認証してもらいます(1)。正しいIDとパスワードで認証に成功すると,ユーザーに対してTGT(Ticket Granting Ticket:チケット発行のための大もとのチケット)が発行されます(2)。

 次に,ユーザーはKDCのTGS(Ticket Granting Server)に対して,実際にアクセスしたいサーバーへの利用権を請求します(3)。すると,TGSはユーザーに対して,チケットと呼ばれるものを発行します(4)。ユーザーはこのチケットをアクセス先のサーバーへ提出して,これを受け取ったサーバーはユーザーを認識し,そのユーザーに合ったアクセスを許可します(5)。

ケルベロス認証に必要な機能とは

 ところで,ケルベロス認証を実装するにあたって,各構成要素間で考慮しておかねばならないことがあります。ある機能が必要になるのですが,イメージできるでしょうか?