第5章 Active Directory および Identity Management によるフォレスト間の信頼作成

本章では、Active Directory と Active Directory Identity Management の間のクロスフォレストトラストの作成について説明します。アイデンティティー管理および Active Directory 環境を間接的に統合する方法で推奨の方法が 2 つあり、クロスフォレストトラストは、そのうちの 1 つとです。もう 1 つの方法が同期です。お使いの環境でどちらの方法を選択するといいのか不明な場合には、「間接的な統合」を確認してください。
Kerberos は 信頼という概念を実装しています。信頼では、ある Kerberos レルムからのプリンシパルが別の Kerberos レルムのサービスにチケットを要求できます。プリンシパルはこのチケットを使って、別のレルムに属するマシン上のリソースに対して認証を行うことができます。
Kerberos には、2 つの別個のレルム間の関係を作成する機能があります。これは、レルム間の信頼と呼ばれています。この信頼の一部となっているレルムは、共有のチケットとキーのペアを使用します。1 つのレルムのメンバーが両方のレルムのメンバーとして認識されるようなります。
Red Hat Identity Management は、IdM ドメインと Active Directory ドメイン間のフォレスト間の信頼設定に対応しています。

5.1. フォレスト間の信頼について

Kerberos レルムが関与するのは認証のみです。他のサービスやプロトコルが、Kerberos レルム内のマシンで実行中のリソースについての識別や承認を補完します。
このため、Kerberos レルム間の信頼を確立するだけでは、あるレルムのユーザーが別のレルムにあるリソースにアクセスするには不十分になります。通信の別のレベルでのサポートも必要になってきます。

5.1.1. 信頼関係のアーキテクチャー

Active Directory および Identity Management の両方が、Kerberos、LDAP、DNS、または証明書サービスなどの各種のコアサービスを管理します。これら 2 つの異なる環境を透過的に統合するには、すべてのコアサービスが相互にシームレスに対話する必要があります。

Active Directory の信頼、フォレスト、およびフォレスト間の信頼

Kerberos レルム間の信頼は、Active Directory の環境間の認証で重要な役割を果たします。信頼される AD ドメインでユーザーおよびグループ名を解決するすべてのアクティビティーは、アクセス方法に関係なく認証が必要になります。つまり、LDAP プロトコルを使用する場合でも、Server Message Block (SMB) プロトコルの他に分散コンピューティング環境/リモートプロシージャーコール (DCE/RPC) の一部とする場合でもです。2 つの異なる Active Directory ドメイン間でのアクセスを組織する際には多くのプロトコルが関わってくるため、信頼の関係は Active Directory 信頼 という一般的な名前になります。
複数の AD ドメインは、1 つの Active Directory forest にまとめることができます。このフォレストの root ドメインは、フォレスト内で作成される最初のドメインになります。Identity Management ドメインは既存の AD フォレストの一部とすることはできないため、常に別個のフォレストとみなされます。
2 つの別個のフォレスト root ドメイン間で信頼関係が確立され、異なる AD フォレストからユーザーやサービスが通信できるように なると、この信頼は Active Directory フォレスト間の信頼と呼ばれるようになります。

信頼のフローと一方向の信頼

信頼は 2 つのドメイン間のアクセス関係を確立します。Active Directory 環境は複雑になり得るので、サブドメイン、root ドメイン、またはフォレスト間には複数の異なるタイプの Active Directory 信頼やその配置が存在することになります。信頼は、あるドメインから別のドメインへのパスです。アイデンティティーおよび情報がドメイン間で移動することは 信頼のフロー と呼ばれます。
信頼されるドメイン にはユーザーが含まれ、信頼するドメイン はリソースへのアクセスを許可します。一方向の信頼では、ユーザーは信頼する側のドメインのリソースにアクセスできますが、信頼する側のドメインのユーザーは、信頼されるドメインのリソースにアクセスすることはできないという一方向のみの信頼のフローになります。図5.1「一方向の信頼」 では、ドメイン A はドメイン B から信頼されていますが、ドメイン B はドメイン A から信頼されていません。
一方向の信頼

図5.1 一方向の信頼

IdM を使用すると、管理者は一方向および双方向の両方の信頼を設定できます。詳細は、「一方向および双方向の信頼」 を参照してください。

