第 27 章 Kerberos サービス (参照)

この章では、Kerberos 製品に組み込まれている多数のファイル、コマンド、およびデーモンを示します。また、Kerberos 認証の機能についても詳細に説明します。

この章の内容は次のとおりです。

• 「Kerberos ファイル」

• 「Kerberos コマンド」

• 「Kerberos デーモン」

• 「Kerberos の用語」

• 「Kerberos 認証システムの動作方法」

• 「Kerberos によるサービスへのアクセス」

• 「Kerberos 暗号化タイプの使用」

• 「gsscred テーブルの使用」

• 「Solaris Kerberos と MIT Kerberos の大きな違い」

Kerberos ファイル

表 27–1 Kerberos ファイル

ファイル名	説明
~/.gkadmin	SEAM 管理ツールで新しい主体を作成するときのデフォルト値
~/.k5login	Kerberos アカウントに対してアクセス権を許可する主体のリスト
/etc/krb5/kadm5.acl	Kerberos アクセス制御リストファイル。KDC 管理者の主体名とその Kerberos 管理特権を含みます
/etc/krb5/kadm5.keytab	マスター KDC 上の kadmin サービスのキータブファイル
/etc/krb5/kdc.conf	KDC 構成ファイル
/etc/krb5/kpropd.acl	Kerberos データベース伝播構成ファイル
/etc/krb5/krb5.conf	Kerberos レルム構成ファイル
/etc/krb5/krb5.keytab	ネットワークアプリケーションサーバー用キータブファイル
/etc/krb5/warn.conf	Kerberos チケットの有効期限切れの警告と自動更新の構成ファイル
/etc/pam.conf	PAM 構成ファイル
/tmp/krb5cc_uid	デフォルト資格キャッシュ ( uid はユーザーの 10 進 UID)
/tmp/ovsec_adm.xxxxxx	パスワード変更操作の間だけ有効な一時資格キャッシュ (xxxxxx はランダムな文字列)
/var/krb5/.k5.REALM	KDC stash ファイル。KDC マスター鍵のコピーを含みます
/var/krb5/kadmin.log	kadmind のログファイル
/var/krb5/kdc.log	KDC のログファイル
/var/krb5/principal	Kerberos 主体データベース
/var/krb5/principal.kadm5	Kerberos 管理データベース。ポリシー情報を含みます
/var/krb5/principal.kadm5.lock	Kerberos 管理データベースのロックファイル
/var/krb5/principal.ok	Kerberos 主体データベースの初期化ファイル。Kerberos データベースの初期化が正常終了すると作成されます
/var/krb5/principal.ulog	Kerberos 更新ログ。増分伝播の更新を含みます
/var/krb5/slave_datatrans	KDC のバックアップファイルで、kprop_script スクリプトが伝播時に使用します
/var/krb5/slave_datatrans_slave	slave に完全更新が行われるときに作成される一時ダンプファイル

Kerberos コマンド

この節では、Kerberos 製品に含まれているコマンドの一部を示します。

表 27–2 Kerberos コマンド

コマンド	説明
/usr/bin/ftp	ファイル転送プロトコルプログラム
/usr/bin/kdestroy	Kerberos チケットを破棄します
/usr/bin/kinit	Kerberos チケット認可チケットを取得し、キャッシュに格納します
/usr/bin/klist	現在の Kerberos チケットを表示します
/usr/bin/kpasswd	Kerberos パスワードを変更します
/usr/bin/ktutil	Kerberos キータブファイルを管理します
/usr/bin/rcp	遠隔ファイルコピープログラム
/usr/bin/rdist	遠隔ファイル配布プログラム
/usr/bin/rlogin	遠隔ログインプログラム
/usr/bin/rsh	遠隔シェルプログラム
/usr/bin/telnet	Kerberos telnet プログラム
/usr/lib/krb5/kprop	Kerberos データベース伝播プログラム
/usr/sbin/gkadmin	Kerberos データベース管理 GUI プログラム。主体とポリシーの管理に使用されます
/usr/sbin/gsscred	gsscred テーブルエントリを管理します
/usr/sbin/kadmin	遠隔 Kerberos データベース管理プログラム (Kerberos 認証とともに実行)。主体、ポリシー、およびキータブファイルの管理に使用されます
/usr/sbin/kadmin.local	ローカル Kerberos データベース管理プログラム (Kerberos 認証なしで動作するが、マスター KDC 上で実行する必要がある)。主体、ポリシー、およびキータブファイルの管理に使用されます
/usr/sbin/kclient	Kerberos クライアントのインストールスクリプト。インストールプロファイルとともに、またはなしで使用されます
/usr/sbin/kdb5_ldap_util	Kerberos データベースの LDAP コンテナを作成します
/usr/sbin/kdb5_util	Kerberos データベースと stash ファイルを作成します
/usr/sbin/kgcmgr	Kerberos のマスター KDC とスレーブ KDC を構成します
/usr/sbin/kproplog	更新ログ内の更新エントリの概要を一覧表示します

