第 7 章 SEAM リファレンス

この章では、SEAM 製品の一部であるファイル、コマンド、およびデーモンのリストを示します。さらに、Kerberos 認証システムの動作についても詳細に説明します。

次に、この章で取り上げる内容のリストを示します。

• 「SEAM ファイル」

• 「SEAM コマンド」

• 「SEAM デーモン」

• 「SEAM の用語」

• 「認証システムの動作」

• 「SEAM によるサービスへのアクセス」

SEAM ファイル

PAM 構成ファイル

SEAM に付属するデフォルトの PAM 構成ファイルには、新しい Kerberos 化されたアプリケーションを処理するためのエントリが含まれています。新しいファイルには、認証サービス、アカウント管理、セッション管理、およびパスワード管理のモジュール用のエントリが含まれています。

認証モジュールの場合は、rlogin、login、dtlogin、krlogin、ktelnet、および krsh 用の新しいエントリです。次に、これらのエントリの例を示します。これらのサービスはすべて新しい PAM ライブラリ /usr/lib/security/pam_krb5.so.1 を使用して、Kerberos 認証を提供します。

最初の 3 つのエントリは try_first_pass オプションを使用して、ユーザーの初期パスワードによる認証を要求します。初期パスワードを使用することは、複数の機構がリストに指定されている場合でも、ユーザーは別のパスワードを入力する必要がないということです。

次の 3 つのエントリは -acceptor オプションを使用して、PAM モジュールが初期チケット許可チケットを取得する手順を実行しないようにします。Kerberos 化されたサーバーアプリケーションの場合、この手順はすでにアプリケーションによって実行されているため、この手順を PAM で行う必要はありません。また、other エントリはデフォルトのエントリで、特に指定されていないが認証が必要であるすべてのエントリ用です。

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

アカウント管理の場合、dtlogin は Kerberos ライブラリを使用する新しいエントリを持っています (次を参照)。other エントリはデフォルトの規則を提供します。現在のところ、other エントリは何もしません。

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

次に、/etc/pam.conf ファイルの最後の 2 つのエントリを示します。セッション管理用の other エントリはユーザー資格を削除します。パスワード管理用の新しい other エントリは Kerberos ライブラリを選択します。

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM コマンド

この節では、SEAM 製品に含まれているコマンドのリストを示します。

SEAM デーモン

次の表に、SEAM 製品で使用されるデーモンのリストを示します。

SEAM の用語

次の節では、SEAM 文書で使用される用語とその定義を示します。SEAM 関連のドキュメントの説明を理解するためには、これらの用語を理解している必要があります。

認証に固有な用語

次に説明する用語は、認証プロセスを理解するために必要です。プログラマとシステム管理者はこれらの用語を理解している必要があります。

クライアントとは、ユーザーのワークステーション上で動作するソフトウェアのことです。クライアント上で動作する SEAM ソフトウェアは、認証プロセス中に多くの要求を作成します。したがって、このソフトウェアの動作とユーザーの動作を区別することは重要です。

多くの場合、サーバーとサービスという用語は同じ意味で使用されます。ここでは両者を区別します。サーバーという用語は、SEAM ソフトウェアが動作している物理的なシステムを定義するために使用されます。サービスという用語は、サーバー上でサポートされている特定の機能 (たとえば、ftp や nfs) に対応します。文書内でサーバーはサービスの一部として表現されることがあります。しかし、この定義を使用すると、これらの用語の意味が曖昧になります。したがって、サーバーは物理的なシステムを指し、サービスはソフトウェアを指すものとします。

SEAM 製品には 3 種類の鍵があります。1 つは非公開鍵です。非公開鍵は各ユーザープリンシパルに与えられます。非公開鍵を知っているのは、そのプリンシパルのユーザーと KDC だけです。ユーザープリンシパルの場合、鍵はユーザーのパスワードが元になっています。2 つめはサービス鍵です。サービス鍵の目的は非公開鍵と同じですが、サーバーとサービスによって使用されるところが異なります。3 つめはセッション鍵です。セッション鍵は、認証サービスまたはチケット許可チケットによって生成されます。セッション鍵は、クライアントとサービス間でセキュリティの保護されたトランザクションを提供するために生成されます。

