Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

第5章 Active Directory および Identity Management を使用したフォレスト間の信頼作成

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

5.1. フォレスト間の信頼の概要

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

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

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

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

Kerberos レルム間の信頼は、Active Directory 環境間の認証で重要なロールを果たします。信頼される AD ドメインのユーザー名およびグループ名を解決するすべてのアクティビティーには、アクセスの実行方法に関係なく認証が必要です。LDAP プロトコルを使用するか、Server Message Block (SMB) プロトコルの上層にある Distributed Computing Environment/Remote Procedure Calls (DCE/RPC) の一部として認証する必要があります。2 つの異なる Active Directory ドメイン間でアクセスを編成するプロトコルが多いため、信頼関係にはより汎用的な名前 Active Directory 信頼 があります。
複数の AD ドメインは、1 つの Active Directory フォレスト にまとめることができます。このフォレストの root ドメインは、フォレスト内で作成される最初のドメインになります。Identity Management ドメインは既存の AD フォレストに含めることができないため、常に別個のフォレストとみなされます。
2 つのフォレストルートドメイン間で信頼関係が確立されると、異なる AD フォレストからのユーザーとサービスが通信できるように、Active Directory のフォレスト間の信頼 と呼ばれます。

信頼フローおよび一方向信頼

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

図5.1 一方向信頼

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

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

ドメインが別のドメインとその 2 番目のドメインによって信頼されている他のドメインを信頼するように、信頼は 推移的 である可能性があります。

図5.2 推移的な信頼

推移的な信頼
信頼は トランザクション以外のもの でもあるため、信頼は明示的に含まれるドメインのみに制限されます。

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

Active Directory フォレスト内では、ドメイン間の信頼関係は通常、デフォルトでは双方向で推移的です。
2 つの AD フォレスト間の信頼は 2 つのフォレストルートドメイン間の信頼であるため、双方向または一方向になります。フォレスト間の信頼の遷移は明示的なものです。フォレストのルートドメインを発生する AD フォレスト内のドメイン信頼は、フォレスト間の信頼を推移します。ただし、個別のフォレスト間の信頼は推移的ではありません。明示的なフォレスト間の信頼は、AD フォレストのルートドメイン間で、別の AD フォレストルートドメインに対して確立する必要があります。
AD の観点から観ると、Identity Management は、1 つの AD ドメインを持つ個別の AD フォレストを表します。AD フォレストの root ドメインと IdM ドメインとの間にフォレスト間の信頼が確立されると、AD フォレストドメインのユーザーは、IdM ドメインの Linux マシンおよびサービスと相互作用できます。

図5.3 信頼の方向

信頼の方向

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

Active Directory グローバルカタログ

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

グローバルカタログおよび POSIX 属性

Active Directory は、デフォルト設定で POSIX 属性を複製しません。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 でアイデンティティールックアップを実行し、承認のためにユーザーおよびグループのセキュリティー識別子 (SID) を取得します。SSSD は、ユーザー、グループ、およびユーザーのチケット情報をキャッシュし、Kerberos ドメインと DNS ドメインをマップします。
  • Identity Management (Linux ドメイン管理) は、Active Directory ユーザーを IdM ポリシーおよびアクセス用の IdM グループに関連付けます。
    注記
    SELinux、sudo、ホストベースのアクセス制御など、Linux ドメイン管理用のアクセス制御ルールおよびポリシーは、Identity Management で定義され、適用されます。Active Directory 側で設定されたアクセス制御ルールは、IdM によって評価または使用されません。関連する唯一の Active Directory 設定は、グループメンバーシップです。

さまざまな Active Directory フォレストとの信頼

IdM は、さまざまな AD フォレストとの信頼関係に含まれることもできます。信頼を確立したら、同じコマンドおよび手順に従って、他のフォレストを使用した追加の信頼を追加できます。IdM は、完全に関連性のない複数のフォレストを同時に信頼できるため、ユーザーは同じ共有 IdM ドメインのリソースに、関係のない AD フォレストによるリソースへのアクセスが可能になります。

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

