Kerberos の用語
次の Kerberos の用語は、Kerberos のドキュメント全体にわたって使用されます。Kerberos の概念を理解するには、これらの用語を理解する必要があります。
Kerberos 固有の用語
KDC を管理するには、このセクションで説明する用語を理解する必要があります。
鍵配布センター (KDC) は、資格の発行に責任を負う Kerberos のコンポーネントです。資格は、KDC データベースに格納されている情報に基づいて作成されます。各レルムには 2 つ以上の KDC サーバー (マスターと 1 つ以上のスレーブ) が必要です。すべての KDC が資格を生成できますが、KDC データベースを変更できるのはマスター KDC だけです。
stash ファイルには、KDC のマスター鍵が含まれています。サーバーがリブートされると、この鍵を使用して KDC が自動的に認証されて、kadmind および krb5kdc コマンドがブートされます。このファイルにはマスター鍵が入っているため、このファイルやバックアップは安全な場所に保管する必要があります。ファイルは、root の読み取り専用のアクセス権で作成されます。ファイルをセキュリティー保護するには、アクセス権を変更しないでください。ファイルの保護が破られると、この鍵を使用して KDC データベースのアクセスや変更が可能になります。
認証固有の用語
認証処理を理解するには、このセクションで説明する用語を理解する必要があります。プログラマやシステム管理者はこれらの用語に精通している必要があります。
クライアントとは、ユーザーのワークステーション上で動作するソフトウェアのことです。クライアントで動作する Kerberos ソフトウェアは、処理中に多数の要求を作成します。そのため、このソフトウェアとユーザーの動作を区別することが重要です。
サーバーとサービスという用語は多くの場合、同じ意味で使用されます。明確にするために、サーバーという用語は、Kerberos ソフトウェアが実行されている物理マシンを定義するために使用されます。サービスという用語は、サーバー上でサポートされている特定の機能 (ftp や nfs など) に対応します。サーバーがサービスの一部として記述されることがよくありますが、これはこれらの用語の定義をあいまいにします。そのため、サーバーという用語は、物理マシンを指します。サービスという用語は、ソフトウェアを指します。
Kerberos 製品では、2 種類の鍵が使用されます。鍵の 1 つの種類は、パスワードから派生する鍵です。これは、各ユーザー主体に与えられ、そのユーザーと KDC だけが認識しています。鍵のもう 1 つの種類はランダム鍵です。これは、パスワードに関連付けられていないため、ユーザー主体が使用するのには適していません。ランダム鍵は通常、keytab 内にエントリがあり、セッション鍵が KDC によって生成されたサービス主体に使用されます。サービスは非対話形式での実行を許可するキータブファイル内の鍵にアクセスできるため、サービス主体はランダム鍵を使用できます。セッション鍵は、クライアントとサービス間のトランザクションを保護するために KDC によって生成され、クライアントとサービス間で共有されます。
サービスの主体名
ユーザーの主体名
ユーザーのホストの IP アドレス
タイムスタンプ
チケットの有効期限を定義する値
セッション鍵のコピー
チケットとは、ユーザーの識別情報をサーバーまたはサービスにセキュアに渡すために使用される情報パケットのことです。チケットは、単一クライアントと特定サーバー上の特定サービスだけに有効です。チケットには、次のものが含まれています。
これらのすべてのデータは、サーバーのサービス鍵に暗号化されます。KDC は、このチケットを資格に組み込んで発行します。チケットは、発行されてから有効期限まで再使用できます。
資格とは、チケットとそれに対応するセッション鍵を含む情報のパケットのことです。資格は要求する主体の鍵で暗号化されます。一般的に、KDC はクライアントからのチケット要求に応じて資格を生成します。
オーセンティケータとは、サーバーがクライアントのユーザー主体を認証するために使用する情報のことです。オーセンティケータは、ユーザーの主体名、タイムスタンプ、およびその他のデータを含みます。チケットとは異なり、オーセンティケータは (通常はサービスへのアクセスがリクエストされたときの) 1 回だけ使用されます。オーセンティケータは、クライアントとサーバーが共有するセッション鍵を使用して暗号化されます。通常、クライアントが、オーセンティケータを作成し、サーバーまたはサービスに対して認証するためにサーバーまたはサービスのチケットとともに送信します。
チケットの種類
チケットには、チケットがどのように使用されるかを決めるプロパティーがあります。これらのプロパティーは、チケットの作成時にチケットに割り当てられます。ただし、チケットのプロパティーはあとから変更できます。たとえば、チケットを転送可能の状態から転送済みの状態に変更できます。チケットのプロパティーを表示するには、klist コマンドを使用しますKerberos チケットの表示を参照してください。
チケットは、次の 1 つまたは複数のプロパティーで表されます。
- 転送可能/転送済み
転送可能チケットは、あるホストから別のホストに送信できます。これにより、クライアントは自身を再認証する必要がなくなります。たとえば、ユーザー david がユーザー jennifer のホスト上にいる間に転送可能チケットを取得した場合、david は、新しいチケットを取得しなくても (それにより自分自身を再認証しなくても) 自分のホストにログインできます。転送可能チケットの例については、使用例 38を参照してください。
- 初期
初期チケットは、チケット認可チケットに基づかずに、直接発行されるチケットです。パスワードを変更するアプリケーションなどの一部のサービスは、クライアントが自身の秘密鍵を知っていることを示せるように、チケットに「初期」とマークするよう要求できます。初期チケットは、クライアントが最近、古くなっている可能性があるチケット認可チケットに依存することなく自身を認証したことを示します。
- 無効
無効チケットは、まだ使用可能になっていない遅延チケットです。無効チケットは、有効になるまでアプリケーションサーバーから拒否されます。チケットが検証されるには、その開始時間が過ぎたあとに –VALIDATE フラグを設定して、クライアントがチケット認可サービスリクエストでそのチケットを KDC に提示する必要があります。
- 遅延可能/遅延
遅延チケットは、作成されたあと、指定された一定の時間が経過するまで有効にならないチケットです。たとえばこのようなチケットは、夜遅く実行するバッチジョブに使用するのに便利です。チケットが盗まれてもバッチジョブが実行される予定の時刻まで使用できないためです。遅延チケットは、無効チケットとして発行され、開始時間を過ぎて、クライアントが KDC による検査を要求したときに有効になります。遅延チケットは通常、チケット認可チケットの有効期限まで有効です。ただし、チケットに更新可能が指定されている場合、その最長有効期限は通常、チケット認可チケットの最長有効期限と同じに設定されます。
- プロキシ可能/プロキシ
場合によっては、主体はサービスに、自身の代わりに操作を実行するよう許可する必要がある場合があります。プロキシの主体名は、チケットの作成時に指定する必要があります。Oracle Solaris では、プロキシ可能チケットやプロキシチケットはサポートされません。
プロキシ可能チケットは、1 つのサービスに対してのみ有効である点を除き、転送可能チケットと同じです。転送可能チケットは、サービスにクライアントの識別情報の完全な使用を許可します。したがって、転送可能チケットは一種のスーパープロキシと考えられます。
- 更新可能
有効期限が非常に長いチケットはセキュリティーリスクになるため、チケットを更新可能として指定できます。更新可能チケットには 2 つの有効期限があります。 1 つはチケットの現在のインスタンスの有効期限で、もう 1 つは任意のチケットの最長有効期限 (1 週間) です。クライアントがチケットの使用を継続するときは、最初の有効期限が切れる前にチケットの有効期限を更新します。たとえば、すべてのチケットの最長有効期限が 10 時間のときに、あるチケットが 1 時間しか有効になれないとします。このチケットを保持するクライアントが 1 時間を超えて使用する場合は、その時間内にチケットの有効期限を更新する必要があります。チケットが最長有効期限 (10 時間) に達すると、チケットの有効期限が自動的に切れ、それ以上更新できなくなります。
チケットの属性を表示する方法については、Kerberos チケットの表示を参照してください。
チケットの有効期限
kinit を使用してチケットを取得する場合は、kinit の –l オプションで指定された有効期限の値。デフォルトでは、kinit は最長有効期限の値を使用します。
チケットを提供するサービス主体に対し Kerberos データベースに指定されている最長有効期限値。kinit の場合、サービス主体は krbtgt/realm です。
チケットを要求するユーザー主体に対し Kerberos データベースに指定されている最長有効期限値。
主体がチケット (チケット認可チケット (TGT) を含む) を取得すると、チケットの有効期限は、次の有効期限の値の最小値として設定されます。
次の図は、TGT の有効期限が決定される方法と、4 つの有効期限の値が生成される場所を示しています。どの主体がチケットを取得した場合も、チケットの有効期限は同様に決定されます。2 つの違いとして、kinit が有効期限の値を提供しない点と、チケットを提供するサービス主体が krbtgt/realm 主体の代わりに最長有効期限の値を提供する点があります。
図 13 TGT の有効期限が決定される方法
kinit を使用してチケットを取得または更新する場合、kinit の –r オプションに指定した更新可能有効期限値。
チケットを提供するサービス主体に対し Kerberos データベースに指定されている更新可能最長有効期限値。kinit の場合、サービス主体は krbtgt/realm です。
チケットを要求するユーザー主体に対し Kerberos データベースに指定されている更新可能最長有効期限値。
更新可能チケットの有効期限は、次のように、4 つの更新可能な有効期限の値の最小値から決定されます。
Kerberos 主体名
チケットは主体名で識別され、主体名はユーザーやサービスを識別します。次の例は、標準的な主体名を示しています。
- 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 アプリケーション (klist や kprop など) およびサービス (ftp や telnet など) によって使用される主体。この主体は 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
Oracle 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 主体。