Solaris のシステム管理 (セキュリティサービス)

チケットの種類

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

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

転送可能/転送済み

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

初期

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

無効

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

遅延可能/遅延

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

プロキシ可能/プロキシ

場合によっては、サービスがそれ自身のために操作できることが主体にとって必要な場合があります。チケットを作成するときには、プロキシの主体名を指定する必要があります。Solaris リリースでは、プロキシ可能またはプロキシチケットをサポートしていません。

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

更新可能

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

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

チケットの有効期限

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

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

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

kinit コマンド、ユーザー主体、サイトデフォルト、チケット許可者のいずれかによって与えられる最小値が、チケットの有効期限となります。

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

Kerberos 主体名

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

表 27–4 Kerberos 主体名の例

Principal Name 

説明 

changepw/kdc1.example.com@EXAMPLE.COM

パスワードを変更するときに、KDC にアクセスできるマスター KDC の主体。 

clntconfig/admin@EXAMPLE.COM

kclient インストールユーティリティーで使用される主体。

ftp/boston.example.com@EXAMPLE.COM

ftp サービスによって使用される主体。この主体は host 主体の代わりに使用できます。

host/boston.example.com@EXAMPLE.COM

Kerberos アプリケーション (klistkprop など) およびサービス (ftptelnet など) によって使用される主体。この主体は host またはサービス主体と呼ばれます。主体は NFS マウントの認証に使用されます。この主体はまた、クライアントが受け取った TGT が正しい KDC から発行されたものであることを確認するためにも使用されます。

K/M@EXAMPLE.COM

マスター鍵名の主体。各マスター KDC には、1 つのマスター鍵名の主体が関連付けられます。 

kadmin/history@EXAMPLE.COM

この主体に含まれる鍵を使用して、ほかの主体のパスワード履歴が保管されます。各マスター KDC には、これらの主体のいずれかが割り当てられます。 

kadmin/kdc1.example.com@EXAMPLE.COM

kadmind を使用して KDC にアクセスできるマスター KDC サーバーの主体。

kadmin/changepw.example.com@EXAMPLE.COM

Solaris リリースが動作していないクライアントからのパスワード変更要求の受け入れに使用される主体。 

krbtgt/EXAMPLE.COM@EXAMPLE.COM

この主体を使用して、チケット認可チケットを生成します。 

krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM

この主体は、レルム間チケット認可チケットの例です。 

nfs/boston.example.com@EXAMPLE.COM

NFS サービスによって使用される主体。この主体は host 主体の代わりに使用できます。

root/boston.example.com@EXAMPLE.COM

クライアントの root アカウントに関連付けられた主体。この主体は、root 主体と呼ばれ、NFS がマウントされたファイルシステムへの root アクセスを提供します。

username@EXAMPLE.COM

ユーザー用の主体。 

username/admin@EXAMPLE.COM

KDC データベースを管理するために使用できる admin 主体。