Active Directory のグループ情報は、Privilege Attribute Certificate (MS-PAC または PAC) データセットの識別子一覧に保存されます。PAC には、グループメンバーシップや追加の認証情報情報などのさまざまな認可情報が含まれます。また、Active Directory ドメインにユーザーおよびグループの セキュリティー識別子 (SID) も含まれます。SID は、作成時に Active Directory ユーザーおよびグループに割り当てられた識別子です。信頼環境では、グループメンバーは名前または DN ではなく SID で識別されます。
PAC は、Windows ドメイン内の他の Windows クライアントおよびサーバーに対してエンティティーを識別する方法として、Active Directory ユーザーの Kerberos サービス要求チケットに組み込まれています。IdM は、PAC のグループ情報を Active Directory グループにマッピングしてから、対応する IdM グループにマッピングして、アクセスを決定します。
Active Directory ユーザーが IdM リソースのサービスのチケットを要求すると、プロセスは以下のようになります。
  1. サービスの要求には、ユーザーの PAC が含まれます。IdM Kerberos Distribution Centre (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 クライアントがグループメンバーシップを検出するために ID トラフィックを減らすことができます。
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 ユーザーおよびグループをすべて Identity Management グループに追加できます。
AD ユーザーに IdM グループを設定する方法は、「Active Directory ユーザーの IdM グループの作成」 を参照してください。

非 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 ユーザーが IdM の POSIX グループに属するグループの SID をマッピングします。AD 側の SID はユーザー名に関連付けられます。ユーザー名を使用して IdM リソースにアクセスする場合、IdM の SSSD はそのユーザー名を SID に解決し、「Active Directory PAC および IdM チケット」 で説明されているように、AD ドメインでその SID の情報を検索します。

ID 範囲

Linux でユーザーを作成すると、ユーザー ID 番号が割り当てられます。さらに、ユーザーにプライベートグループが作成されます。プライベートグループ ID 番号は、ユーザー ID 番号と同じです。Linux 環境では、競合を作成しません。ただし、Windows では、ドメインのすべてのオブジェクトに対して、セキュリティー ID 番号が一意でなければなりません。
信頼できる AD ユーザーには、Linux システムで UID および GID の番号が必要です。この UID および GID の番号を IdM で生成できますが、AD エントリーに UID と GID の番号がすでに割り当てられている場合は、異なる数値を割り当てると競合が作成されます。このような競合を回避するには、UID および GID の番号や推奨ログインシェルなど、AD 定義 POSIX 属性を使用できます。
注記
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 は、AD のグローバルカタログまたはディレクトリーコントローラーから、uidNumber および gidNumber を含む POSIX 属性を取得します。AD ドメインが正しく管理され、ID の競合なしに管理されている場合は、この方法で生成された 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、netgroup などの複数の IdM ポリシー定義が、ユーザーグループに依存してポリシーの適用方法を特定します。

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

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

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

IdM は、IdM でサービスへの接続を確立できるエンティティーが AD のみに制限されるか、または IdM エンティティーも含めるかどうかによって、2 種類の信頼関係がサポートされます。
一方向の信頼
一方向の信頼により、AD ユーザーおよびグループは IdM のリソースにアクセスできますが、その逆はできません。IdM ドメインは AD フォレストを信頼しますが、AD フォレストは IdM ドメインを信頼しません。
一方向の信頼は、信頼を作成するデフォルトのモードです。
双方向の信頼
双方向の信頼により、AD ユーザーおよびグループは IdM のリソースにアクセスできるようになります。信頼境界を使用して Kerberos プロトコルに S4U2Self および S4U2Proxy の Microsoft 拡張を必要とする、Microsoft SQL Server などのソリューションに、双方向の信頼を設定する必要があります。RHEL IdM ホスト上にあるアプリケーションは、AD ユーザーに関する S4U2Self または S4U2Proxy の情報を Active Directory ドメインコントローラーから要求する場合があり、双方向の信頼でこの機能が提供されます。
この双方向の信頼機能では、IdM ユーザーは Windows システムにログインできないだけでなく、IdM の双方向信頼では、AD の一方向信頼ソリューションと比較して、権限が追加でユーザーに付与されるわけではありません。
一方向および双方向の信頼に関する一般的な情報は、「信頼関係のアーキテクチャー」 を参照してください。
信頼を確立した後には、そのタイプを変更することができません。別の信頼タイプが必要な場合は、ipa trust-add コマンドを再度実行します。これを実行すると、既存の信頼を削除して、新しい信頼を確立できます。

5.1.5. Active Directory への外部信頼

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

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

IdM には、Active Directory への信頼をサポートする、次のタイプの IdM サーバーがあります。
信頼コントローラー
信頼を制御し、Active Directory ドメインコントローラー (DC) に対して ID 検索を実行できる IdM サーバー。Active Directory ドメインコントローラーは、Active Directory への信頼を確立して検証する際に信頼コントローラーに問い合わせます。信頼を設定すると、最初の信頼コントローラーが作成されます。
IdM サーバーを信頼コントローラーとして設定する方法は、「信頼の作成」 を参照してください。
信頼コントローラーは、信頼エージェントと比較して、ネットワークに直接接続するサービスの実行量が多いため、潜在的な侵入者に対してより大きな攻撃対象領域を提示します。
信頼エージェント
Active Directory ドメインコントローラーで ID 検索が実行可能な IdM サーバー。
IdM サーバーを信頼エージェントとして設定する方法は、「信頼用の IdM サーバーの準備」 を参照してください。
IdM ドメインには、信頼コントローラーおよびエージェントの他に、ロールなしでレプリカを含めることもできます。ただし、このサーバーは Active Directory と通信しません。したがって、これらのサーバーと通信するクライアントは、Active Directory ユーザーおよびグループを解決できず、Active Directory ユーザーを認証および認可することができません。

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

機能 信頼コントローラー 信頼エージェント
Active Directory のユーザーおよびグループの解決 はい はい
信頼された Active Directory フォレストのユーザーがアクセスできるサービスを実行する IdM クライアントを登録 はい はい
信頼の管理 (たとえば、信頼関係の追加) はい いいえ
信頼コントローラーと信頼エージェントのデプロイメントを計画する時に、以下のガイドラインを考慮してください。
  • Identity Management のデプロイメントごとに、信頼コントローラーを少なくとも 2 台は設定してください。
  • 各データセンターごとに、信頼コントローラーを少なくとも 2 台設定する。
追加の信頼コントローラーを作成する場合や、既存の信頼コントローラーが失敗した場合には、信頼エージェントまたはレプリカを昇格して、信頼コントローラーを新規作成してください。これには、「信頼用の IdM サーバーの準備」 の説明に従って、IdM サーバーの ipa-adtrust-install ユーティリティーを使用します。
重要
既存の信頼コントローラーを信頼エージェントにダウングレードすることはできません。インストール後は、信頼コントローラーサーバーのロールはトポロジーから削除できません。