11.5. レルム間 Kerberos 信頼の設定

Kerberos v5 レルムは、接続されているすべてのマスターおよびスレーブ上の Kerberos データベースで定義されている Kerberos プリンシパルのセットです。異なるレルム間のプリンシパルが相互に通信できるようにするには、レルム間 Kerberos 信頼を設定する必要があります。
混在環境の場合と同様に、多くの Linux 環境でシングルサインオンやアプリケーション認証、ユーザー管理用に Kerberos レルムが導入されています。この場合、Kerberos は異なるドメインや (Windows および Linux などの) 混在環境における共通の統合パスとなり得ます。Linux 環境で Identity Management のようなより構成化されたドメイン設定が使用されていない場合は、特にこれが該当します。

11.5.1. 信頼関係

信頼 とは、あるレルム内のユーザーが別のドメイン内のリソースにアクセスする際に この別のレルムに所属しているかのように 信頼されていることを指します。これは、両方のドメインで共通して保持される単一のプリンシパル用に共有鍵を作成することで実現します。
基本的な信頼

図11.2 基本的な信頼

図11.2「基本的な信頼」 では、共有プリンシパルはドメイン B (krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM) に所属します。このプリンシパルがドメイン A にも追加されると、ドメイン A のクライアントはドメイン B 内のリソースにアクセスできるようになります。設定済みのプリンシパルは両方のレルムに存在することになります。この共有プリンシパルには以下の 3 つの特徴があります。
  • 両方のレルムに存在します。
  • 鍵が作成されると、両方のレルムで同じパスワードが使えます。
  • キーのキーバージョン番号は同一です (kvno)。
デフォルトでは、レルム間信頼は一方向です。この信頼は自動で往復しないので、B.EXAMPLE.COM レルムは A.EXAMPLE.COM レルム内のサービスに対して認証するよう信頼されています。反対方向の信頼を確立するには、両方のレルムで krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM サービスの鍵を共有する必要があります。これは、上記の例とは反対のマッピングを持つエントリーになります。
レルムには複数の信頼関係を確立することが可能です。信頼関係は、レルムが他のレルムを信頼することと、他のレルムが当該レルムを信頼することの両方を定義できます。Kerberos の信頼を使うと、信頼は連鎖して流れることが可能になります。たとえば、レルム A がレルム B を信頼し、レルム B がレルム C を信頼していれば、暗示的にレルム A はレルム C を信頼します。信頼がレルムに沿って流れることになります。これが 推移的 信頼です。
推移的信頼

図11.3 推移的信頼

推移的信頼の方向は、trust flow (トラストフロー) と呼ばれます。トラストフローは、まずサービスが所属するレルムを認識し、次にそのサービスにアクセスするためにクライアントが連絡する必要のあるレルムを特定することで定義されます。
Kerberos プリンシパル名は、service/hostname@REALM という形式になります。service は通常、LDAP や IMAP、HTTP、host といったプロトコルになります。hostname はホストシステムの完全修飾ドメイン名になります。REALM は所属する Kerberos レルムです。Kerberos クライアントは通常、Kerberos レルムマッピングのホスト名または DNS ドメイン名を使用します。このマッピングは、明示的または暗黙的に指定できます。明示的なマッピングは、/etc/krb5.conf ファイルの [domain_realm] セクションを使用します。暗黙的なマッピングでは、ドメイン名は大文字に変換され、変換された名前が検索する Kerberos レルムであるとみなされます。
信頼関係をスキャンする際に、Kerberos は各レルムがルートドメインとサブドメインからなる階層的な DNS ドメインのように構成されていると仮定します。つまり、信頼は共有ルートまで移動します。ホップ と呼ばれる各ステップには共有キーがあります。図11.4「同一ドメイン内の信頼」 では、SALES.EXAMPLE.COM は EXAMPLE.COM とキーを共有し、EXAMPLE.COM は EVERYWHERE.EXAMPLE.COM とキーを共有しています。
同一ドメイン内の信頼

図11.4 同一ドメイン内の信頼

クライアントはレルム名を DNS 名として扱い、root 名に達するまで自身のレルム名の要素を取り除くことで信頼パスを判断します。そして、サービスのレルムに到達するまで名前を先頭につけ始めます。
同一ドメイン内の子/親の信頼

