Solaris のシステム管理 (第 2 巻)

第 23 章 SEAM リファレンス

この章では、SEAM が動作するシステムでチケットの取得、表示、および破棄を行う方法と Kerberos パスワードの選択や変更を行う方法を説明します。この章には、多数の SEAM 製品ファイルがリストされています。さらに、この章では、Kerberos 認証システムがどのように動作するかを詳しく説明します。

チケットの管理

この節では、チケットの取得、表示、および破棄を行う方法を説明します。チケットの概要については、「SEAM の動作」を参照してください。

チケットを意識する必要があるか

PAM の構成方法によっては、ログインしたときにチケットが自動的に取得されます。これがデフォルトの動作ですが、使用する SEAM 構成によっては、チケットの自動転送機能が含まれていないことがあります。

Kerberos 化されたほとんどのコマンドは、終了するときにチケットを自動的に破棄します。しかし、念のために、コマンドが終了したときに Kerberos チケットを明示的に破棄したい場合は、kdestroy を使用します。kdestroy の詳細は、「チケットを破棄する方法」を参照してください。

チケットの有効期限については、「チケットの有効期間」を参照してください。

チケットを作成する方法

通常は、ログインするとチケットが自動的に作成されるため、チケットを取得するために特別な作業をする必要はありません。ただし、次の場合には、チケットを作成しなければならないことがあります。

チケットの有効期限が切れている。
デフォルトのプリンシパルの他に別のプリンシパルを使用する必要がある (たとえば、rlogin -l を使って他人としてマシンにログインする)。

チケットを作成するには、kinit コマンドを使用します。

% /usr/bin/kinit

kinit からはパスワードのプロンプトが表示されます。kinit コマンドの詳しい構文については、kinit(1) のマニュアルページを参照してください。

例 - チケットを作成する

この例では、ユーザー jennifer が自分のシステムにチケットを作成します。

% kinit
Password for jennifer@ENG.ACME.COM:  <パスワードの入力>

次の例では、ユーザー david が -l オプションを使用して 3 時間有効なチケットを作成します。

% kinit -l 3h david@ACME.ORG
Password for david@ACME.ORG:  <パスワードの入力>

この例では、ユーザー david が -f オプションを使用して自分用の転送可能チケットを作成します。この転送可能チケットを使用すると、ユーザーは、たとえば、別のシステムにログインし、telnet を使用してさらに別のシステムにログインできます。

% kinit -f david@ACME.ORG
Password for david@ACME.ORG:     <パスワードの入力>

転送可能チケットをどのように使用するかについては、「チケットの種類」を参照してください。

チケットを表示する方法

すべてのチケットが同じ属性をもっているわけではありません。たとえば、あるチケットは「転送可能 (forwardable)」、別のチケットは「遅延 (postdated)」、さらに別のチケットはその両方である可能性があります。現在のチケットが何で、どのような属性をもつかを知るには、klist コマンドで -f オプションを使用します。

% /usr/bin/klist -f

次の記号はチケットに関連付けられる属性です。klist によって表示されます。

F	転送可能 (Forwardable)
f	転送済み (Forwarded)
P	プロクシ可能 (Proxiable)
p	プロクシ (Proxy)
D	遅延可能 (Postdateable)
d	遅延 (Postdated)
R	更新可能 (Renewable)
I	初期 (Initial)
i	無効 (Invalid)

チケットがもつことのできる属性については、「チケットの種類」を参照してください。

例 - チケットを表示する

次の例は、ユーザー jennifer の「初期 (initial)」チケットが「転送可能 (forwardable)」(F) と「遅延 (postdated)」(d) のプロパティを持っていて、まだ検証 (i) されていないことを示します。

% /usr/bin/klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: jenniferm@ENG.ACME.COM

Valid starting                 Expires                 Service principal
09 Mar 99 15:09:51  09 Mar 99 21:09:51  nfs/ACME.SUN.COM@ACME.SUN.COM
        renew until 10 Mar 99 15:12:51, Flags: Fdi

次の例は、ユーザー david が別のホストから自分のホストに「転送された (forwarded)」(f) チケットを 2 つ持っていることを示します。これらのチケットは「再転送可能 (forwardable)」(F) です。

% klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: david@ACME.SUN.COM

Valid starting                 Expires                 Service principal
07 Mar 99 06:09:51  09 Mar 99 23:33:51  host/ACME.COM@ACME.COM
        renew until 10 Mar 99 17:09:51, Flags: fF

Valid starting                 Expires                 Service principal
08 Mar 99 08:09:51  09 Mar 99 12:54:51  nfs/ACME.COM@ACME.COM
        renew until 10 Mar 99 15:22:51, Flags: fF

チケットを破棄する方法

チケットは通常、チケットを作成したコマンドが終了すると自動的に破棄されます。しかし、念のために、コマンドが終了したときに Kerberos チケットを明示的に破棄したい場合があります。チケットは盗まれることがあります。チケットを盗んだ人は、暗号解除する必要はありますが、その有効期限が切れるまでチケットを使用できます。

チケットを破棄するには、kdestroy コマンドを使用します。

% /usr/bin/kdestroy

kdestroy はそのユーザーの「すべての」チケットを破棄します。特定のチケットを選択して破棄することはできません。

システムを離れるときに侵入者が権限を使用する危険がある場合は、kdestroy を使用してチケットを破棄するか、スクリーンセーバーを使って画面をロックする必要があります。

注 -

チケットを確実に破棄する 1 つの方法は、ホームディレクトリの .logout ファイルに kdestroy コマンドを追加することです。

PAM モジュールが適切に構成されていれば、チケットはログアウト時に自動的に破棄されるため、.login ファイルに kdestroy 呼び出しを追加する必要はありません。ただし、PAM モジュールが適切に構成されていない場合や、構成されているかどうかわからない場合は、システムを終了するときにチケットを確実に破棄するために、kdestroy を .login ファイルに追加することもできます。

パスワード管理

SEAM をインストールすると、2 つのパスワードをもつことになります。通常の Solaris パスワードと Kerberos パスワードです。これらのパスワードは同じでも、異なっていてもかまいません。

login など、Kerberos 化されていないコマンドは、PAM を使用して Kerberos と UNIX の両方で認証するように設定できます。2 つのパスワードが異なっている場合は、ログインで適切な認証を得るために両方のパスワードを入力する必要があります。しかし、2 つのパスワードが同じ場合は、UNIX 用に入力した最初のパスワードが Kerberos で使用されます。

ただし、UNIX と Kerberos に同じパスワードを使用すると、セキュリティを損うおそれがあります。つまり、他人が Kerberos パスワードを入手した場合、UNIX パスワードも安全ではありません。ただし、UNIX と Kerberos に同じパスワードを使用したとしも、Kerberos 環境ではパスワードがネットワークを超えて送信されることはないため、Kerberos のないサイトよりは安全です。通常、どの方法を選ぶかは、サイトごとに決められる方針に従います。

Kerberos では、Kerberos パスワードはユーザーの識別を行う唯一の情報です。Kerberos パスワードを他人に知られると、Kerberos セキュリティは無意味になります。その人が本人になり代わって「本人の」電子メールを送信したり、本人のファイルの読み取り、編集、削除などをしたり、本人として他のホストにログインしても、違いはだれにもわかりません。したがって、適切なパスワードを選択し、その秘密を保持することは極めて重要です。パスワードは、システム管理者を含め誰にも教えてはいけません。さらに、パスワードは頻繁に変更してください。他人に知られた可能性のある場合は特に変更が必要です。

パスワード選択のヒント

パスワードには、制御キーや Return キーなどを除き、入力できるキーであればどの文字でもほとんど使用できます。良いパスワードとは、覚え易く、しかも他人が簡単に推定できないものです。悪い例は次のようなものです。

辞書に出てくる言葉
よく見られるありふれた名前
有名な人やキャラクタの名前
形式に関係なく、自分の名前やユーザー名 (逆方向、2 度繰り返すなどを含む)
配偶者、子、ペットの名前
自分の誕生日や親戚の誕生日
社会保険番号、運転免許書番号、パスポート番号、またはこれに類した身分証明書番号
このマニュアルや他のマニュアルに出てくるサンプルパスワード