推移的および非推移的な信頼

信頼は 推移的 とすることが可能で、その場合、1 つ目のドメインが別のドメインを信頼し、この 2 つ目のドメインが信頼してしているの他のドメインも 1 つ目のドメインが信頼することになります。
推移的な信頼

図5.2 推移的な信頼

信頼は 非推移的 にすることもできます。この場合、信頼関係は明示的に含まれるドメインに限定されます。

Active Directory と Identity Management におけるフォレスト間の信頼

Active Directory フォレスト内では、ドメイン間の信頼関係は通常双方向で、デフォルトで推移的となっています。
2 つの AD フォレスト間の信頼は 2 つのフォレスト root ドメイン間の信頼なので、双方向にも一方向にもすることができます。フォレスト間の信頼の推移性は明示的なものです。つまり、フォレストの root ドメインにつながっている AD フォレスト内のドメイン信頼は、フォレスト間の信頼で推移的になります。ただし、別個のフォレスト間信頼は非推移的になります。ある AD フォレスト root ドメインと別の AD フォレスト root ドメイン間では、明示的なフォレスト信頼を確立する必要があります。
ADの観点からは、Identity Management は単一の AD ドメインを持つ個別の AD フォレストを表します。AD フォレスト root ドメインと IdM ドメイン間でフォレスト間信頼が確立されると、AD フォレストドメインからのユーザーは IdM ドメインからの Linux マシンやサービスと対話できるように なります。
信頼の方向

図5.3 信頼の方向

5.1.2. Active Directory セキュリティーオブジェクトおよび信頼

Active Directory グローバルカタログ

グローバルカタログには Active Directory のオブジェクトについての情報が含まれます。自身のドメイン内にあるオブジェクトの完全コピーが保存されます。Active Directory フォレスト内の他のドメインのオブジェクトからは、最も一般的に検索される属性のコピーの一部のみがグローバルカタログに保存されます。また、グループの一部のタイプのみが特定のスコープ内で有効になり、これはグローバルカタログの一部とならない可能性があります。
フォレスト間信頼のコンテキストは、単一ドメインのものよりも広くなることに注意してください。このため、信頼されるフォレストからのサーバー-ローカルもしくはドメイン-ローカルのセキュリティーグループメンバーシップの一部は、IdM サーバーに認識されない可能性があります。

グローバルカタログと POSIX 属性

Active Directory はデフォルトでは POSIX 属性を複製しません。Red Hat では、AD で定義される POSIX 属性を使用する必要がある場合は、グローバルカタログサービスに属性を複製することを強く推奨しています。

5.1.3. IdM における信頼アーキテクチャー

Identity Management 側では、IdM サーバーは Active Directory アイデンティティーを認識し、かつアクセス制御のグループメンバーシップを適切に処理できる必要があります。Microsoft PAC (MS-PAC、Privilege Account Certificate) にはユーザーについての必要な情報が含まれます。これには、ユーザーのセキュリティー ID、ドメインユーザー名、およびグループメンバーシップが含まれます。Identity Management には、Kerberos チケット上の PAC のデータを分析する 2 つのコンポーネントがあります。
  • SSSD は、Active Directory 上の ID 検索を実行し、認可のためにユーザーおよびグループセキュリティー識別子 (SID) を取得します。さらに SSSD は、ユーザー、グループ、およびユーザーのチケット情報をキャッシュし、Kerberos および DNS ドメインをマップします。
  • Identity Management (Linux ドメイン管理) は、Active Directory ユーザーを、an IdM ポリシーおよびアクセスのために IdM グループと関連付けます。

    注記

    SELinux、sudo、およびホストベースのアクセス制御など、Linux ドメイン管理のアクセス制御ルールおよびポリシーは Identity Management で定義され、適用されます。Active Directory 側で設定されるいずれのアクセス制御ルールも IdM では評価または使用されます。関連する Active Directory 設定はグループメンバーシップのみになります。

異なる Active Directory フォレストとの信頼

IdM は複数の異なる AD フォレストとの信頼関係の一部に組み込むこともできます。信頼が確立されると、同じコマンドと手順で他のフォレストとの信頼を後で追加することができます。IdM は複数のまったく無関係のフォレストを同時に信頼できるため、関連性のない AD フォレストのユーザーが同じ共有済みの IdM ドメイン内のリソースにアクセスできます。