図11.5 同一ドメイン内の子/親の信頼

信頼の推移的な性質は以下のようになります。SITE.SALES.EXAMPLE.COM には SALES.EXAMPLE.COM との共有鍵が 1 つだけあります。しかし、小さい信頼が連続することで、SITE.SALES.EXAMPLE.COM から EVERYWHERE.EXAMPLE.COM に信頼が移動するという大きなトラストフローが可能になります。
このトラストフローは、共有鍵をドメインレベルで作成することで、完全に異なるドメイン間での行き来が可能になります。この場合、サイト間で共有される共通の接尾辞はありません。
異なるドメインでの信頼

図11.6 異なるドメインでの信頼

[capaths] セクション

フローを明示的に定義することで、ホップ数を減らして非常に複雑な信頼を表示することもできます。/etc/krb5.conf ファイルの [capaths] セクションでは異なるレルム間の信頼フローを定義します。
[capaths] セクションの形式は比較的単純です。各レルムのメインエントリーがあり、ここではクライアントにはプリンシパルが含まれます。次に各レルムセクションの中には、クライアントの資格情報の取得元となる中間レルムの一覧があります。
たとえば [capaths] を使用して、認証情報の取得に以下のプロセスを指定することができます。
  1. レルム A からの認証情報で、クライアントはレルム A の KDC から krbtgt/A@A チケットを取得します。このチケットを使用して、クライアントは krbtgt/B@A のチケットを要求します。
    レルム A の KDC が発行する krbtgt/B@A チケットは クロスレルムの TGT (Ticket-granting ticket) です。これにより、クライアントはレルム B の KDC に、レルム B のサービスプリンシパルへのサービスを要求することができます。
  2. krbtgt/B@A チケットを使用して、クライアントは krbtgt/C@B のクロスレルムチケットを要求します。
  3. レルム B が発行する krbtgt/C@B チケットを使用して、クライアントは krbtgt/D@C クロスレルムチケットを要求します。
  4. レルム C の KDC が発行する krbtgt/D@C チケットを使用して、クライアントはレルム D の KDC に、レルム D のサービスプリンシパルへのチケットを要求します。
このあと、認証情報キャッシュには、krbtgt/A@Akrbtgt/B@Akrbtgt/C@Bkrbtgt/D@Cservice/hostname@D のチケットが含まれます。service/hostname@D チケットを取得するには、中間のクロスレルムチケットを 3 つ取得する必要があります。
[capaths] 設定の実例を含む [capaths] セクションの詳細は、krb5.conf(5) の man ページを参照してください。

11.5.2. レルム信頼の設定

以下の例では、Kerberos レルムは A.EXAMPLE.COM および B.EXAMPLE.COM とします。
kadmin を使って A レルム内に B レルム用に共通プリンシパルのエントリーを作成します。
[root@server ~]# kadmin -r A.EXAMPLE.COM
kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created.
quit
上記では、A レルムが B プリンシパルを信頼していることを示しています。

重要

レルム間プリンシパルのパスワードは、非常に強固なものにすることが推奨されます。1 日に何度も入力を求められる他の多くのパスワードとは異なり、システムはレルム間プリンシパルのパスワードを頻繁に要求しません。このため、このパスワードを簡単に記憶できるものにする必要はありません。
双方向の信頼を作成するには、反対方向に移動するプリンシパルを作成します。kadmin を使って B レルム内に A レルム用のプリンシパルを作成します。
[root@server ~]# kadmin -r B.EXAMPLE.COM
kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created.
quit
get_principal コマンドを使用して、鍵バージョン番号 (kvno の値) と暗号化タイプが両方のエントリーで一致するか確認します。

重要

よくある間違った例では、管理者が add_principal コマンドを -randkey オプションと使用して、パスワードではなくランダムの鍵を割り当て、最初のレルムのデータベースから新規エントリーをダンプし、これを 2 番目にインポートしてしまいます。これは、レルムデータベースのマスター鍵が同じものでなければ、機能しません。データベースダンプに含まれている鍵自体が、マスター鍵を使って暗号化されているためです。