良いパスワードとは少なくとも 8 文字からなり、大文字、小文字、番号、句読記号などが混在しているものです。次に例を挙げます。

「I2LMHinSF」などの短縮形。(「I too left my heart in San Francisco」と覚える)
「WumpaBun」、「WangDangdoodle!」など、発音しやすい意味のない語句
「6o'cluck」、「RrriotGrrrlsRrrule!」など、わざとスペルを間違えた語句

注意 -

これらの例は使用しないでください。マニュアルの例に使用されているパスワードは侵入者が最初に試みるパスワードです。

パスワードの変更

Kerberos パスワードは 2 つの方法で変更できます。

通常の UNIX passwd コマンド。SEAM がインストールされていると、Solaris passwd コマンドでも新しい Kerberos パスワードを求めるプロンプトが自動的に表示されます。

kpasswd の代わりに passwd を使用する利点は、UNIX と Kerbeors 両方のパスワードを同時に設定できることです。しかし、passwd で両方のパスワードを同時に変更することは一般的に必要ありません。UNIX パスワードだけを変更して Kerberos パスワードは変更しなかったり、その逆はよくあります。

注 -
passwd の動きは、PAM モジュールがどのように構成されているかによって異なります。構成によっては、両方のパスワードを変更しなければならないことがあります。あるサイトでは UNIX パスワードの変更が必須であり、別のサイトでは Kerberos パスワードの変更が必須であるということがあります。
kpasswd パスワードコマンド。kpasswd は passwd とよく似ていますが、違う点の 1 つは、kpasswd では Kerberos パスワードだけを変更するということです。UNIX パスワードを変更する場合は、passwd を使用する必要があります。

もう 1 つの違いは、kpasswd では、有効な UNIX ユーザーではない Kerberos プリンシパルのパスワードを変更できる点です。たとえば、david/admin は Kerberos プリンシパルですが、実際の UNIX ユーザーではありません。したがって、この場合は、passwd の代わりに kpasswd を使用する必要があります。

注意 -

kpasswd を使用するには、SEAS 3.0 リリースに含まれている SEAM 1.0 管理システムを使用する必要があります。さらに、プライバシサポートを読み込んで、このパスワードの変更要求を防止する必要があります。

パスワードを変更しても、変更がシステム全体に伝達されるまでには (とりわけ大きなネットワークでは)、ある程度の時間が必要です。システムの設定方法によりますが、この時間は数分から 1 時間以上になることがあります。パスワードを変更したあとすぐに新しい Kerberos チケットを取得する場合は、新しいパスワードをまず試してください。新しいパスワードが有効でない場合は、前のパスワードを使用して再度試してください。

Kerberos V5 では、システム管理者が有効なパスワードの基準をユーザーごとに設定できます。このような基準は、ユーザーごとに「ポリシー」セット (またはデフォルトポリシー) で定義します。たとえば、jenpol と呼ぶ jennifer のポリシーでは、パスワードは少なくとも 8 文字からなり、少なくとも 2 種類の文字が混在すると定義されているとします。その場合、パスワードとして sloth を入力すると、kpasswd によって拒否されます。

% kpasswd
kpasswd: Changing password for jennifer@ENG.ACME.COM.
Old password:   <jennifer が現在のパスワードを入力する>
kpasswd: jennifer@ENG.ACME.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password: <jennifer が「sloth」と入力する>
New password (again):  <jennifer が再び「sloth」と入力する>
kpasswd: New password is too short.
Please choose a password which is at least 4 characters long.

次に、jennifer はパスワードとして slothrop49 と入力します。slothrop49 は長さが 8 文字以上で、2 種類の文字 (数字と小文字) が混在しているため基準に合っています。

% kpasswd
kpasswd: Changing password for jennifer@ENG.ACME.COM.
Old password:  <jennifer が現在のパスワードを入力する>
kpasswd: jennifer@ENG.ACME.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password:  <jennifer が「slothrop49」と入力する>
New password (again):  <jennifer が再び「slothrop49」と入力する>
Kerberos password changed.

例 - パスワードを変更する

次の例では、david が passwd を使用して UNIX と Kerberos のパスワードを両方とも変更します。

% passwd
	passwd:  Changing password for david
	Enter login (NIS+) password:         <現在の UNIX パスワードを入力する>
	New password:                        <新しい UNIX パスワードを入力する>
	Re-enter password:                   <新しい UNIX パスワードを確認する>
	Old KRB5 password:                   <現在の Kerberos パスワードを入力する>
	New KRB5 password:                   <新しい Kerberos パスワードを入力する>
	Re-enter new KRB5 password:          <新しい Kerberos パスワードを確認する>

上の例では、passwd によって UNIX と Kerberos のパスワードが要求されます。しかし、PAM モジュールで try_first_pass が設定されていると、Kerberos パスワードは自動的に UNIX パスワードと同じ内容に設定されます (これがデフォルトの設定です)。この場合、david が Kerberos パスワードを他のものに設定するには、次の例のように kpasswd を使用する必要があります。

次の例では、david が kpasswd を使用して Kerberos パスワードだけを変更します。

% kpasswd
kpasswd: Changing password for david@ENG.ACME.COM.
Old password:           <現在の Kerberos パスワードを入力する>
New password:           <新しい Kerberos パスワードを入力する>
New password (again):   <新しい Kerberos パスワードを確認する>
Kerberos password changed.

次の例では、david が Kerberos のプリンシパル david/admin (有効な UNIX ユーザーではない) を変更します。この場合、kpasswd を使用します。

% kpasswd david/admin
kpasswd:  Changing password for david/admin.
Old password:		   	     <現在の Kerberos パスワードを入力する>
New password:			       <新しい Kerberos パスワードを入力する>
New password (again):	   <新しい Kerberos パスワードを確認する>
Kerberos password changed.

SEAM ファイル

この節では、SEAM 製品に含まれているファイルについて説明します。

表 23-1 SEAM ファイル


ファイル名	説明
`/etc/gss/gsscred.conf`	`gsscred` テーブルのデフォルトファイル形式
`/etc/gss/mech`	RPCSEC_GSS のメカニズム
`/etc/gss/qop`	RPCSEC_GSS の Quality of Protection (保護品質) パラメータ
`/etc/nfssec.conf`	NFS 認証セキュリティモードを定義する
`/etc/krb5/krb5.conf`	Kerberos レルム構成ファイル
`/etc/krb5/krb5.keytab`	ネットワークアプリケーションサーバーの keytab
`/etc/krb5/warn.conf`	Kerberos 警告構成ファイル
`/etc/pam.conf`	PAM 構成ファイル
`/tmp/krb5cc_uid`	デフォルト資格キャッシュ (`uid` はユーザーの 10 進数 UID)
`/tmp/ovsec_adm.xxxxxx`	パスワード変更操作の間だけ有効な一時資格キャッシュ (`xxxxxx` はランダムな文字列)

PAM 構成ファイル

SEAM とともに提供されるデフォルトの PAM 構成ファイルでは、Kerberos 機能を使用するためのエントリがコメント化されています。この新しいファイルには、認証サービス、アカウント管理、セッション管理、パスワード管理の各モジュールを表すエントリが含まれています。

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

最初の 3 つのエントリでは try_first_pass オプションが使用されています。この場合、ユーザーの最初のパスワードを使用して認証が行われます。最初のパスワードを使用するとは、複数のメカニズムが表示されていても、ユーザーは別のパスワードを要求されないという意味です。指定されていない、認証を必要とするすべてのエントリのデフォルトとして other エントリが 1 つ含まれています。

# 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

アカウント管理では、Kerberos ライブラリを使用する新しいエントリが dtlogin に次のように含まれています。other エントリはデフォルトルールを提供するために 1 つ含まれています。現状では、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 製品に含まれているコマンドの一部を示します。

表 23-2 SEAM コマンド


ファイル名	説明
`/usr/bin/kdestroy`	Kerberos チケットを破棄する
`/usr/bin/kinit`	Kerberos チケットを許可するチケットを取得およびキャッシュする
`/usr/bin/klist`	現在の Kerberos チケットをリストする
`/usr/bin/kpasswd`	Kerberos パスワードを変更する
`/usr/bin/ktutil`	keytab 保守ユーティリティ
`/usr/sbin/gsscred`	NFS サービスのための GSS-API トークンを生成および検証する

