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 は、特に Linux 環境が Identity Management などのより構造化されたドメイン設定を使用していない場合に、さまざまなドメインおよび混合システム (Windows や Linux など) 環境で共通の統合パスになる可能性があります。

11.5.1. 信頼関係

信頼 とは、あるレルム内のユーザーが、そのレルムに属するかのように、別のドメインのリソースにアクセスするために信頼されることを意味します。これは、両方のドメインで共通に保持される単一のプリンシパルに共有キーを作成して行います。

図11.2 基本的な信頼

基本的な信頼
図11.2「基本的な信頼」 では、共有プリンシパルはドメイン B (krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM) に属します。プリンシパルが Domain A に追加されると、Domain A のクライアントは Domain 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 ドメインと同様に設定され、ルートドメインおよびサブドメインを持つことが前提となります。これは、信頼のフローが共有ルートに至ることを意味します。各ステップまたは ホップ には、共有キーがあります。図11.4「同じドメインの信頼」 では、SALES.EXAMPLE.COM が EXAMPLE.COM の鍵を共有し、EXAMPLE.COM が EVERYWHERE.EXAMPLE.COM の鍵を共有します。

図11.4 同じドメインの信頼

同じドメインの信頼
クライアントはレルム名を DNS 名として扱い、ルート名に到達するまで自身のレルム名の要素を取り除くことによって信頼パスを決定します。その後、サービスのレルムに到達するまで、名前を先頭に追加します。

図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. Realm A からの認証情報を使用すると、クライアントは Realm A の KDC から krbtgt/A@A チケットを取得します。このチケットを使用して、クライアントは krbtgt/B@A チケットを要求します。
    Realm A の KDC により発行された krbtgt/B@A チケットは、レルム間のチケット付与チケット です。クライアントは、Realm B の KDC に対してチケットを Realm B のサービスプリンシパルに要求できます。
  2. krbtgt/B@A チケットを使用すると、クライアントは krbtgt/C@B レルム間チケットを要求します。
  3. Realm B の KDC が発行する krbtgt/C@B チケットを使用すると、クライアントは krbtgt/D@C レルム間チケットを要求します。
  4. Realm C の KDC が発行する krbtgt/D@C チケットを使用すると、クライアントは Realm D の KDC に、Realm 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 ページを参照してください。