48.6.9. レルム間の認証の設定
レルム間の認証 は、1 つのレルムのクライアント（通常はユーザー）が Kerberos を使用してサービス（通常は特定のサーバーシステムで実行しているサーバープロセス）に対して認証を行う状況を説明するために使用される用語です。
最も単純なケースでは、
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.COMEnter 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. kadmin:quit~]# kadmin -r B.EXAMPLE.COM kadmin:add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COMEnter 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. kadmin:quit
get_principal コマンドを使用して、鍵バージョン番号 (
kvno の値) と暗号化タイプの両方が一致することを確認します。
データベースのダンプが実行されない
セキュリティー意識のある管理者は、パスワードの代わりにランダムキーの割り当てに add_principal コマンドの
-randkey オプションを使用し、最初のレルムのデータベースから新しいエントリーをダンプして、2 番目のレルムにインポートすることができます。データベースダンプに含まれる鍵自体がマスターキーを使用して暗号化されるため、レルムデータベースのマスターキーが同一でない限り動作しません。
A.EXAMPLE.COM レルムのクライアントは、B.EXAMPLE.COM レルムのサービスに対して認証できるようになりました。別の方法では、B.EXAMPLE.COM レルムが A.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 サービスの鍵を共有する必要があります（上記の例と比較した 2 つのレルムの順番で逆順で注意します）。
直接信頼関係がレルム間の信頼を提供する唯一の方法である場合、複数のレルムを含むネットワークはセットアップが非常に困難になります。幸い、クロスレルムの信頼は推移的です。
A.EXAMPLE.COM のクライアントが B.EXAMPLE.COM のサービスに対して認証でき、B.EXAMPLE.COM のクライアントが C.EXAMPLE.COM のサービスに対して認証できる場合、C.EXAMPLE.COM のクライアントは、C.EXAMPLE.COM で直接 A.EXAMPLE.COMの サービスに対して認証することもできます。つまり、相互に信頼する必要がある複数のレルムがあるネットワークでは、セットアップする信頼関係に適切な選択を行うことで、必要な作業量を大幅に削減できる可能性があることを意味します。
従来の問題が発生しました。クライアントのシステムは、特定のサービスが属するレルムを適切に推測できるように設定する必要があり、そのレルム内のサービスの認証情報を取得する方法を判断できる必要があります。
最初：特定のレルムの特定サーバーシステムから提供されるサービスのプリンシパル名は通常、以下のようになります。
service/server.example.com@EXAMPLE.COM
この例では、サービス は通常、使用中のプロトコルの名前( ldap imap、cvs、および HTTP)または ホスト、server.example.com はサービスを実行するシステムの完全修飾ドメイン名で、
EXAMPLE.COM はレルムの名前です。
サービスが属するレルムを推測するために、クライアントはほとんどの場合
/etc/krb5.conf の DNS または domain_realm セクションを参照して、ホスト名(server.example.com)または DNS ドメイン名(.example.com)をレルム名(EXAMPLE.COM)にマッピングします。
サービスが属するレルムを決定するには、クライアントは問い合わせる必要のあるレルムのセットと、サービスへの認証に使用する認証情報を取得するためにそれらと通信する必要のある順番を決定する必要があります。
これは 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
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の鍵を共有
より複雑で柔軟な方法は、
/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