`share` コマンドの変更

新しい SEAM コマンドの他に、Solaris 8 リリースには、share コマンドとともに使用する新しいセキュリティモードが含まれています。このモードは /etc/nfssec.conf ファイルに定義されます。share コマンドでは、次のセキュリティモードを使用できます。

krb5: Kerberos 認証を選択する。
krb5i: 完全性機能付き Kerberos 認証を選択する。
krb5p: 完全性機能とプライバシ機能付き Kerberos 認証を選択する。

share コマンドに複数のモードを指定すると、クライアントがセキュリティモードを指定していない場合は、指定した最初のモードがデフォルトで選択されます。クライアントがセキュリティモードを指定している場合は、指定したモードが使用されます。

Kerberos モードを使用したマウント要求が失敗すると、マウントはセキュリティモード none で完了します。この状態は、NFS クライアントの root プリンシパルが認証されない場合によく発生します。マウント要求が完了したとしても、ファイルが Kerberos で認証されない限り、ユーザーがこのファイルにアクセスすることはできません。ファイルシステムが Kerberos セキュリティモードを使用してマウントされていなくても、クライアントとサーバー間のトランザクションには Kerberos 認証が必要です。

SEAM デーモン

SEAM 製品で使用するデーモンを表 23-3 で示します。

表 23-3 SEAM デーモン


ファイル名	説明
`/usr/lib/krb5/ktkt_warnd`	Kerberos 警告デーモン
`/usr/lib/gss/gssd`	GSSAPI デーモン

チケットリファレンス

この節では、チケットについて補足して説明します。

チケットの種類

チケットには、チケットがどのように使用されるかを決めるプロパティがあります。これらのプロパティは、チケットの作成時にチケットに割り当てられます。ただし、チケットのプロパティはあとから変更できます。たとえば、チケットは「転送可能 (forwardable)」から「転送済み (forwarded)」に変更できます。チケットのプロパティを表示するには klist コマンドを使用します (「チケットを表示する方法」を参照)。

チケットは、次の 1 つまたはそれ以上のプロパティで表されます。

転送可能 / 転送済み

「転送可能 (forwardable)」チケットはホストからホストに転送されます。これによって、クライアントは再び認証を受ける必要がありません。たとえば、ユーザー david が jennifer のマシンで転送可能チケットを取得した場合、david は自身のマシンにログインするときに新しいチケットを取得する必要はありません (再び認証を受ける必要もありません)。転送可能チケットと「プロクシ可能」チケットの違いを比較してください。

初期

「初期 (initial)」チケットは、チケット許可チケットを使わずに直接発行されるチケットです。パスワードを変更するアプリケーションなど、サービスの中には、「初期」チケットを要求するものがあります。これは、そのクライアントが自らの秘密鍵を知っているクライアントであることを確認するためです。つまり、「初期」チケットは、クライアントが認証を受けたばかりであることを示します。これに対し、チケット許可チケットに依存する場合は、そのチケットがしばらくの間使用されていたことを表しています。

無効

「無効 (invalid)」チケットとは、まだ使用可能になっていない遅延チケットです (次の項を参照)。無効チケットは、有効になるまでアプリケーションサーバーから拒否されます。これを有効にするには、開始時期が過ぎたあと、TGS 要求で VALIDATE フラグをオンにしてクライアントがこのチケットを KDC に提示する必要があります。

遅延可能 (postdatable) / 遅延

「遅延 (postdated)」チケットとは、作成されても指定された時期まで有効にならないチケットです。たとえばこのようなチケットは、夜遅く実行されるバッチジョブに使用するのに便利です。チケットが盗まれてもバッチジョブが実行されるまで使用できないためです。「遅延」チケットは「無効」チケットとして発行されます。開始時期がきて、クライアントが KDC から検証を受けるまで「無効」のままです (上の「無効」を参照)。「遅延」チケットは通常、チケット許可チケットの有効期限まで有効です。ただし、チケットが「更新可能」な場合、チケットの有効期限は通常、チケット許可チケットの全有効期限と同じに設定されます (「更新可能」を参照)。