チケットとは、ユーザーの識別情報をサーバーまたはサービスに安全に渡すために使用される情報パケットのことです。チケットは、単一のクライアントおよび特定のサーバー上にある特定のサービスにとってだけ有効なものです。チケットには、サービスのプリンシパル名、ユーザーのプリンシパル名、ユーザーのホストの IP アドレス、タイムスタンプ、およびチケットの有効期間を定義する値が入っています。チケットは、クライアントとサービスで使用されるランダムなセッション鍵とともに作成されます。作成後、チケットは有効期限が切れるまで何度でも使用できます。

資格とは、チケットとそれに一致するセッション鍵を含む情報パケットのことです。多くの場合、資格は (資格の暗号を解読するかどうかによって) 非公開鍵またはサービス鍵で暗号化されます。

オーセンティケータとは、別の種類の情報です。チケットとともに使用されると、オーセンティケータはユーザープリンシパルを認証するために使用されます。オーセンティケータには、ユーザーのプリンシパル名、ユーザーのホストの IP アドレス、およびタイムスタンプが入っています。チケットとは異なり、オーセンティケータはサービスへのアクセス権が要求されたときに 1 回だけ使用できます。オーセンティケータは、当該クライアントと当該サーバーのセッション鍵で暗号化されます。

チケットの種類

チケットには、その使い方を決定する属性があります。属性は、チケットの作成時にチケットに割り当てられます。しかし、チケットの属性はこの後でも変更できます。たとえば、チケットを「転送可能」から「転送」に変更できます。チケットの属性を表示するには、klist コマンドを使用します (「チケットを表示するには」を参照)。

チケットは、次に示す属性によって分類されます。

転送可能 / 転送

転送可能チケットはあるホストから別のホストに送信できるため、クライアントが自分自身を再び認証する必要がなくなります。たとえば、ユーザー david が jennifer のマシン上で転送可能チケットを取得した場合、新しいチケットを取得しなくても (したがって、自分自身をもう一度認証しなくても)、自分のマシンにログインできます。転送可能チケットの例については、「例 - チケットを作成する」を参照してください。転送可能チケットと代理可能チケット (次を参照) を比較してください。

初期

初期チケットとは、チケット許可チケットに基づくのではなく、直接発行されるチケットのことです。一部のサービス (パスワードを変更するアプリケーションなど) は、クライアントが自分の秘密鍵を知っていることを示すために、「initial (初期)」というマークが付いたチケットを要求できます。これは、初期チケットがクライアントが自分を認証したのが最近であることを示すためです。一方、チケット許可チケットに基づくチケットは、長時間使用されていた可能性があることを示します。

無効

無効なチケットとは、遅延チケットのことで、まだ有効になっていないチケットのことです (次の「遅延」を参照)。有効性が確認されるまで、アプリケーションサーバーはチケットを拒否します。有効性を確認するためには、起動後に、クライアントが TGS 要求中に VALIDATE フラグを設定することによって、KDC にチケットを示さなければなりません。

遅延可能 / 遅延

遅延チケットとは、作成後から特定の時間が経過するまで有効にならないチケットのことです。このようなチケットは、真夜中に実行したいバッチジョブなどに便利です。これは、チケットが第三者に漏れたとしても、バッチジョブが実行されるまで使用できないためです。発行時、遅延チケットは無効であり、起動されるまで、あるいはクライアントが KDC による有効性の確認を要求するまで無効な状態が続きます (上記の「無効」を参照)。遅延チケットは通常、チケット許可チケットの有効期限が切れるまで有効です。しかし、「更新可能」というマークを付けた場合、そのチケットの有効期間はチケット許可チケットの有効期間と同じに設定されます。次の「更新可能」を参照してください。

