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] を使用して認証情報を取得するために以下のプロセスを指定できます。
- レルム A からのクレデンシャルでは、クライアントは Realm A の KDC から
krbtgt/A@Aチケットを取得します。このチケットを使用して、クライアントはkrbtgt/B@Aチケットを要求します。Realm A の KDC が発行するkrbtgt/B@Aチケットは、レルム間のチケット付与チケット です。クライアントは、Realm B の KDC に対してチケットを Realm B のサービスプリンシパルに要求できます。 krbtgt/B@Aチケットを使用すると、クライアントはkrbtgt/C@Bクロスレルムチケットを要求します。- Realm B の KDC が発行する
krbtgt/C@Bチケットを使用すると、クライアントはkrbtgt/D@Cクロスレルムチケットを要求します。 - 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
つまり、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
get_principal コマンドを使用して、鍵バージョン番号(
kvno の値)と暗号化タイプの両方が一致することを確認します。
重要
一般的な間違った状況は、管理者がパスワードの代わりにランダムな鍵を割り当て、最初のレルムのデータベースから新しいエントリーをダンプして 2 番目のレルムにインポートするために add_principal コマンドの
-randkey オプションを使用しようとすることです。データベースダンプに含まれる鍵自体がマスターキーを使用して暗号化されるため、レルムデータベースのマスターキーが同一でない限り動作しません。
