チケットには、その使い方を決定する属性があります。属性は、チケットの作成時にチケットに割り当てられます。しかし、チケットの属性はこの後でも変更できます。たとえば、チケットを「転送可能」から「転送」に変更できます。チケットの属性を表示するには、klist コマンドを使用します (「チケットを表示するには」を参照)。
チケットは、次に示す属性によって分類されます。
転送可能チケットはあるホストから別のホストに送信できるため、クライアントが自分自身を再び認証する必要がなくなります。たとえば、ユーザー david が jennifer のマシン上で転送可能チケットを取得した場合、新しいチケットを取得しなくても (したがって、自分自身をもう一度認証しなくても)、自分のマシンにログインできます。転送可能チケットの例については、「例 - チケットを作成する」を参照してください。転送可能チケットと代理可能チケット (次を参照) を比較してください。
初期チケットとは、チケット許可チケットに基づくのではなく、直接発行されるチケットのことです。一部のサービス (パスワードを変更するアプリケーションなど) は、クライアントが自分の秘密鍵を知っていることを示すために、「initial (初期)」というマークが付いたチケットを要求できます。これは、初期チケットがクライアントが自分を認証したのが最近であることを示すためです。一方、チケット許可チケットに基づくチケットは、長時間使用されていた可能性があることを示します。
無効なチケットとは、遅延チケットのことで、まだ有効になっていないチケットのことです (次の「遅延」を参照)。有効性が確認されるまで、アプリケーションサーバーはチケットを拒否します。有効性を確認するためには、起動後に、クライアントが TGS 要求中に VALIDATE フラグを設定することによって、KDC にチケットを示さなければなりません。
遅延チケットとは、作成後から特定の時間が経過するまで有効にならないチケットのことです。このようなチケットは、真夜中に実行したいバッチジョブなどに便利です。これは、チケットが第三者に漏れたとしても、バッチジョブが実行されるまで使用できないためです。発行時、遅延チケットは無効であり、起動されるまで、あるいはクライアントが KDC による有効性の確認を要求するまで無効な状態が続きます (上記の「無効」を参照)。遅延チケットは通常、チケット許可チケットの有効期限が切れるまで有効です。しかし、「更新可能」というマークを付けた場合、そのチケットの有効期間はチケット許可チケットの有効期間と同じに設定されます。次の「更新可能」を参照してください。
場合によってはサービスがプリンシパルの代わりに操作を実行することをプリンシパルが許可する必要もあります。たとえば、第 3 のホスト上で印刷ジョブを実行するようにプリンシパルがサービスに要求するときなどです。サービスはクライアントの識別情報を取得する必要があります。しかし、これは単一の操作だけ必要となります。この場合、サーバーはクライアントの代理として動作しています。代理のプリンシパル名は、チケット作成時に指定しなければなりません。
代理可能チケットは転送可能チケットに似ています。しかし、代理可能チケットは単一のサービスでだけ有効です。一方、転送可能チケットは、クライアントの識別情報を使用するためのアクセス権をサービスに許可します。したがって、転送可能チケットは代理可能チケットのスーパーセットと考えられます。
チケットの有効期間が長いとセキュリティが保たれなくなることがあるため、チケットは更新可能にすることができます。更新可能チケットは 2 つの有効期限を持ちます。1 つは、チケットの現在のインスタンスの有効期限が切れる時間です。もう 1 つは、すべてのチケットの最大有効期間です。クライアントがチケットを使用し続けたい場合、クライアントは最初の有効期限に到達する前にチケットを更新します。たとえば、あるチケットが 1 時間だけ有効であり、すべてのチケットの最大有効期間が 10 時間であると仮定します。チケットを保有するクライアントが 1 時間よりも長くチケットを使用したい場合、クライアントはその時間内にチケットを更新します。チケットがすべてのチケットの最大有効期間 (10 時間) に到達した場合は、自動的に有効期限が切れて、更新できなくなります。
チケットとその属性を表示する方法については、「チケットを表示するには」を参照してください。
プリンシパルがチケット (チケット許可チケットも含む) を取得するとき、チケットの有効期間は次の有効期間の中の最小値に設定されます。
チケットを提供するサービスプリンシパルに対して Kerberos データベースで指定した最大有効期間の値 (kinit の場合、サービスプリンシパルは krbtgt/realm)
チケットを要求するユーザープリンシパルに対して Kerberos データベースで指定した最大有効期間の値
図 7-1 に、TGT の有効期間がどのように決定されるかを示します。また、4 つの有効期間がどのように指定されているのかも示します。図 7-1 は TGT の有効期間がどのように決定されるかを示していますが、プリンシパルがチケットを取得するときも、基本的に同じです。両者の唯一の違いは、kinit が有効期間を提供しないことと、チケットを提供するサービスプリンシパルが (krbtgt/realm プリンシパルの代わりに) 最大有効期間を提供することです。
更新可能チケットの有効期間も 4 つの値の最小値から決定されます。しかし、次の場合、更新可能有効期間の値が使用されます。
kinit でチケットを取得または更新する場合、kinit の -r オプションで指定した更新可能有効期間の値
kdc.conf ファイルで指定した最大更新可能有効期間の値 (max_renewable_life)
チケットを提供するサービスプリンシパルに対して Kerberos データベースで指定した最大更新可能有効期間の値 (kinit の場合、サービスプリンシパルは krbtgt/realm)
チケットを要求するユーザープリンシパルに対して Kerberos データベースで指定した最大更新可能有効期間の値
各チケットはプリンシパル名で識別されます。プリンシパル名はユーザーまたはサービスを識別できます。次に、いくつかのプリンシパル名の例を示します。
表 7-4 プリンシパル名の例
プリンシパル名 |
説明 |
---|---|
root/boston.acme.com@ACME.COM |
NFS クライアント上の root アカウントに関連するプリンシパル名。root プリンシパルと呼ばれ、認証された NFS マウントを成功させるために必要 |
host/boston.acme.com@ACME.COM |
Kerberos 化されたアプリケーションによって使用されるプリンシパル (klist や kprop など) とサービス (ftp や telnet など)。host プリンシパルまたはサービスプリンシパルと呼ばれる |
username@ACME.COM |
ユーザーのプリンシパル |
username/admin@ACME.COM |
KDC データベースを管理するために使用できる admin プリンシパル |
ftp/boston.acme.com@ACME.COM |
ftp サービスによって使用されるプリンシパル。host プリンシパルの代わりに使用できる |
K/M@ACME.COM |
マスター鍵名プリンシパル。マスター KDC ごとに 1 つずつ存在する |
kadmin/history@ACME.COM |
他のプリンシパルのパスワードヒストリを保存するために使用される鍵を含むプリンシパル。マスター KDC ごとに 1 つずつ存在する |
kadmin/kdc1.acme.com@ACME.COM |
kadmind を使用して KDC へのアクセスを許可するマスター KDC サーバーのプリンシパル |
changepw/kdc1.acme.com@ACME.COM |
パスワードの変更時に KDC へのアクセスを許可するマスター KDC サーバーのプリンシパル |
krbtgt/ACME.COM@ACME.COM |
チケット許可チケットの生成時に使用されるプリンシパル |