代理可能 / 代理

場合によってはサービスがプリンシパルの代わりに操作を実行することをプリンシパルが許可する必要もあります。たとえば、第 3 のホスト上で印刷ジョブを実行するようにプリンシパルがサービスに要求するときなどです。サービスはクライアントの識別情報を取得する必要があります。しかし、これは単一の操作だけ必要となります。この場合、サーバーはクライアントの代理として動作しています。代理のプリンシパル名は、チケット作成時に指定しなければなりません。

代理可能チケットは転送可能チケットに似ています。しかし、代理可能チケットは単一のサービスでだけ有効です。一方、転送可能チケットは、クライアントの識別情報を使用するためのアクセス権をサービスに許可します。したがって、転送可能チケットは代理可能チケットのスーパーセットと考えられます。

更新可能

チケットの有効期間が長いとセキュリティが保たれなくなることがあるため、チケットは更新可能にすることができます。更新可能チケットは 2 つの有効期限を持ちます。1 つは、チケットの現在のインスタンスの有効期限が切れる時間です。もう 1 つは、すべてのチケットの最大有効期間です。クライアントがチケットを使用し続けたい場合、クライアントは最初の有効期限に到達する前にチケットを更新します。たとえば、あるチケットが 1 時間だけ有効であり、すべてのチケットの最大有効期間が 10 時間であると仮定します。チケットを保有するクライアントが 1 時間よりも長くチケットを使用したい場合、クライアントはその時間内にチケットを更新します。チケットがすべてのチケットの最大有効期間 (10 時間) に到達した場合は、自動的に有効期限が切れて、更新できなくなります。

チケットとその属性を表示する方法については、「チケットを表示するには」を参照してください。

チケットの有効期間

プリンシパルがチケット (チケット許可チケットも含む) を取得するとき、チケットの有効期間は次の有効期間の中の最小値に設定されます。

• kinit でチケットを取得する場合、kinit の -l オプションで指定した有効期間の値

• kdc.conf ファイルで指定した最大有効期間の値 (max_life)

• チケットを提供するサービスプリンシパルに対して Kerberos データベースで指定した最大有効期間の値 (kinit の場合、サービスプリンシパルは krbtgt/realm)

• チケットを要求するユーザープリンシパルに対して Kerberos データベースで指定した最大有効期間の値

図 7-1 に、TGT の有効期間がどのように決定されるかを示します。また、4 つの有効期間がどのように指定されているのかも示します。図 7-1 は TGT の有効期間がどのように決定されるかを示していますが、プリンシパルがチケットを取得するときも、基本的に同じです。両者の唯一の違いは、kinit が有効期間を提供しないことと、チケットを提供するサービスプリンシパルが (krbtgt/realm プリンシパルの代わりに) 最大有効期間を提供することです。

図 7-1 TGT の有効期間の決定方法

更新可能チケットの有効期間も 4 つの値の最小値から決定されます。しかし、次の場合、更新可能有効期間の値が使用されます。

• kinit でチケットを取得または更新する場合、kinit の -r オプションで指定した更新可能有効期間の値

• kdc.conf ファイルで指定した最大更新可能有効期間の値 (max_renewable_life)

• チケットを提供するサービスプリンシパルに対して Kerberos データベースで指定した最大更新可能有効期間の値 (kinit の場合、サービスプリンシパルは krbtgt/realm)

• チケットを要求するユーザープリンシパルに対して Kerberos データベースで指定した最大更新可能有効期間の値

プリンシパル名

各チケットはプリンシパル名で識別されます。プリンシパル名はユーザーまたはサービスを識別できます。次に、いくつかのプリンシパル名の例を示します。

認証システムの動作