Kerberos デーモン

次の表は、Kerberos 製品で使用されるデーモンの一覧です。

表 27–3 Kerberos デーモン

デーモン	説明
/usr/sbin/in.ftpd	ファイル転送プロトコルデーモン
/usr/lib/krb5/kadmind	Kerberos データベース管理デーモン
/usr/lib/krb5/kpropd	Kerberos データベース伝播デーモン
/usr/lib/krb5/krb5kdc	Kerberos チケット処理デーモン
/usr/lib/krb5/ktkt_warnd	Kerberos チケットの有効期限切れの警告と自動更新のデーモン
/usr/sbin/in.rlogind	遠隔ログインデーモン
/usr/sbin/in.rshd	遠隔シェルデーモン
/usr/sbin/in.telnetd	telnet デーモン

Kerberos の用語

この節では、Kerberos の用語とその定義について説明します。これらの用語は、Kerberos のマニュアル全体で使用されます。Kerberos の概念を理解するには、これらの用語を理解する必要があります。

Kerberos 固有の用語

KDC を管理するには、この節で説明する用語を理解する必要があります。

「鍵配布センター (Key Distribution Center、KDC)」は、資格の発行を担当する Kerberos の構成要素です。資格は、KDC データベースに格納されている情報に基づいて作成されます。各レルムには 2 つ以上の KDC サーバー (マスターと 1 つ以上のスレーブ) が必要です。すべての KDC が資格を生成できますが、KDC データベースを変更できるのはマスター KDC だけです。

KDC のマスター鍵は stash ファイル に含まれます。サーバーがリブートされると、この鍵を使用して KDC が自動的に認証されて、kadmind と krb5kdc コマンドが起動されます。このファイルにはマスター鍵が入っているため、このファイルやバックアップは安全な場所に保管する必要があります。ファイルは、root の読み取り専用のアクセス権で作成されます。ファイルをセキュリティー保護するには、アクセス権を変更しないでください。ファイルの保護が破られると、この鍵を使用して KDC データベースのアクセスや変更が可能になります。

認証固有の用語

認証処理を理解するには、この節で説明する用語を理解する必要があります。プログラマやシステム管理者はこれらの用語に精通している必要があります。

「クライアント 」は、ユーザーのワークステーションで動作するソフトウェアです。クライアントで動作する Kerberos ソフトウェアは、処理中に多数の要求を作成します。このため、Kerberos ソフトウェアとユーザーの動作を区別することが重要です。

「サーバー」と「サービス」はよく同じ意味で使われます。明確に定義すると、「サーバー」は、Kerberos ソフトウェアが動作する物理システムです。「サービス」とは、サーバー上でサポートされる特定の機能 (ftp や nfs) です。サーバーがサービスの一部として記述されることがよくありますが、これはこれらの用語の定義をあいまいにします。このマニュアルでは、サーバーという用語は、物理システムを指します。サービスという用語は、ソフトウェアを指します。

Kerberos 製品は、2 種類の鍵を使用します。1 つはパスワード由来の鍵です。パスワード由来の鍵は、各ユーザー主体に与えられ、そのユーザーと KDC だけに知られています。Kerberos 製品が使用するもう 1 つの鍵は、パスワードとの関連性がないランダム鍵です。そのため、ユーザー主体による使用には適しません。通常、ランダム鍵は、キータブにエントリがあり、KDC によって作成されるセッション鍵を持つサービス主体で使用されます。サービスは非対話形式での実行を許可するキータブファイル内の鍵にアクセスできるため、サービス主体はランダム鍵を使用できます。セッション鍵は、クライアントとサービス間のトランザクションを保護するために KDC によって生成され、クライアントとサービス間で共有されます。

「チケット」は、ユーザーの識別情報をサーバーやサービスに安全に渡すために使用される情報パケットです。チケットは、単一クライアントと特定サーバー上の特定サービスだけに有効です。チケットには、次のものが含まれます。

• サービスの主体名

• ユーザーの主体名