5.1.3.1. Active Directory PAC および IdM チケット

Active Directory 内のグループ情報は、特権属性証明書 (MS-PAC または PAC) のデータセット内の識別子リストに保存されます。PAC には、グループメンバーシップや新たな認証情報などの各種の認証情報が含まれます。また、これには、Active Directory ドメイン内のユーザーおよびグループの セキュリティー識別子 (SID) も含まれます。SID は、Active Directory ユーザーおよびグループの作成時にそれらに割り当てられる識別子です。信頼環境では、グループのメンバーは名前や DN ではなく、SID で識別されます。
PAC は、Active Directory ユーザー向けにエンティティーを Windows ドメイン内の他の Windows クライアントおよびサーバーに特定する方法として、Kerberos サービスリクエストチケットに埋め込まれています。IdM は PAC 内のグループ情報を Active Directory グループにマッピングし、その後に対応する IdM グループにマッピングすることでアクセスを決定します。
Active Directory ユーザーが IdM リソース上のサービスのチケットをリクエストすると、以下のプロセスが実行されます。
  1. サービスのリクエストにはユーザーの PAC が含まれます。IdM KDC は、Active Directory グループ一覧と IdM グループ内のメンバーシップを比較して PAC を分析します。
  2. MS-PAC 内で定義されている Kerberos プリンシパルの SID の場合、IdM KDC が IdM LDAP で定義されている外部のグループメンバーシップを評価します。SID の新たなマッピングが利用可能な場合、MS-PAC レコードは SID が属する IdM グループの他の SID で拡張されます。この拡張された MS-PAC は IdM KDC で署名されます。
  3. IdM KDC で署名された更新済み PAC のあるサービスチケットがユーザーに返されます。IdM に既知の AD グループに属するユーザーは、これでサービスチケットの MS-PAC コンテンツをベースにした IdM クライアント上で実行している SSSD に認識されます。これにより、IdM クライアントによるグループメンバーシップを検索するアイデンティティートラフィックを抑制することができます。
IdM クライアントがサービスチケットを評価する際には、以下のプロセスが発生します。
  1. 評価プロセスで使用される Kerberos クライアントライブラリーが PAC データを SSSD PAC レスポンダーに送信します。
  2. PAC レスポンダーが PAC 内のグループ SID を確認し、ユーザーを SSSD キャッシュ内の対応するグループに追加します。SSSD は、新規サービスがアクセスされるたびに複数の TGT と各ユーザーのチケットを保存します。
  3. 確認されたグループに所属するユーザーは、IdM 側にある必要なサービスにアクセスできるように なります。

5.1.3.2. Active Directory ユーザーと Identity Management グループ

Active Directory のユーザーとグループを管理する際には、個別の AD ユーザーと AD グループ全体を Identity Management グループに追加することができます。
IdM グループを AD ユーザー向けに設定する詳細な方法は、「IdM ユーザー用の Active Directory グループの作成」 を参照してください。

非 POSIX の外部グループおよび SID マッピング

IdM LDAP 内のグループメンバーシップは、グループのメンバーである LDAP の識別名 (DN) を指定することで表記されます。AD エントリーは IdM と同期されたりコピーされたりしないので、AD ユーザーとグループは IdM LDAP 内に LDAP オブジェクトがないことになります。このため、IdM LDAP 内のグループメンバーシップの表記にこれらは直接使用できません。
この理由のために、IdM は 非 POSIX 外部グループ を作成します。これは AD ユーザーおよびグループの SID への参照を文字列として含むプロキシ LDAP オブジェクトです。非 POSIX 外部グループは、IdM 内の AD ユーザーおよびグループのグループメンバーシップを表示する際に通常の IdM LDAP オブジェクトとして参照されます。
非 POSIX 外部グループの SID は SSSD で処理されます。SSSD は、AD ユーザーが所属するグループの SID を IdM の POSIX グループにマップします。AD 側の SID は、ユーザー名に関連付けられています。ユーザー名を使用して IdM リソースにアクセスすると、IdM 内の SSSD がそのユーザー名を SID に解決し、AD 内のその SID の情報を検索します。これについては 「Active Directory PAC および IdM チケット」 で説明してます。

ID の範囲