ユーザーは自分の識別情報を立証するチケットおよび一致するセッション鍵を提供できる場合に、アプリケーションを使用してリモートシステムにログインできます。セッション鍵には、ユーザーおよびアクセスされるサービスに固有な情報が入っています。ユーザーがログインするとき、KDC はすべてのユーザー用にチケットとセッション鍵を作成します。チケットおよび一致するセッション鍵は資格となります。複数のネットワークサービスを使用するとき、ユーザーは必要なさまざまな資格を集めることができます。ユーザーは特定のサーバー上で動作しているサービスごとに資格を持つ必要があります。たとえば、boston というサーバー上の ftp サービスにアクセスするにはある資格が必要ですが、別のサーバー上の ftp サービスにアクセスするには別の資格が必要です。

資格を作成および格納するプロセスは透過的です。KDC は資格を作成し、要求元に送信します。要求元は資格を受信すると、資格キャッシュに格納します。

SEAM によるサービスへのアクセス

特定のサーバー上の特定のサービスにアクセスするためには、ユーザーは 2 つの資格を取得する必要があります。1 つは、チケット許可サービス (TGT と呼ぶ) の資格です。この資格の暗号を復号化した後、チケット許可サービスはもう 1 つの資格、つまり、ユーザーがアクセスを要求しているサーバーの資格を作成します。この 2 番目の資格は、サーバー上のサービスへのアクセスを要求するために使用できます。サーバーが 2 番目の資格の暗号の復号化に成功した後、ユーザーにアクセスが許可されます。次に、このプロセスを詳細に説明します。

チケット許可サービスの資格の取得

1. 認証プロセスを開始するには、クライアントは特定のユーザープリンシパルに対する要求を認証サーバーに送信します。この要求は暗号化されずに送信されます。この要求には機密情報は含まれていないため、暗号化の必要はありません。

2. 認証サービスは要求を受信すると、ユーザーのプリンシパル名を KDC データベースで検索します。プリンシパルが一致した場合、認証サービスはそのプリンシパル用の非公開鍵を取得します。次に、認証サービスはクライアントとチケット許可サービスが使用するセッション鍵 (セッション鍵 1 と呼ぶ) とチケット許可サービス用のチケット (チケット 1 と呼ぶ) を生成します。このチケットがチケット許可チケット (TGT) です。セッション鍵とチケットは両方ともユーザーの非公開鍵で暗号化され、クライアントに戻されます。

3. クライアントはユーザープリンシパルの非公開鍵でセッション鍵 1 とチケット 1 の暗号を復号化します。非公開鍵を知っているのはユーザーと KDC データベースだけであるため、パケット内の情報は安全です。クライアントはこの情報を資格キャッシュに格納します。

通常、この処理中、ユーザーはパスワードを入力する必要があります。入力したパスワードが KDC データベースに格納されている非公開鍵を構築するために使用されたパスワードと同じ場合、クライアントは認証サービスからの送信されてきた情報の暗号を復号化できます。この時点で、クライアントはチケット許可サービスと一緒に使用する資格を取得し、サーバーの資格を要求することができます。

図 7-2 チケット許可サービスの資格の取得

サーバーの資格の取得

1. 特定のサーバーへアクセスを要求するには、クライアントはチケット許可サービスの資格を認証サービスから取得する必要があります (「チケット許可サービスの資格の取得」を参照)。次に、クライアントはチケット許可サービスに、サービスプリンシパル名、チケット 1、セッション鍵 1 で暗号化されたオーセンティケータが入っている要求を送信します。チケット 1 はあらかじめ、認証サービスによってチケット許可サービスのサービス鍵で暗号化されています。

2. チケット許可サービスはチケット許可サービスのサービス鍵を知っているため、チケット 1 の暗号は復号化できます。チケット 1 に入っている情報にはセッション鍵 1 が入っているため、チケット許可サービスはオーセンティケータの暗号を復号化できます。この時点で、ユーザープリンシパルはチケット許可サービスで認証されます。

3. 認証が成功した後、チケット許可サービスは、ユーザープリンシパルとサーバー用のセッション鍵 (セッション鍵 2) とサーバー用のチケット (チケット 2) を生成します。次に、セッション鍵 2 とチケット 2 はセッション鍵 1 で暗号化されます。セッション鍵 1 を知っているのはクライアントとチケット許可サービスだけであるため、この情報のセキュリティは保護された状態で、ネットワーク上で使用できます。