プロクシ可能 / プロクシ

場合によっては、プリンシパルがサービスにサービス自身のために操作を行わせたい場合があります。たとえば、プリンシパルがサービスに対し第 3 のホストで印刷ジョブを実行するように要求する場合です。サービスは、その操作の間に限り、クライアントの識別情報を代わりに使用します。その場合、サービスは、クライアントの「プロクシ (proxy)」として動作するといいます。チケットを作成するときには、プロクシのプリンシパル名を指定する必要があります。

「プロクシ可能 (proxiable)」チケットは「転送可能」チケットに似ていますが、「プロクシ可能」チケットが 1 つのサービスに対してのみ有効であるのに対し、「転送可能」チケットはサービスに対しクライアントの識別情報の完全な使用を許可します。したがって、「転送可能」チケットは一種のスーパープロクシと考えられます。

更新可能

チケットに非常に長い有効期限を与えるとセキュリティを損うおそれがあるため、チケットを「更新可能 (renewable)」にすることができます。「更新可能」チケットには 2 つの有効期限があります。1 つはチケットの現在のインスタンスの有効期限、もう 1 つは任意のチケットの最長有効期限です。クライアントがチケットの使用を継続したいときは、最初の有効期限が切れる前にチケットの有効期限を更新します。たとえば、すべてのチケットの最長有効期限が 10 時間のときに、あるチケットが 1 時間だけ有効だとします。このチケットを保持するクライアントが 1 時間を超えて使用したい場合は、その時間内にチケットの有効期限を更新する必要があります。チケットが最長有効期限 (10 時間) に達すると、チケットの有効期限が自動的に切れ、それ以上更新できなくなります。

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

チケットの有効期間

プリンシパルがチケットを取得すると、チケット許可チケットであっても、チケットの有効期限は次の値のうち最も小さいものに設定されます。

kinit 使用してチケットを取得する場合、kinit の -l オプションに指定した有効期限値
kdc.conf ファイルに指定された最長有効期限値 (max_life)
チケットを提供するサービスプリンシパルに対し Kerberos データベースに指定されている最長有効期限値 (kinit の場合、サービスプリンシパルは krbtgt/realm)
チケットを要求するユーザープリンシパルに対し Kerberos データベースに指定されている最長有効期限値

図 23-1 で、TGT の有効期限がどのようにして決まるか、4 つの有効期限の値がどこで指定されるかを示します。この図は TGT の有効期限がどのようにして決まるかを示していますが、基本的には、どのプリンシパルがチケットを取得する場合でも同じことです。違いは、kinit で有効期限を与えないことと、krbtgt/realm プリンシパルの代わりに、チケットを提供するサービスプリンシパルが最長有効期限を提供することです。

図 23-1 TGT の有効期限の決め方

「更新可能」チケットの有効期限も次の 4 つの値の最小値で決まります。ただし、この場合は更新可能有効期限の値が使用されます。

kinit を使用してチケットを取得または継続する場合、kinit の -r オプションに指定した更新可能有効期限値
kdc.conf ファイルに指定された最長更新可能有効期限値 (max_renewable_life)
チケットを提供するサービスプリンシパルに対し Kerberos データベースに指定されている最長有効期限更新可能値 (kinit の場合、サービスプリンシパルは krbtgt/realm)
チケットを要求するユーザープリンシパルに対し Kerberos データベースに指定されている最長有効期限更新可能値

プリンシパル名

チケットはプリンシパル名で識別され、プリンシパル名はユーザーやサービスを識別します。表 23-4 にプリンシパル名の例を示します。

表 23-4 プリンシパル名の例


プリンシパル名	説明
`root/boston.acme.com@ACME.COM`	NFS クライアントの `root` アカウントに関連付けられたプリンシパル。`root` プリンシパルと呼ばれ、認証された NFS マウントを行う場合に必要
`host/boston.acme.com@ACME.COM`	Kerberos 化されたアプリケーション (`klist` など) やサービス (NFS サービスなど) で使用するプリンシパル
`username@ACME.COM`	ユーザー用のプリンシパル
`username/admin@ACME.COM`	KDC データベースを管理するために使用できる `admin` プリンシパル
`nfs/boston.acme.com@ACME.COM`	`nfs` サービスによって使用されるプリンシパル。これは `host` プリンシパルの代わりに使用できる

