レルム は、ドメインに似た論理ネットワークです。レルムは、同一マスター KDC に登録されるシステムのグループを定義します。DNS ドメイン名を確立する場合と同様に、Kerberos サービスを構成する前に、レルム名、各レルムの数とサイズ、レルム間認証のためのレルムとその他のレルムとの関係などの問題を解決する必要があります。
レルム名には、任意の ASCII 文字列を使用できます。通常、レルム名が大文字である点を除き、レルム名は DNS ドメイン名と同じです。この規則により、なじみのある名前を維持しながら、Kerberos サービスに関する問題と DNS 名前空間に関する問題を区別しやすくなります。どのような文字列でも使用できますが、それにより、構成や保守に必要な作業が増える可能性があります。標準のインターネット命名構造に従ったレルム名を使用してください。
インストールするレルムの数は、次の要因によって異なります。
サポートするクライアント数。1 つのレルムに配置するクライアントが多すぎると、管理が複雑になり、レルムの分割が必要になることがあります。サポートできるクライアント数は、主に次の要因によって決まります。
各クライアントが生成する Kerberos トラフィックの量
物理ネットワークの帯域幅
ホストの処理速度
インストールごとに制限が違ってくるため、最大クライアント数を決定する規則はありません。
クライアント間の距離。クライアントが地理的に異なる領域に配置されている場合は、小さなレルムをいくつか設定することが望ましい方法です。
KDC としてインストールできるホスト数。レルムあたり少なくとも 2 つの KDC サーバー (1 つのマスターサーバーと少なくとも 1 つのスレーブサーバー) を作成するように計画してください。
Kerberos レルムと管理ドメインがそろっているようにすることをお勧めします。Kerberos V レルムは、そのレルムの対応する DNS ドメインの複数のサブドメインにまたがることができます。
複数のレルムを構成してレルム間認証を行う場合は、レルム間の接続方法を決定する必要があります。レルム間に階層関係を設定すると、関連付けたドメインに自動パスが作成されます。階層チェーン内のすべてのレルムが正しく構成されていれば、これらの自動パスによって管理の負荷を軽減できます。ただし、ドメインのレベル数が多い場合は、非常に多くのトランザクションが必要になるため、自動パスを使用しないようにすることをお勧めします。
また、信頼関係を直接確立することもできます。直接の信頼関係は、2 つの階層レルム間に存在するレベル数が多すぎる場合や、階層関係が存在しない場合に役立ちます。接続は、この接続を使用するすべてのホスト上の /etc/krb5/krb5.conf ファイルで定義する必要があるため、ある程度の追加の作業が必要になります。直接の信頼関係は、推移的関係とも呼ばれます。図については、Kerberos レルムを参照してください。構成手順については、レルム間認証の構成を参照してください。
ホスト名のレルム名へのマッピングは、krb5.conf ファイルの domain_realm セクションで定義されます。これらのマッピングは、必要に応じてドメイン全体およびホスト単位に定義できます。
また、DNS を使用して KDC に関する情報を検索することもできます。DNS を使用すると、変更のたびにすべての Kerberos クライアント上の krb5.conf ファイルを編集する必要がないため、情報の変更が容易になります。
詳細は、krb5.conf(4) のマニュアルページを参照してください。
Oracle Solaris の Kerberos クライアントは、Active Directory サーバーと適切に相互運用します。Active Directory サーバーは、ホストのマッピングにレルムを提供するように構成できます。
Oracle Solaris の Kerberos では、name-service/switch サービスを使用しません。代わりに、Kerberos サービスは DNS を使用してホスト名を解決します。そのため、すべてのホスト上で DNS が有効になっている必要があります。DNS では、主体に各ホストの完全修飾ドメイン名 (FQDN) が含まれている必要があります。たとえば、ホスト名が boston、DNS ドメイン名が example.com、レルム名が EXAMPLE.COM である場合、ホストの主体名は host/boston.example.com@EXAMPLE.COM になります。このガイドの例では、DNS が構成されていて、各ホストに対して FQDN が使用されていることが必要です。
Kerberos サービスは DNS を介してホストの別名を正規化し、関連するサービスのサービス主体を構築する際には正規化された形式 (正規名) を使用します。そのため、サービス主体を作成するとき、サービス主体名のホスト名コンポーネントはそのサービスを提供するシステムのホスト名の正規化形式です。
次の例は、Kerberos サービスがホスト名を正規化する方法を示しています。ユーザーがコマンド ssh alpha.example.com (ここで、alpha.example.com は正規名 beta.example.com に対する DNS ホストの別名) を実行すると、Kerberos サービスは alpha.example.com を beta.example.com に正規化します。KDC は、このチケットをサービス主体 host/beta.example.com に対するリクエストとして処理します。
ホストの FQDN を含む主体名の場合は、/etc/resolv.conf ファイル内の DNS ドメイン名を表す文字列に必ず一致するようにしてください。Kerberos サービスでは、主体に FQDN を指定するときに、DNS ドメイン名は小文字にする必要があります。DNS ドメイン名には大文字と小文字を使用できますが、ホスト主体を作成する場合は小文字だけを使用します。たとえば、DNS ドメイン名は example.com、Example.COM、またはその他のどのようなバリエーションであってもかまいません。ホストの主体名は、host/boston.example.com@EXAMPLE.COM でなければなりません。
さらに、DNS クライアントサービスが実行されていない場合に多数のデーモンまたはコマンドが起動しないように、サービス管理機能 (SMF) が構成されています。kdb5_util、kadmind、kpropd デーモン、および kprop コマンドは、DNS サービスに依存するように構成されています。Kerberos サービスおよび SMF から使用可能な機能を完全に使用するには、すべてのホスト上で DNS クライアントサービスを有効にする必要があります。
Kerberos 認証システムに参加するすべてのホストの内部クロックを、指定された最大時間内に同期する必要があります。「クロックスキュー」と呼ばれるこの機能も、Kerberos セキュリティー検査の 1 つです。参加しているホスト間でクロックスキューを超過すると、要求が拒否されます。
すべてのクロックを同期化するときは、Network Time Protocol (NTP) ソフトウェアを使用します。詳細は、KDC と Kerberos クライアントのクロックの同期化を参照してください。クロック同期のその他の方法も使用できますが、何らかの形式の同期が必要です。
暗号化タイプとは、Kerberos サービスで使用される、暗号化アルゴリズム、暗号化モード、およびハッシュアルゴリズムを特定する識別子です。Kerberos サービスの鍵には、このサービスがその鍵で暗号化操作を実行するときに使用される暗号化アルゴリズムとモードを指定する暗号化タイプが関連付けられています。サポートされている暗号化タイプのリストについては、krb5.conf(4) および kdb5_util(1M) のマニュアルページを参照してください。
暗号化タイプを変更する場合は、新しい主体データベースを作成するときに行います。KDC、サーバー、クライアント間の相互作用のために、既存のデータベースでの暗号化タイプの変更は困難です。詳細は、Kerberos 暗号化タイプを参照してください。
des などの弱い暗号化タイプは、デフォルトでは許可されません。下位互換性または相互運用性のために弱い暗号化タイプを使用する必要がある場合は、/etc/krb5/krb5.conf ファイルの libdefaults セクション内の allow_weak_crypto エントリを true に設定します。