チケットの種類

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

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

転送可能 / 転送済み

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

初期

初期チケットは、チケット認可チケットを使わずに直接発行されるチケットです。パスワードを変更するアプリケーションなどの一部のサービスでは、クライアントが非公開鍵を知っていることを確認するために、「初期」と指定されたチケットを要求することができます。初期チケットは、チケット認可チケットを使用せずに、クライアントが最近認証されたことを証明します。チケット認可チケットの場合は、認証されてから時間が経っている可能性があります。

無効

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

遅延可能 / 遅延

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

プロキシ可能 / プロキシ

場合によっては、サービスがそれ自身のために操作できることが主体にとって必要な場合があります。たとえば、主体がサービスを要求して、サーバーとクライアント以外のホストで印刷ジョブを実行するとします。サービスにはクライアントの ID を使用する権限が必要になりますが、その権限はこの操作だけに制限する必要があります。その場合、サービスは、クライアントの「プロキシ」として動作するといいます。チケットを作成するときには、プロキシの主体名を指定する必要があります。

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

更新可能

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

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

チケットの有効期限

主体がチケットを取得すると、チケット認可チケットであっても、チケットの有効期限は次の中で最も小さい値に設定されます。

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

• kdc.conf ファイルで指定される最長有効期限値 (max_life)

• チケットを提供するサービス主体に対し Kerberos データベースに指定されている最長有効期限値。 kinit の場合、サービス主体は krbtgt/realm

• チケットを要求するユーザー主体に対し Kerberos データベースに指定されている最長有効期限値

図 13–1 は、TGT の有効期限の決定方法と 4 つの有効期限値の指定元を示しています。この図は TGT の有効期限がどのようにして決まるかを示しますが、基本的には、どの主体がチケットを取得する場合でも同じです。違いは、kinit で有効期限値を指定しないことと、krbtgt/realm 主体の代わりに、チケットを提供するサービス主体が最長有効期限値を提供することです。

図 13–1 TGT の有効期限の決定方法

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

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

• kdc.conf ファイルに指定された更新可能最長有効期限値 (max_renewable_life)

• チケットを提供するサービス主体に対し Kerberos データベースに指定されている更新可能最長有効期限値。 kinit の場合、サービス主体は krbtgt/realm

• チケットを要求するユーザー主体に対し Kerberos データベースに指定されている更新可能最長有効期限値

主体名

チケットは主体名で識別され、主体名はユーザーやサービスを識別します。 次の表に主体名の例を示します。