認証システムの動作

アプリケーションを使用してリモートシステムにログインするには、識別情報を証明するチケットとそれに対応するセッション鍵を指定する必要があります。セッション鍵には、ユーザーやアクセスするサービスに特有の情報が含まれています。ユーザーすべてのチケットとセッション鍵は、ユーザーが最初にログインするときに KDC によって作成されます。チケットとそれに対応するセッション鍵が 1 つの資格となります。複数のネットワークサービスを使用する場合には、ユーザーは多数の資格を収集できます。ユーザーは特定のサーバーで動作するサービスごとに 1 つの資格を必要とします。たとえば、boston というサーバーで動作する ftp サービスにアクセスするには 1 つの資格が必要であり、別のサーバーで動作する ftp サービスにアクセスするにはそれ独自の別の資格が必要です。

資格の作成や格納は透過的に行われます。資格は KDC によって作成され、要求者に送信されます。資格は、受信されると資格キャッシュに格納されます。

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

特定のサーバーの特定のサービスにアクセスする場合、ユーザーは 2 つの資格を取得する必要があります。最初は TGT として知られるチケット許可サービスに対する資格です。チケット許可サービスは、この資格の暗号を解除すると、ユーザーからアクセスを要求されているサーバーの資格をさらに作成します。ユーザーは、この 2 つめの資格を使用してサーバー上のサービスへのアクセスを要求します。サーバーがこの資格の暗号を解除すると、ユーザーはアクセスを許可されます。この処理を次の項とそれに続く図で説明します。

チケット許可サービスに対する資格の取得

認証処理を開始するために、クライアントが特定のユーザープリンシパルの要求を認証サーバーに送信します。この要求の送信では暗号は使用されません。要求には機密情報が含まれていないため、暗号を使う必要はありません。
認証サービスは要求を受信すると、ユーザーのプリンシパル名を KDC データベースから探します。合致するプリンシパルが見つかると、認証サービスはそのプリンシパルの非公開鍵を取得します。次に認証サービスは、クライアントとチケット許可サービスが使用するセッション鍵 (セッション鍵 1) とチケット許可サービス用のチケット (チケット 1) を生成します。このチケットはチケット許可チケット (TGT) ともいいます。セッション鍵とチケットはユーザーの非公開鍵を使って暗号化され、クライアントに返送されます。
クライアントは、ユーザープリンシパルの非公開鍵を使用して、この情報からセッション鍵 1 とチケット１の暗号を解除します。非公開鍵を知っているのはユーザーと KDC データベースだけである必要があるため、パケットの情報は安全に保たれなければなりません。クライアントはこの情報を資格キャッシュに格納します。

通常、この処理では、ユーザーはパスワードの入力を要求されます。非公開鍵の作成で KDC データベースから取り出されたパスワードが入力したパスワードと同じであると、認証サービスから送信された情報は正しく暗号解除されます。これでクライアントは、チケット許可サービスに対して使用する資格を取得したことになります。次にクライアントはサーバーに対する資格を要求します。

図 23-2 チケット許可サービスに対する資格の取得

サーバーに対する資格の取得

特定のサーバーにアクセスするには、クライアントがその前にサーバーに対する資格を認証サービスから取得していなければなりません (「チケット許可サービスに対する資格の取得」を参照)。次にクライアントは、チケット許可サービスに要求を送信します。この要求には、サービスプリンシパル名、チケット 1 と、セッション鍵 1 で暗号化された認証者が含まれています。チケット 1 は、チケット許可サービスのサービス鍵を使用して認証サービスによって暗号化されたものです。
チケット許可サービスはチケット許可サービスのサービス鍵を知っているため、チケット 1 の暗号を解除できます。チケット 1 の情報にはセッション鍵 1 が含まれているため、チケット許可サービスは認証者の暗号を解除できます。この時点で、ユーザープリンシパルはチケット許可サービスによって認証されます。
認証が正常に終ると、チケット許可サービスは、ユーザープリンシパルとサーバーに対するセッション鍵 (セッション鍵 2) とサーバーに対するチケット (チケット 2) を生成します。セッション鍵 2 とチケット 2 はセッション鍵 1 を使って暗号化されます。セッション鍵 1 を知っているのはクライアントとチケット許可サービスだけですので、この情報は安全であり、ネットワークを介して安全に送信されます。
クライアントはこの情報パケットを受信すると、前に資格キャッシュに格納したセッション鍵 1 を使用して情報の暗号を解除します。クライアントは、サーバーに対して使用する資格を取得したことになります。次にクライアントは、そのサーバーの特定のサービスにアクセスする要求を行います。

図 23-3 サーバーに対する資格の取得

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

特定のサービスにアクセスするには、クライアントがその前に認証サーバーからチケット許可サービスの資格を、チケット許可サービスからサーバーの資格をそれぞれ取得していなければなりません (「チケット許可サービスに対する資格の取得」と「サーバーに対する資格の取得」を参照)。クライアントは、チケット 2 と別の認証者を含む要求をサーバーに送信します。認証者はセッション鍵 2 を使用して暗号化されます。
チケット 2 は、サービスのサービス鍵を使用してチケット許可サービスによって暗号化されています。サービス鍵はサービスプリンシパルが知っているため、サービスはチケット 2 の暗号を解除し、セッション鍵 2 を取得できます。次に、セッション鍵 2 を使用して認証者の暗号が解除されます。認証者の暗号が正しく解除されると、サーバーへのアクセスがクライアントに許可されます。

図 23-4 特定のサーバーへのアクセス権を取得

`gsscred` テーブルの使用

gsscred テーブルは、NFS サーバーが SEAM ユーザーを識別するときに使用します。NFS サービスは UNIX ID を使用してユーザーを識別しますが、この ID はユーザープリンシパルや資格の一部ではありません。gsscred テーブルは、パスワードファイルから得られる UNIX ID とプリンシパル名を対応付けるテーブルです。このテーブルは、KDC データベースにデータを入力したあとに作成および開始する必要があります。

クライアントの要求が到着すると、NFS サービスはプリンシパル名を UNIX ID に対応づけようとします。そして、この変換に失敗すると、gsscred テーブルを使用します。kerberos_v5 メカニズムでは、root/hostname プリンシパルは自動的に UID 0 に対応付けられるため、gsscred テーブルは使用されません。したがって、gsscred テーブルを使用して root を特別な UID に対応づけることはできません。

`gsscred` テーブル用メカニズムの選択

gsscred テーブルに対しどのメカニズムを選択するかは、次の要素で決まります。

検索時間の短縮に関心があるか
データアクセスのセキュリティ向上に関心があるか
ファイルを短時間で作成する必要があるか

次に、選択可能なバックエンドメカニズムとその利点を説明します。

files: gsscred テーブルはファイルシステムに格納されます。テーブルが作成された後はネットワークを介した伝送は行われないため、共有されないローカルファイルシステムが最も安全なバックエンドです。このタイプのファイルが最も短時間で作成されます。
xfn_files: gsscred テーブルは /var/fn ファイルシステムに格納されます。このファイルシステムは共有されていても、されていなくてもかまいません。xfn ファイルはどれも作成に長い時間がかかります。
xfn_nis: gsscred テーブルは NIS 名前空間に格納されます。このファイルシステムの検索は安全ではありません。xfn ファイルはどれも作成に長い時間がかかります。
xfn_nisplus: gsscred テーブルは NIS+ 名前空間に格納されます。このファイルシステムの検索は安全ではありません。xfn ファイルはどれも作成に長時間かかります。
xfn: gsscred テーブルは xfn のデフォルトシステムに格納されます。xfn ファイルはどれも作成に長時間かかります。

files バックエンドメカニズムでは、最初の検索が遅いことがあります。他のメカニズムでは、最初の検索はネームサービスを使用してこれより速く行われます。どのメカニズムでも、データがキャッシュされたあとの検索時間はほぼ同じです。