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

3.7. レルム間認証の設定

あるレルムのクライアント (通常は、Kerberos を使用して、特定のサーバーシステムで実行しているサーバープロセス) を許可するには、クロスレルム認証が必要です。

3.7.1. 基本的な信頼関係の設定
リンクのコピー

最も単純なケースでは、レルム A.EXAMPLE.COM のクライアントが B.EXAMPLE.COM レルムのサービスにアクセスするには、両方のレルムが krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM という名前のプリンシパルのキーを共有する必要があります。また、両方のキーに同じキーが関連付けられている必要があります。
これを行うには、非常に強固なパスワードまたはパスフレーズを選択し、kadmin を使用して両方のレルムにプリンシパルのエントリーを作成します。 
# 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

# 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 番目のレルムにインポートすることです。データベースダンプに含まれる鍵自体がマスターキーを使用して暗号化されるため、レルムデータベースのマスターキーが同一でない限り動作しません。
A.EXAMPLE.COM レルムのクライアントは、B.EXAMPLE.COM レルムのサービスに対して認証できるようになりました。別の方法として、B.EXAMPLE.COM レルムが A.EXAMPLE.COM レルムを信頼するようになりました。
デフォルトでは、クロスレルム信頼は一方向です。B.EXAMPLE.COM レルムの KDC は、B.EXAMPLE.COM レルムのサービスに対して認証を行うために A.EXAMPLE.COM からのクライアントを信頼できます。ただし、この信頼は自動的に再処理されないため、B.EXAMPLE.COM レルムは A.EXAMPLE.COM レルムのサービスに対して認証するために信頼されています。反対方向の信頼を確立するには、両方のレルムが krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM サービスの鍵を共有する必要があります。これは、前述の例とは反対のマッピングのエントリーになります。

3.7.2. 複合信頼関係の設定
リンクのコピー

直接信頼関係がレルム間の信頼を提供する唯一の方法である場合、複数のレルムを含むネットワークはセットアップが非常に困難になります。幸い、クロスレルムの信頼は推移的です。A.EXAMPLE.COM のクライアントが B.EXAMPLE.COM のサービスに対して認証可能で、B.EXAMPLE.COM のクライアントが C.EXAMPLE.COM のサービスに対して認証できる場合は、C.EXAMPLE.COM が A.EXAMPLE.COM を直接信頼していない場合でも、A.EXAMPLE .COM のクライアントは C.EXAMPLE.COM のサービスに対して認証することもできます。つまり、相互に信頼する必要がある複数のレルムがあるネットワークでは、セットアップする信頼関係に適切な選択を行うことで、必要な作業量を大幅に削減できる可能性があることを意味します。
クライアントのシステムは、特定のサービスが属するレルムを適切に推測できるように設定する必要があります。また、そのレルム内のサービスの認証情報の取得方法を判断できる必要があります。
最初に、通常、指定されたレルムの特定のサーバーシステムから提供されるサービスのプリンシパル名は以下のようになります。 
service/server.example.com@EXAMPLE.COM
サービス は通常、使用するプロトコルの名前 (LDAP、IMAP、CVS、HTTP など) または ホスト です。server.example.com は、サービスを実行するシステムの完全修飾ドメイン名です。example.COM はレルムの名前です。
サービスが属するレルムを判別するため、クライアントは、ホスト名 (server.example.com) または DNS ドメイン名(.example.com) をレルム名 (EXAMPLE.COM) にマップするために DNS または /etc/krb5.conf の domain_realm セクションを参照してください。
サービスが属するレルムを決定した後、クライアントは接続する必要のあるレルムのセットを決定する必要があります。そして、サービスに対する認証に使用する認証情報を取得するために、接続する順番を判断する必要があります。
これは 2 つの方法の 1 つで実行できます。最も単純な方法は、共有階層を使用してレルムに名前を付けることです。2 つ目は、krb5.conf ファイルで明示的な設定を使用します。

3.7.2.1. 名前の共有階層の設定
リンクのコピー

明示的な設定を必要としないデフォルトの方法は、共有階層内でレルム名を提供することです。たとえば、A.EXAMPLE.COM、B.EXAMPLE.COM、および EXAMPLE.COM という名前のレルムを想定します。A.EXAMPLE.COM レリムのクライアントが B.EXAMPLE.COM 内のサービスに対して認証を試みると、デフォルトでは、最初に EXAMPLE.COM レルムの認証情報を取得してから、これらの認証情報を使用して B.EXAMPLE.COM レルムで使用する認証情報を取得します。
このシナリオのクライアントは、レルム名を DNS 名を処理する可能性があるものとして扱います。これは、自身のレルム名のコンポーネントを繰り返し取り除き、階層内で「上」のレリムの名前を生成します。これは、サーバーレリムの「上」でもある位置に達するまで行われます。この時点で、サービスのレルムに到達するまで、サービスのレルム名のコンポーネントを先頭に追加し始めます。プロセスに関与する各レルムは別の「ホップ」です。
たとえば、A.EXAMPLE.COM で認証情報を使用すると、B.EXAMPLE.COM のサービスに対して認証を行う際に A.EXAMPLE.COM EXAMPLE.COM B.EXAMPLE.COM の 3 つのホップがあります。
  • A.EXAMPLE.COM および EXAMPLE.COM が krbtgt/EXAMPLE.COM@A.EXAMPLE.COM の鍵を共有
  • EXAMPLE.COM および B.EXAMPLE.COM が krbtgt/B.EXAMPLE.COM@EXAMPLE.COM の鍵を共有
