Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

11.5. クロスレルムの Kerberos 信頼の設定

Kerberos V5 レルムは、接続されたすべてのマスターとスレーブ上の Kerberos データベースに定義されている Kerberos プリンシパルのセットです。異なるレルムからのプリンシパルが相互に通信する場合は、レルム間の Kerberos 信頼を設定する必要があります。
多くの Linux 環境、および混合環境には、シングルサインオン、アプリケーション認証、およびユーザー管理のために Kerberos レルムが既に展開されています。これにより、Kerberos は、特に Linux 環境が Identity Management などのより構造化されたドメイン設定を使用していない場合に、さまざまなドメインおよび混合システム (Windows や Linux など) 環境で共通の統合パスになる可能性があります。

11.5.1. 信頼関係
リンクのコピー

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

図11.2 基本的な信頼

基本的な信頼
View larger image
基本的な信頼
図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 推移的な信頼

推移的な信頼
View larger image
推移的な信頼
推移的信頼の方向は 信頼フロー です。信頼フローは、最初にサービスが属するレルムを認識し、次にクライアントがそのサービスにアクセスするのに接続する必要のあるレルムを識別することで定義する必要があります。
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 同じドメインの信頼

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

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

同じドメインの子/親の信頼
View larger image
同じドメインの子/親の信頼
これは、推移的である信頼の性質です。SITE.SALES.EXAMPLE.COM には、SALES.EXAMPLE.COM との共有キーが 1 つだけあります。しかし、一連の小さな信頼のために、信頼が SITE.SALES.EXAMPLE.COM から EVERYWHERE.EXAMPLE.COM に移動できるようにする大きな信頼フローがあります。
この信頼フローは、ドメインレベルで共有鍵を作成し、サイトが共通の接尾辞を持たないことで、完全に異なるドメイン間で送信される可能性があります。

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

異なるドメインの信頼
View larger image
異なるドメインの信頼

[capaths] セクション

フローを明示的に定義することにより、ホップ数を減らし、非常に複雑な信頼フローを表すこともできます。/etc/krb5.conf ファイルの [capaths] セクションは、異なるレルム間の信頼フローを定義します。
[capaths] セクションの形式は比較的簡単です。クライアントがプリンシパルを持つ各レルムにメインエントリーがあり、各レルムセクションにはクライアントが認証情報を取得する中間レルムのリストになります。
たとえば、[capaths] を使用して認証情報を取得するために以下のプロセスを指定できます。
  1. レルム 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 にレルム 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 ページを参照してください。

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
Copy to Clipboard Toggle word wrap
つまり、A レルムが B プリンシパルを信頼することを意味します。
重要
レルム間のプリンシパルに非常に強固なパスワードを選択することが推奨されます。ユーザーに 1 日に数回プロンプトが表示される他の多くのパスワードとは異なり、システムはレルム間プリンシパルのパスワードを頻繁に要求しないため、簡単に覚える必要はありません。
双方向の信頼を作成するには、逆方向のプリンシパルを作成します。kadmin を使用して、B レルムに A レルムのプリンシパルを作成します。 
[root@server ~]# kadmin -r B.EXAMPLE.COM
kadmin: add_principal krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM
Enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM":
Re-enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM":
Principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM" created.
quit
Copy to Clipboard Toggle word wrap
get_principal コマンドを使用して、鍵バージョン番号(kvno の値)と暗号化タイプの両方が一致することを確認します。
重要
一般的な間違った状況は、管理者がパスワードの代わりにランダムな鍵を割り当て、最初のレルムのデータベースから新しいエントリーをダンプして 2 番目のレルムにインポートするために add_principal コマンドの -randkey オプションを使用しようとすることです。データベースダンプに含まれる鍵自体がマスターキーを使用して暗号化されるため、レルムデータベースのマスターキーが同一でない限り動作しません。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat