Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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 推移的な信頼

推移的な信頼
推移的な信頼の方向は信頼 フロー です。最初にサービスが属するレルムを認識して、信頼フローを定義する必要があります。これには、クライアントがそのサービスにアクセスするために接続する必要のあるレルムを特定します。
Kerberos プリンシパル名は、service/hostname@REALM 形式で構成されますサービス は通常、LDAP、IMAP、HTTP、ホストなどのプロトコルです。hostname はホストシステムの完全修飾ドメイン名で、REALM 所属する Kerberos レルムです。Kerberos クライアントは通常、Kerberos レルムマッピングのホスト名または DNS ドメイン名を使用します。このマッピングは明示的または暗黙的です。明示的なマッピングは、/etc/krb5.conf ファイルの [domain_realm] セクションを使用します。暗黙的なマッピングでは、ドメイン名が大文字に変換されます。変換された名前は、検索する Kerberos レルムであると想定されます。
Kerberos は、信頼を通過する際に、各レリムが階層 DNS ドメインのような階層的な DNS ドメインとして構成されることを想定し、root ドメインおよびサブドメインを使用します。これは、信頼が共有ルートまで流れることを意味します。各ステップまたは ホップ には、共有キーがあります。図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] セクションの形式は比較的簡単です。クライアントのプリンシパルがある各レルムにメインエントリーがあり、次に各 realm セクション内にクライアントがクレデンシャルを取得する必要のある中間レルムのリストになります。
たとえば 、[capaths] を使用して認証情報を取得するために以下のプロセスを指定できます。
  1. Realm A からクレデンシャルを使用すると、クライアントはレルム A の KDC から krbtgt/A@A チケットを取得します。このチケットを使用して、クライアントは krbtgt/B@A チケットを要求します。
    レルム A の KDC が発行する krbtgt/B@A チケットは、クロスレルムチケット付与チケット です。これにより、クライアントは Realm B の KDC にレルム B のサービスプリンシパルに尋ねることができます。
  2. krbtgt/B@A チケットにより、クライアントは krbtgt/C@B cross-realm チケットを要求します。
  3. レルム B の KDC により krbtgt/C@B チケットを発行すると、クライアントは krbtgt/D@C cross-realm チケットを要求します。
  4. Realm C の KDC が発行する krbtgt/D@C チケットを使用すると、クライアントは Realm D のチケットに対して、レルム D のサービスプリンシパルに発行されるよう要求します。
この後、認証情報キャッシュには krbtgt/A@A、krbtgt/B@A、krbtgt/C@B、 krbtgt/ D@C、および service/hostname@D のチケット が含まれます。service/hostname@D チケットを取得するには、3 つの中間クロスレルムチケットを取得する必要がありました。
[capaths] 設定のサンプルを含む [capaths] セクションの詳細は、krb5.conf(5) man ページを参照してください。