4. この情報パケットを受信すると、クライアントは資格キャッシュに格納していた情報の暗号をセッション鍵 1 で復号化します。この時点で、クライアントはサーバーと一緒に使用する資格を取得しました。これで、クライアントはそのサーバー上にある特定のサービスへのアクセスを要求することができます。

図 7-3 サーバーの資格の取得

特定のサービスへのアクセスの取得

1. 特定のサービスへのアクセスを要求するには、クライアントはまず認証サーバーからチケット許可サービスの資格を取得し、次にチケット許可サービスからサーバーの資格を取得する必要があります (「チケット許可サービスの資格の取得」と 「サーバーの資格の取得」を参照)。クライアントは、チケット 2 と別のオーセンティケータが入っている要求をサーバーに送信できます。オーセンティケータはセッション鍵 2 で暗号化されています。

2. チケット 2 はあらかじめ、チケット許可サービスによってサービスのサービス鍵で暗号化されています。サービスプリンシパルはサービス鍵を知っているため、サービスはチケット 2 の暗号を復号化して、セッション鍵 2 を取得できます。つまり、セッション鍵 2 でオーセンティケータの暗号を復号化できます。オーセンティケータが暗号を復号化できた場合、クライアントはサービスへのアクセスが許可されます。

図 7-4 特定のサービスへのアクセスの取得

gsscred テーブルの使い方

gsscred テーブルは、NFS サーバーが SEAM ユーザーを識別するときに使用されます。NFS サービスは UNIX の ID でユーザーを識別します。しかし、UNIX の ID はユーザープリンシパルや資格の一部ではありません。gsscred テーブルは (パスワードファイルにある) UNIX の ユーザー ID からプリンシパル名へのマッピングを提供します。gsscred テーブルを作成および管理するのは、KDC データベースが生成された後です。

クライアントの要求を受信すると、NFS サービスはプリンシパル名を UNIX の ID にマッピングしようとします。マッピングが失敗した場合、gsscred テーブルが調べられます。kerberos_v5 機構では、root/hostname プリンシパルは自動的に UID 0 にマッピングされ、gsscred テーブルは調べられません。つまり、gsscred テーブルでは、root を再マッピングする特別な方法はありません。

gsscred テーブル用に選択する機構

gsscred テーブル用に正しい機構を選択するには、いくつかの要因が関わってきます。

• 検索時間を短くしたいか

• データアクセスのセキュリティを高める必要があるか

• 迅速にファイルを構築する必要があるか

次に、選択できるすべてのバックエンド機構のリストを示し、その利点を説明します。

files

gsscred テーブルは 1 つのファイルシステム上に格納されます。共有されないローカルのファイルシステムは、テーブルの作成後にネットワーク上で転送が行われないため、最も安全なバックエンドを提供します。このバージョンのファイルは最も速く構築されます。

xfn_files

gsscred テーブルは /var/fn ファイルシステムに格納されます。このファイルシステムを共有することも共有しないこともできます。すべての xfn ファイルは構築に時間がかかります。

xfn_nis

gsscred テーブルは NIS ネームスペースに格納されます。このファイルシステムにおける検索ではセキュリティは保証されません。すべての xfn ファイルは構築に時間がかかります。

xfn_nisplus

gsscred テーブルは NIS+ ネームスペースに格納されます。このファイルシステムにおける検索ではセキュリティは保証されません。すべての xfn ファイルは構築に時間がかかります。

xfn

gsscred テーブルは xfn のデフォルトのシステムに格納されます。すべての xfn ファイルは構築に時間がかかります。

files バックエンド機構の場合、初期検索は時間がかかることがあります。他の機構の場合は、ネームサービスを使用するため、初期検索の時間が短縮されることがあります。すべての機構において、データをキャッシュに入れた後は、検索時間はほぼ同じになります。