Linux でユーザーが作成されると、ユーザー ID 番号が割り当てられ、さらにそのユーザーのプライベートグループが作成されます。プライベートグループの ID 番号はユーザー ID 番号と同じものになります。Linux 環境ではこれによって競合は発生しませんが、Windows では、セキュリティー ID 番号はドメイン内の各オブジェクトで一意である必要があります。
信頼される AD ユーザーは、Linux システムで UID および GID 番号が必要になります。この UID/GID 番号は IdM で生成できますが、AD エントリーに UID/GID 番号がすでに割り当てられている場合は、異なる番号を割り当てると競合が生じます。このような競合を避けるために、AD で定義された POSIX 属性 (UID/GID 番号および好みのログインシェルを含む) を使用することができます。

注記

AD は、フォレスト内の全オブジェクトの情報のサブセットを グローバルカタログ に保存します。このグローバルカタログには、フォレスト内のすべてのドメインの全エントリーが含まれます。AD 定義の POSIX 属性を使用する場合は、Red Hat では、最初に属性をグローバルカタログに複製することを強く推奨しています。
信頼が作成されると IdM は使用する ID 範囲を自動的に検出し、信頼に追加される AD ドメイン用に一意の ID 範囲を作成します。これは以下のオプションのいずれかを ipa trust-add コマンドに渡すことで手動で選択することもできます。
ipa-ad-trust
この範囲のオプションは、SID をベースに IdM がアルゴリズムで生成した ID に使用します。
IdM が SID-to-POSIX ID マッピングを使用して SID を生成している場合は、AD および IdM ユーザーおよびグループの ID 範囲は一意で、重複しない ID 範囲が利用可能になっている必要があります。
ipa-ad-trust-posix
この範囲のオプションは、AD エントリー内の POSIX 属性で定義された ID に使用されます。
IdM は、uidNumber および gidNumberなどを含む POSIX 属性を AD のグローバルカタログまたはディレクトリーコントローラーから取得します。AD ドメインが適切に管理されており、かつ ID の競合がなければ、この方法で生成された ID 番号は一意のものになります。この場合、ID の検証や範囲は必要ありません。
例:
[root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust-posix
他の ID 範囲でのトラストの再作成
作成したトラストの ID 範囲が使用しているデプロイメントに適さない場合には、他の --range-type オプションを使用してトラストを再作成します。
  1. 現在使用している ID 範囲をすべて表示します。
    [root@ipaserver ~]# ipa idrange-find
    ipa trust-add コマンドで作成した ID 範囲名を、リストの中から特定します。ID 範囲名の最初の部分は、トラストの名前 (name_of_the_trust_id_range) です。例: ad.example.com
  2. (オプション) トラストの作成時に、どの --range-type オプション (ipa-ad-trust または ipa-ad-trust-posix) を使用したか分からない場合には、以下のコマンドを使用してオプションを特定します。
    [root@ipaserver ~]# ipa idrange-show name_of_the_trust_id_range
    タイプをメモし、ステップ 5 で新しいトラストには、もう一方のタイプを選択します。
  3. ipa trust-add コマンドで作成された範囲を削除します。
    [root@ipaserver ~]# ipa idrange-del name_of_the_trust_id_range
  4. トラストを削除します。
    [root@ipaserver ~]# ipa trust-del name_of_the_trust
  5. 正しい --range-type オプションで新規トラストを作成します。以下に例を示します。
    [root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust

5.1.3.3. Active Directory ユーザーと IdM ポリシーおよび設定

SELinux、ホストベースのアクセス制御、sudo およびネットグループなどのいくつかの IdM ポリシー定義では、ポリシー適用方法の特定でユーザーグループに依存します。
Active Directory ユーザーと IdM グループおよびポリシー

図5.4 Active Directory ユーザーと IdM グループおよびポリシー

Active Directory ユーザーは IdM ドメインには外部という位置付けになりますが、IdM にあるように 「Active Directory ユーザーと Identity Management グループ」 グループが外部グループとして設定されていれば、これらのユーザーは IdM グループのグループメンバーとして追加できます。この場合、 ドメインリソースにアクセスする際には、sudo、ホストベースのアクセス制御、および他のポリシーは外部 POSIX に適用され、最終的には AD ユーザーに適用されます。
チケットの PAC にあるユーザー SID は Active Directory アイデンティティーに対して解決されます。つまり、完全修飾ユーザー名または SID を使用して ユーザーをグループメンバーとして追加できることになります。

5.1.4. 一方向および双方向の信頼

IdM は IdM 内のサービスへの接続を確立できるエンティティーが AD に限定されるか、もしくは IdM エンティティーも含めることができるかによって、2 つのタイプの信頼関係をサポートします。
一方向の信頼
一方向の信頼では、AD ユーザーとグループは IdM 内のリソースにアクセスできますが、その逆は可能ではありません。IdM ドメインは AD フォレストを信頼しますが、AD フォレストは IdM ドメインを信頼しません。
一方向の信頼は、信頼の作成におけるデフォルトのモードです。
双方向の信頼
双方向の信頼では、AD ユーザーとグループは IdM 内のリソースにアクセスできます。IdM の双方向信頼では、AD における一方向の信頼ソリューションと比較した場合、ユーザーに新たな権限が与えられるわけではありません。デフォルトのフォレスト間信頼の フィルター設定により、両方のソリューションの安全性は同等なものと考えられます。
一方向および双方向の信頼に関する詳細情報は、「信頼関係のアーキテクチャー」 を参照してください。
信頼を確立した後は、タイプを修正することはできません。異なるタイプの信頼が必要な場合は、ipa trust-add コマンドを再度実行してください。これにより既存の信頼を削除し、新規の信頼を確立することができます。

5.1.5. Active Directory への外部の信頼

外部の信頼は、異なるフォレストにあるドメイン間の信頼関係です。フォレストの信頼は常に Active Directory フォレストの root ドメイン間の信頼確立を必要としますが、フォレスト内では外部の信頼をどのドメインに対しても確立できます。
外部の信頼は非推移的です。このため、他の Active Directory ドメインからのユーザーおよびグループには IdM リソースへのアクセスはありません。詳細は、「推移的および非推移的な信頼」 を参照してください。

5.1.6. 信頼コントローラーおよび信頼エージェント

IdM には、Active Directory に対する信頼をサポートする、以下のタイプの IdM サーバーがあります。
信頼エージェント
Active Directory ドメインコントローラーに対してアイデンティティー検索を実行可能な IdM サーバー
信頼コントローラー
Samba スイートも実行する信頼エージェントの機能を持つ IdM サーバー。Active Directory ドメインコントローラーは、Active Directory への信頼を確立し、検証する場合には信頼コントローラーに問い合わせます。
最初の信頼コントローラーは、「信頼向けに IdM サーバーを準備する」 で記載されているように信頼の設定時に作成されます。
信頼コントローラーは信頼エージェントと比較するとネットワークに接続されているサービスを多く実行するので、侵入者が攻撃できる範囲が大きくなります。
信頼エージェントとコントローラーに加え、IdM ドメインには、標準の IdM サーバーも含めることができます。ただし、これらのサーバーは Active Directory と通信しないので、標準のサーバーと通信するクライアントは、Active Directory ユーザーおよびグループを解決できず、Active Directory ユーザーを認証および許可することができません。

表5.1 信頼コントローラーおよび信頼エージェントが提供する機能の比較

機能信頼エージェント信頼コントローラー
Active Directory ユーザーとグループの解決はいはい
IdM クライアントを登録して、信頼済みの Active Directory フォレストからのユーザーがアクセスできるサービスを実行しますはいはい
信頼を管理します(たとえば、信頼合意の追加)いいえはい
信頼コントローラーと信頼エージェントのデプロイメントを計画する時に、以下のガイドラインを考慮してください。
  • 最低でもアイデンティティー管理のデプロイメントごとに、信頼コントローラーは 2 台設定してください。
  • 最低でも各データセンターごとに信頼コントローラーは 2 台設定してください。
追加の信頼コントローラーを作成する場合や、既存の信頼コントローラーが失敗した場合には、信頼エージェントまたは標準サーバーをプロモートして、新規信頼コントローラーを作成してください。これには、「信頼向けに IdM サーバーを準備する」 で記載されているように、IdMサーバーの ipa-adtrust-install ユーティリティーを使用してください。

重要

信頼エージェント上の既存の信頼コントローラーはダウングレードできません。

その他のリソース