もう 1 つの例は、SITE1.SALES.EXAMPLE.COM で認証情報を使用して EVERYWHERE.EXAMPLE.COM でのサービスに対する認証に、複数のシリーズのホップを利用できます。 
SITE1.SALES.EXAMPLE.COM  
SALES.EXAMPLE.COM  
EXAMPLE.COM  
EVERYWHERE.EXAMPLE.COM
  • SITE1.SALES.EXAMPLE.COM と SALES.EXAMPLE.COM が krbtgt/SALES.EXAMPLE.COM@SITE1.SALES.EXAMPLE.COM の鍵を共有
  • SALES.EXAMPLE.COM と EXAMPLE.COM が krbtgt/EXAMPLE.COM@SALES.EXAMPLE.COM の鍵を共有
  • EXAMPLE.COM と EVERYWHERE.EXAMPLE.COM が krbtgt/EVERYWHERE.EXAMPLE.COM@EXAMPLE.COM の鍵を共有
DEVEL.EXAMPLE.COM や PROD.EXAMPLE.ORG など、共通のサフィックスを持たない名前のレリム名間にホップがある場合さえあります。 
DEVEL.EXAMPLE.COM  
EXAMPLE.COM  
COM  
ORG  
EXAMPLE.ORG  
PROD.EXAMPLE.ORG
  • DEVEL.EXAMPLE.COM と EXAMPLE.COM が krbtgt/EXAMPLE.COM@DEVEL.EXAMPLE.COM の鍵を共有
  • EXAMPLE.COM と COM が krbtgt/COM@EXAMPLE.COM の鍵を共有
  • COM と ORG が krbtgt/ORG@COM の鍵を共有
  • ORG と EXAMPLE.ORG が krbtgt/EXAMPLE.ORG@ORG を共有
  • EXAMPLE.ORG および PROD.EXAMPLE.ORG が krbtgt/PROD.EXAMPLE.ORG@EXAMPLE.ORG を共有

3.7.2.2. krb5.conf のパスの設定
リンクのコピー

より複雑でも柔軟な方法は、/etc/krb5.conf の capaths セクションを設定することです。これにより、1 つのレルムに認証情報があるクライアントが、チェーン内でどのレルムが次であるかを検索できます。これはい最終的にサーバーに認証できます。
capaths セクションの形式は比較的簡単です。セクションの各エントリーは、クライアントが存在する可能性があるレルムの後に名前が付けられます。そのサブセクション内では、クライアントが認証情報を取得する必要のある中間レルムのセットが、サービスが置かれるレルムに対応するキーの値として一覧表示されます。中間レルムがない場合は、「.」が使用されます。
以下に例を示します。 
[capaths]
A.EXAMPLE.COM = {
B.EXAMPLE.COM = .
C.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = C.EXAMPLE.COM
}
A.EXAMPLE.COM レルムのクライアントは、A.EXAMPLE.COM KDC から直接 B.EXAMPLE.COM のレルム間認証情報を取得できます。
これらのクライアントが C.EXAMPLE.COM レルムのサービスに問い合わせる必要がある場合は、最初に B.EXAMPLE.COM レルムから必要な認証情報を取得する必要があります (これには krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM が必要です)。次に、これらの認証情報を使用して C.EXAMPLE.COM レルムで使用する認証情報を取得します (krbtgt/C.EXAMPLE.COM@B.EXAMPLE.COM を使用)。
これらのクライアントが D.EXAMPLE.COM レルムのサービスに問い合わせたい場合は、最初に B.EXAMPLE.COM レルムから必要な認証情報を取得し、次に C.EXAMPLE.COM レルムから認証情報を取得して D.EXAMPLE.COM レルムで使用する認証情報を取得する必要があります。

注記

特に示される capath エントリーがない場合、Kerberos はレルム間の信頼関係が階層を形成していると仮定します。
A.EXAMPLE.COM レルムのクライアントは、B.EXAMPLE.COM レルムから直接レルム間の認証情報を取得できます。「.」を指定しないと、クライアントは代わりに階層パスを使用しようとします。この場合は以下のようになります。 
A.EXAMPLE.COM  EXAMPLE.COM  B.EXAMPLE.COM
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る