• ユーザーのホストの IP アドレス

• タイムスタンプ

• チケットの有効期限を定義する値

• セッション鍵のコピー

これらのすべてのデータは、サーバーのサービス鍵に暗号化されます。KDC は、次に説明する資格に組み込まれたチケットを発行します。チケットは、発行されてから有効期限まで再使用できます。

「 資格」は、チケットとそれに対応するセッション鍵を含む情報パケットです。資格は要求する主体の鍵で暗号化されます。一般的に、KDC はクライアントからのチケット要求に応じて資格を生成します。

「オーセンティケータ (authenticator)」は、クライアントのユーザー主体を認証するためにサーバーが使用する情報です。 オーセンティケータは、ユーザーの主体名、タイムスタンプ、およびその他のデータを含みます。チケットとは異なり、オーセンティケータは一度しか使用できません。通常、サービスへのアクセスが要求されたときに使用されます。オーセンティケータは、クライアントとサーバーが共有するセッション鍵を使用して暗号化されます。通常、クライアントが、オーセンティケータを作成し、サーバーまたはサービスに対して認証するためにサーバーまたはサービスのチケットとともに送信します。

チケットの種類

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

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

転送可能/転送済み

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

初期

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

無効

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

遅延可能/遅延

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

プロキシ可能/プロキシ

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

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

更新可能

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

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

チケットの有効期限

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

• kinit を使用してチケットを取得する場合、kinit の -l オプションに指定した有効期限値。デフォルトで、kinit は最長有効期限値を使用します。

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

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

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

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

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

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

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

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

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

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

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 アプリケーション (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	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 主体。

Kerberos 認証システムの動作方法

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

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

Kerberos サービスによる DNS および nsswitch.conf ファイルとの対話処理方法

Kerberos サービスは、ホスト名の解決に DNS を使用するようにコンパイルされています。ホスト名を解決する場合、 nsswitch.conf ファイルへの参照は一切行われません。

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

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

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

1. 認証処理を開始するために、クライアントが特定のユーザー主体の要求を認証サーバーに送信します。この要求の送信では暗号は使用されません。要求にはセキュリティーにかかわる情報が含まれていないため、暗号を使う必要はありません。

2. 認証サービスは要求を受信すると、ユーザーの主体名を KDC データベースから検索します。主体がデータベースのエントリに一致すると、認証サービスはその主体の非公開鍵を取得します。次に認証サービスは、クライアントとチケット認可サービスが使用するセッション鍵 (セッション鍵 1) とチケット認可サービス用のチケット (チケット 1) を生成します。このチケットを「チケット認可チケット (TGT)」ともいいます。セッション鍵とチケットはユーザーの非公開鍵を使って暗号化され、情報がクライアントに返送されます。

3. クライアントは、ユーザー主体の非公開鍵を使用して、この情報からセッション鍵 1 とチケット 1 の暗号を解除します。非公開鍵を知っているのはユーザーと KDC データベースだけである必要があるため、パケットの情報は安全に保たれなければなりません。クライアントはこの情報を資格キャッシュに格納します。

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

図 27–2 チケット認可サービスに対する資格の取得

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

1. 特定のサーバーにアクセスするには、クライアントがその前にサーバーに対する資格を認証サービスから取得している必要があります。「チケット認可サービスに対する資格の取得」を参照してください。次にクライアントは、チケット認可サービスに要求を送信します。この要求には、サービス主体名、チケット 1 およびセッション鍵 1 で暗号化されたオーセンティケータが含まれています。チケット 1 は、チケット認可サービスのサービス鍵を使用して認証サービスによって暗号化されたものです。

2. チケット認可サービスはチケット認可サービスのサービス鍵を知っているため、チケット 1 の暗号を解除できます。チケット 1 の情報にはセッション鍵 1 が含まれているため、チケット認可サービスはオーセンティケータの暗号を解除できます。この時点で、ユーザー主体はチケット認可サービスによって認証されます。

3. 認証が正常に終了すると、チケット認可サービスは、ユーザー主体とサーバーに対するセッション鍵 (セッション鍵 2) とサーバーに対するチケット (チケット 2) を生成します。次にセッション鍵 2 とチケット 2 はセッション鍵 1 を使って暗号化されます。セッション鍵 1 を知っているのはクライアントとチケット認可サービスだけであるため、この情報は安全であり、ネットワークを介して安全に送信されます。

4. クライアントはこの情報パケットを受信すると、前に資格キャッシュに格納したセッション鍵 1 を使用して情報を復号化します。クライアントは、サーバーに対して使用する資格を取得したことになります。次にクライアントは、そのサーバーの特定のサービスにアクセスする要求を行います。

図 27–3 サーバーに対する資格の取得

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

1. クライアントが特定のサービスへのアクセスを要求するには、まず認証サーバーからチケット認可サービスに対する資格を取得し、チケット認可サービスからサーバー資格を取得する必要があります。「チケット認可サービスに対する資格の取得」および 「サーバーに対する資格の取得」を参照してください。次に、クライアントは、チケット 2 と別のオーセンティケータを含む要求をサーバーに送信します。オーセンティケータはセッション鍵 2 を使用して暗号化されます。

2. チケット 2 は、サービスのサービス鍵を使用してチケット認可サービスによって暗号化されています。サービス鍵はサービス主体が知っているため、サービスはチケット 2 を復号化し、セッション鍵 2 を取得できます。次に、セッション鍵 2 を使用してオーセンティケータが復号化されます。オーセンティケータが正しく復号化されると、サービスへのアクセスがクライアントに許可されます。

図 27–4 特定のサービスへのアクセス権の取得

Kerberos 暗号化タイプの使用

暗号化タイプは、暗号処理が実行されるときに使用する暗号アルゴリズムとモードを特定します。aes、des3-cbc-sha1、および rc4–hmac 暗号化タイプによって、より強固な暗号処理のために使用される鍵を作成できます。これらの強固な操作により、Kerberos サービスのセキュリティー全体が向上します。

---

注 –

Solaris 10 8/07 より前のリリースでは、別売の Strong Cryptographic パッケージがインストールされている場合は、Kerberos サービスで aes256-cts-hmac-sha1-96 暗号化タイプを使用できます。

---

クライアントが KDC にチケットを要求する場合、KDC はクライアントとサーバーで互換性のある暗号化タイプの鍵を使用する必要があります。Kerberos プロトコルでは、KDC がチケット応答のクライアント部分に対して特定の暗号化タイプを使用するようクライアントが要求することができます。しかし、サーバーが KDC に対して暗号化タイプを指定することはできません。

---

注 –

Solaris 10 が動作していないマスター KDC がインストールされている場合は、マスター KDC をアップグレードする前に、スレーブ KDC を Solaris 10 にアップグレードする必要があります。Solaris 10 のマスター KDC では、古いスレーブが処理できない新しい暗号化タイプが使用されます。

---

次に、暗号化タイプを変更する前に考慮する必要があるいくつかの問題を説明します。

• KDC では、主体データベースのサーバー主体エントリに関連する最初の鍵/暗号化タイプはサーバーがサポートしていると想定します。

• KDC 上で、主体に対して生成される鍵が、主体が認証されるシステムと互換性があるかを確認してください。デフォルトで、kadmin コマンドは、サポートされるすべての暗号化タイプの鍵を生成します。主体を使用するシステムがこの暗号化タイプのデフォルトのセットをサポートしていない場合、主体の作成時に暗号化タイプを制限する必要があります。暗号化タイプは、kadmin addprinc で -e フラグを使用するか、または kdc.conf ファイルの supported_enctypes パラメータを設定することで、そのサブセットに制限することができます。Kerberos レルムの大部分のシステムがデフォルトの暗号化タイプのサブセットをサポートしている場合に、supported_enctypes パラメータを使用します。supported_enctypes の設定では、 kadmin addprinc が特定のレルムに対して主体を作成するときに使用する暗号化タイプのデフォルトのセットが指定されます。一般的に、これら 2 つの方法のうち 1 つを使用して、Kerberos が使用する暗号化タイプを制御します。

• システムがサポートする暗号化タイプを決定するときは、システムで実行する Kerberos のバージョンと、サーバー主体の作成対象のサーバーアプリケーションがサポートする暗号アルゴリズムとを考慮します。たとえば、nfs/hostname サービス主体を作成するときは、ホスト上の NFS サーバーがサポートするタイプに暗号化タイプを制限します。Solaris 10 リリースでは、サポートされるすべての Kerberos 暗号化タイプが NFS サーバーでもサポートされることに注意してください。

• kdc.conf ファイルの master_key_enctype パラメータを使用して、主体データベースのエントリを暗号化するマスター鍵の暗号化タイプを制御できます。KDC 主体データベースが既に作成済みの場合は、このパラメータを使用しないでください。データベースの作成時に master_key_enctype パラメータを使用して、デフォルトのマスター鍵の暗号化タイプを des-cbc-crc からより強固な暗号化タイプに変更できます。スレーブ KDC を設定するときに、すべてのスレーブ KDC が選択された暗号化タイプをサポートし、それらの kdc.conf に同一の master_key_enctype エントリがあることを確認してください。また、supported_enctypes が kdc.conf で設定されている場合は、master_key_enctype が supported_enctypes の暗号化タイプのうちの 1 つに設定されていることも確認してください。これらの問題のいずれかが適切に処理されない場合、マスター KDC はスレーブ KDC と連携できない可能性があります。

• クライアント上で、krb5.conf のパラメータのいくつかを使用して、KDC からチケットを取得するときにクライアントが要求する暗号化タイプを制御できます。default_tkt_enctypes パラメータには、クライアントが KDC からチケット認可チケット (TGT) を要求するときに使用する暗号化タイプを指定します。TGT は、より効果的な方法でほかのサーバーチケットを取得するためにクライアントにより使用されます。default_tkt_enctypes を設定すると、クライアントが TGT を使用してサーバーチケットを要求する (TGS 要求と呼ばれる) ときに、クライアントと KDC 間の通信を保護するために使用される暗号化タイプを一部制御できます。default_tkt_enctypes に指定された暗号化タイプは、KDC 上に格納された主体データベース内の主体鍵の暗号タイプのうち少なくとも 1 つに一致する必要があることに注意してください。一致しない場合、TGT 要求は失敗します。多くの場合、default_tkt_enctypes を設定しないようにします。このパラメータは、相互運用性の問題の原因になるためです。デフォルトで、クライアントコードは、サポートされるすべての暗号化タイプと KDC が、KDC により主体データベースで検出された鍵に基づく暗号化タイプを選択するように要求します。

• default_tgs_enctypes パラメータは、サーバーチケットの取得に使用される TGS 要求でクライアントが要求する暗号化タイプを制限します。このパラメータは、クライアントとサーバーが共有するセッション鍵を作成するときに KDC が使用する暗号化タイプも制限します。たとえば、NFS をセキュリティー保護するときに 3DES 暗号化だけを使用するには、default_tgs_enctypes = des3-cbc-sha1 と設定します。クライアントとサーバーの主体が、主体データベース内に des-3-cbc-sha1 鍵を持っていることを確認してください。default_tkt_enctype と同様に、多くの場合でこの設定をしないようにします。資格が KDC とサーバーの両方で適切に設定されていないと、相互運用性の問題の原因となるためです。

• サーバー上で、kdc.conf の permitted_enctypes を使用して、サーバーが受け入れる暗号化タイプを制御できます。さらに、keytab エントリを作成するときに使用される暗号化タイプを指定できます。一般的に、これらの方法のいずれかを使用して暗号化タイプを制御したり、代わりに、使用する暗号化タイプを KDC に決定させたりしないようにします。KDC はサーバーアプリケーションと通信しないで、使用する鍵や暗号化タイプを決定するためです。

gsscred テーブルの使用

デフォルトのマッピングでは十分でないとき、NFS サーバーは gsscred テーブルを使用して、Kerberos ユーザーを識別します。NFS サービスは、UNIX ID を使用してユーザーを識別します。UNIX ID は、ユーザー主体または資格には含まれません。gsscred テーブルは、パスワードファイルから得られる GSS 資格を UNIX ID に追加してマッピングするテーブルです。このテーブルは、KDC データベースを生成したあとに作成および開始する必要があります。詳細は、 「GSS 資格の UNIX 資格へのマッピング」を参照してください。

クライアントの要求が到着すると、NFS サービスは主体名を UNIX ID にマッピングしようとします。このマッピングに失敗した場合、gsscred テーブルが確認されます。

Solaris Kerberos と MIT Kerberos の大きな違い

Solaris 10 バージョンの Kerberos サービスは MIT Kerberos version 1.2.1 に基づいています。次に、Solaris 10 リリースに含まれ、MIT 1.2.1 バージョンには含まれない拡張機能を示します。

• Solaris 遠隔アプリケーションの Kerberos サポート

• KDC データベースの増分伝播

• クライアント構成スクリプト

• 地域対応のエラーメッセージ

• BSM 監査レコードのサポート

• GSS-API を使用する Kerberos のスレッドに対して安全な使用法

• 暗号用暗号化フレームワークの使用

このバージョンには MIT 1.2.1 以後のバグ修正もいくつか含まれています。特に、1.2.5 btree のバグ修正および 1.3 TCP サポートが追加されました。