Windows Server 2003 での連合フォレストの計画と実装

Microsoft Corporation

Windows Server 2003, Standard Edition、Windows Server 2003, Enterprise Edition、および Windows Server 2003, Datacenter Edition

謝辞
Karthik Jaganathan, Program Manager, Microsoft Corporation
Don Schmidt, Lead Program Manager, Microsoft Corporation

概要
Microsoft Windows Server 2003, Standard Edition、Windows Server 2003, Enterprise Edition、 または Windows Server 2003, Datacenter Edition を使用すると、2 つの Active Directory フォレストを連合して、 各フォレストの既存の認証や承認のインフラストラクチャを利用できます。 この資料では、企業管理者向けにテクニカル リファレンスを提供し、 複数の Windows Server 2003 フォレストの計画と実装方法、 および 2 つのフォレスト間でシームレスな認証や承認を可能にする方法について説明します。

*

トピック

はじめに はじめに

適用範囲 適用範囲

概要 概要

複数フォレストの展開事例 複数フォレストの展開事例

複数フォレストを連合するためのテクノロジ 複数フォレストを連合するためのテクノロジ

フォレストの信頼を展開する際の考慮点 フォレストの信頼を展開する際の考慮点

Windows Server 2003 で複数フォレストの事例を有効にする Windows Server 2003 で複数フォレストの事例を有効にする

ウォークスルー ウォークスルー

付録 A – ポートの一覧 付録 A – ポートの一覧

付録 B – この資料で使用する用語 付録 B – この資料で使用する用語

はじめに

Active Directory フォレストの概念が複数のバージョンの Microsoft Windows 2000 に導入されたことにより、 多くの組織が組織全体に渡って 1 つのフォレストを展開すると推測されていました。 ところが、多くの組織は複数のフォレストを展開しています。 そのため、さまざまな組織のフォレスト間で、コラボレーションが必要になっています。 このような場合、外部の信頼関係の確立に、膨大な管理が必要になります。 ただし、最新のテクノロジは使用しません。

複数フォレストの展開をより容易にするために、Windows Server 2003 にはフォレストの信頼の概念が導入されました。 管理者はこのフォレストの信頼を使用することにより、2 つの Active Directory フォレストを 1 つの信頼関係に連合して、 フォレスト間のシームレスな認証や承認を提供できます。 この資料では、フォレストの信頼を展開できる一般的な事例、 フォレストの信頼に関する基本的な概念、 および複数フォレストの展開を可能にする Windows Server 2003 に含まれるテクノロジについて説明します。

注意
この資料では、Windows Server 2003, Standard Edition、Windows Server 2003, Enterprise Edition、 および Windows Server 2003, Datacenter Edition に同梱されている機能について説明します。 これらの機能は、Windows Server 2003, Web Edition オペレーティング システムを実行しているコンピュータには含まれません。

ページのトップへ ページのトップへ

適用範囲

この資料の適用範囲は、 複数フォレスト間の認証、承認、および信頼の管理に関する概念に限定されます。 この資料は複数フォレストを展開する根本的な理由は説明していますが、 複数フォレストの展開を決定するためのガイドとなることは目的としていません。 また、この資料では、Microsoft Outlook® アドレス帳の連絡先または Microsoft Exchange Server のパブリック フォルダを同期する方法は説明していません。 ただし、 この資料では、Microsoft Metadirectory Services (MMS) や Exchange Server パブリック フォルダ レプリケーション ツールなど、 その他のテクノロジに関する情報を提供します。

ページのトップへ ページのトップへ

概要

Windows 2000 では、 それまでの Windows NT Server 4.0 ドメインを統合する Active Directory フォレストの概念を導入しました。 ドメインをフォレストに統合することにより、 フォレスト内のドメイン間の優れたコラボレーションを可能にします。 また、アプリケーションでもこのコラボレーションを使用できます。 たとえば、Exchange Server グローバル アドレス一覧を検索して、 フォレスト内の他のユーザーを特定でき、 その結果、さまざまな属性に基づいてメールを送信できるようになります。

この統合が導入されたとき、Windows NT Server 4.0 の多くの境界が消滅しました。 その結果、ドメインが完全に相互に分離されることはなくなりました。 ドメインは、相互依存するようになり、単一のフォレストに移動するには、 さまざまなドメインの管理者間で特定のレベルの同意と信頼が必要になりました。

信頼がこのレベルに到達できない場合に、 複数フォレストを展開する必要が生じます。 また、(合併や買収または企業間のコラボレーションなど) 複数のフォレストが既に展開されてしまっている事例もあります。 このため、組織間の信頼関係の複雑さ、 または信頼関係の欠如により、1 つのフォレスト環境に移動することが不可能になります。

Windows 2000 Server は、 複数フォレストの展開の事例に完全には対応していません。 管理者は認証を有効にするために、 あるフォレスト内のすべてのドメイン間の信頼関係を、 別のフォレスト内の他のすべてのドメイン間にセットアップする必要があります。 その結果、多くの場合信頼関係の管理が困難になります。 また、信頼の程度にも限度があります。 つまり、他のフォレスト内のすべてのユーザーを信頼できるか、 またはユーザーをまったく信頼しないと判断するかのいずれかになってしまいます。 企業間の事例ではより細やかなアプローチが必要になります。 つまり、他の企業からのユーザーの特定のセットだけを認証できるようにする必要があります。 また、企業間の信頼関係には、 ファイアウォールを介在させる必要があります。Windows 2000 の信頼は、 ファイアウォールが介在する際のサポートが制限されています。

Windows Server 2003 ファミリでは、 フォレストの信頼の概念が導入されました。 この概念により 2 つのフォレスト間の信頼が可能になるので、 各フォレスト内のすべてのドメインがその信頼関係の一部になります。 信頼の程度に関する問題を解決するには、[認証の選択] オプションを使用します。 この結果、特定のユーザーやユーザー セットだけをその信頼にまたがって認証できます。 また、管理者は特定のリモート プロシージャ コール (RPC) ポートを管理できるので、 ネットワーク ファイアウォールが介在する場合の信頼もより簡単に管理できます。 信頼を有効にするためには、RPC ポートを開く必要があります。

ページのトップへ ページのトップへ

複数フォレストの展開事例

さまざまな理由により、複数フォレストが必要になります。 リソースの所有者が政治的に分断されたり、 別の組織の管理インフラストラクチャを信頼できなかったり、 合併や買収が行われたり、 事業単位を地域的に分散したりなど、 さまざまなスキーマが必要になる場合があります。

複数フォレストの展開を必要とする理由は、一般的に 2 つあります。

  • 管理的な自立のために複数フォレストを展開する必要がある場合があります。 各部門は、(政治的またはセキュリティ上の理由により) 互いの管理者を信頼できず、(ディレクトリのスキーマおよび構成の) 一般的な変更管理ポリシーにも合意できません。

    - および -

  • 資産の分離のために複数フォレストを展開する必要がある場合があります。 合併や買収により巨大複合体となった行政機関および事業体は、 セキュリティまたは予算上の理由で、 場合によっては、 完全に個別のコンピュータ処理インフラストラクチャを維持することになります。 また、アプリケーション サービス プロバイダが、 大規模な企業顧客から委託を受け独立したインフラストラクチャを作成する場合があります。 「Design Considerations for Delegation of Administration in Active Directory」ホワイト ペーパーには、 複数フォレストを使用する理由が以下のように記載されています。

    Active Directory に格納されたデータや Active Directory に参加するコンピュータをディレクトリのサービス管理者から分離できないので、 組織が完全にデータを分離する唯一の方法として、独立したフォレストを作成します。

    https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx で Microsoft TechNet の 「Design Considerations for Delegation of Administration in Active Directory」ホワイト ペーパー (英語) を参照できます。

同一企業内の複数フォレスト

単一の企業内で好ましいアプローチは、1 つのフォレストを展開することです。 ただし、前のセクションに記載した理由により、 複数フォレストを展開する必要がある場合があります。 ほとんどの事例では、 専用回線または仮想プライベート ネットワーク (VPN) を使用してフォレストに接続する必要があります。 これにより、必要なデータ トラフィックがフォレスト間を流れることができます。 パケット フィルタやファイアウォールがある場合、 通常、これらは "すべてをトラフィックを許可して、 特定のトラフィックのみ明示的に拒否する" アプローチを使用します。 2 つのフォレストの管理者は同一人物の場合も別人の場合もありますが、 管理者は、管理者自身のフォレストからのユーザーを信頼するのと同じ方法で、 他のフォレストからのユーザーを信頼したいと考えるでしょう。

次の例を考えてみましょう。 Contoso, Inc. Corporation には 3 つのフォレスト (contoso.com、plant.contoso.com および hr.contoso.com) があります。 人事 (HR) 部には、スキーマの変更を必要とするプログラムがあるので、 独自のフォレストがあります。HR 組織の IT 部門は、 中央の IT 部門を経由せずにこれらの変更の管理を保持しようとします。 さらに、hr.contoso.com フォレストには、contoso.com フォレストが信頼関係から除外したいテスト ドメインがあります。

また、Fabrikam 製造工場では、Active Directory を使用するプログラムを実行する必要があります。 この事例では、ドメイン コントローラを製造工場に設置する必要があるので独立したフォレストが必要でした。 工場のすべての人がそのドメイン コントローラに物理的にアクセスします。

fedfin01

図 1: 同一企業内の複数のフォレスト

異なる企業内の複数フォレスト

各組織には、それぞれ独自のフォレストがあります。 ただし、企業間 (B2B) の事例では、 ある組織内のフォレストと別の組織のフォレスト間のコラボレーションが必要になります。 この事例では、この 2 つのフォレスト間で信頼関係を確立する必要もあります。 ただし、各フォレストの管理者は、 相手側のフォレストのユーザーが制限された一連のリソースのみにアクセスできるようにしたいと考えます。 2 つのフォレストは専用回線または VPN 接続で接続される可能性がありますが、 2 つのフォレスト間では限定されたトラフィックのみを許可します。 このため、通常、ファイアウォールは、 すべてのトラフィックを拒否して、 特定のトラフィックのみを明示的に許可する規則を持ちます。

この事例では、Contoso.com と Fabrikam.com が緊密に提携し、 歯磨き粉と歯ブラシを組み合わせた製品を共同で市場に出荷します。 ただし、両者は、多くのコラボレーションがマーケティングに関係しているので、 互いのプロジェクト ファイルへのアクセスを相手側のマーケティング チームに限定することを希望します。 両企業は、従業員に全体的な経過を意識させ続けるために、 内部ニュースに関する Web サイトを他社のすべての従業員に公開したいと考えます。

fedfin02

図 2: 異なる企業内の複数フォレスト

境界ネットワークの事例

組織は、境界ネットワーク (別名、DMZ、非武装地帯、およびスクリーンド サブネット) にリソースを公開する必要があるので、 Active Directory を必要とするプログラムを実行することがあります。 ただし、内部フォレストの独立したドメインを境界ネットワークに展開することはお勧めしません。 外部ドメインが危害を受ける場合に内部フォレスト全体に危害を与える単純な原因となるからです。 このため、ドメイン内の境界ネットワーク サーバーを管理する管理上およびセキュリティ上の利点をすべて得ようとする場合は、 境界ネットワーク内に独立したフォレストを展開する必要があります。

この事例では、contoso.com の管理者が dmz.contoso.com と呼ばれる独立したフォレストを所有します。 さらに、ユーザーがポータルにアクセスできるように、 境界ネットワークで実行される Microsoft .NET Passport 認証を使用する Web アプリケーションを所有します。 また、管理者は、 内部フォレストのユーザーが境界ネットワーク フォレストにリソースを公開できるようにします。 このため、内部フォレストのユーザーは、 内部フォレストのアカウントを使用して、 境界ネットワーク内のリソースにアクセスできる必要があります。

fedfin03

図 3: 境界ネットワークの事例

ページのトップへページのトップへ

複数フォレストを連合するためのテクノロジ

ここでは、 複数フォレストの展開に関する問題を解決するために、Windows Server 2003 に同梱されたテクノロジについて説明します。

フォレストの信頼

フォレストの信頼が、Windows Server 2003 の連合フォレストを可能にします。 フォレストの信頼は、2 つのフォレスト内のすべてのドメイン間の推移性の信頼を有効にします。 信頼は、両フォレストのルート ドメイン間で確立されます。 フォレストの信頼は、一方向または双方向の信頼になります。 図 4 では、Forest A と Forest B の間に双方向の信頼があります。 このため、Forest A のユーザーは Forest B のリソースを認証し、Forest B のユーザーは Forest A のリソースを認証できます。 信頼は認証に加えて、各フォレスト内のリソース所有者が、 他のフォレストからの随意性アクセス制御リスト (DACL) およびグループにプリンシパルを追加できるように、 承認も有効にします。

fedfin04

図 4: フォレストの信頼

フォレストの信頼の必要条件
フォレストの信頼を作成する前に、 両方のフォレスト内のすべてのドメイン コントローラが Windows Server 2003 を実行していることを確認する必要があります。 また、的確なドメイン ネーム システム (DNS) インフラストラクチャが適切な場所にあること、 および Active Directory に適切な機能レベルを確立していることを確認する必要もあります。 つまり、フォレストの機能レベルを Windows Server 2003 に上げる必要があり、 今後は Windows 2000 または Windows NT Server 4.0 のドメイン コントローラをフォレストに追加できないことを意味します。

フォレストの信頼を作成するには、Fabrikam および Contoso で信頼を作成するユーザーが、 対応するフォレスト内に Enterprise Admin 特権を持つ必要があります。 各信頼には、両方のフォレストの管理者が認識する必要があるパスワードが割り当てられます。 両方のフォレストの Enterprise Admin 特権を持つ管理者は、Fabrikam および Contoso に同時に信頼を作成できます。 この事例では、暗号化による任意のパスワードが自動的に生成され、 両方のフォレストに書き込まれます。

Windows NT Server 4.0 や Windows 2000 クライアントは共に、認証にフォレストの信頼を使用できます。 ただし、Windows NT Server 4.0 クライアントは、NTLM のみをサポートし、 ネットワークにログオンするためのユーザー プリンシパル名 (UPN) をサポートしません。

外部の信頼とフォレストの信頼
Windows 2000 では、 異なるフォレスト内の 2 つのドメイン間で信頼を有効にするために、 外部の信頼が使用されています。 フォレストの信頼は、2 つのフォレストのルート ドメイン間の外部の信頼に似ていますが、 その信頼をさらに発展させ、すべてのドメインに適用しています。 (外部の信頼およびフォレストの信頼に関する) 基本的な信頼情報は、 信頼されたドメイン オブジェクト (TDO) によって表現されます。 外部の信頼の TDO には、信頼を確立する他のドメインの名前、 そのドメインのセキュリティ識別子 (SID)、信頼の方向、信頼の種類、 およびその他の属性が含まれています。

フォレストの信頼が存在する場合、 その信頼は "Forest" とマークされます。 また、TDO には、新たに Forest Trust Information 属性も含まれています。 Forest Trust Information 属性には、 リモート フォレスト内のすべてのドメイン、ツリー名、 および代替名サフィックスに関する情報が含まれています。 この情報を使用し、必要に応じて、リモート フォレストの認証および参照を変更します。 この情報は、任意のドメイン コントローラが参照できるように、グローバル カタログに反映されます。 TDO は、Active Directory に存在するドメイン コントローラに格納されます。

ツリー名および代替名サフィックスは、TLN (TopLevelName) レコードに格納されます。 すべてのドメインの DNS 名、ネットワーク基本入出力システム (NetBIOS) 名、 および SID は、DomainInfo レコードに格納されます。 このため、フォレストの信頼には、 他のフォレストに存在可能なサービスまたはユーザーを合理的に判断するのに十分な情報が含まれています。

次の表では、外部の信頼とフォレストの信頼との主な相違点を示しています。

1 外部の信頼とフォレストの信頼

  外部の信頼 フォレストの信頼

TDO

最上位レベルの名前

DomainInfo (すべてのドメイン用)

Kerberos V5 サポート

制限付きサポート

オブジェクトピッカーの表示

NTLM サポート

UPN ログオン

暗黙の UPN のみ

暗黙の UPN および明示的な UPN

Kerberos 認証のルーティング
フォレストの信頼を確立した後、Kerberos および NTLM 認証は、 ユーザー資格情報を検証できるように、 結果的に他のフォレストにルーティングされます。

Kerberos では、 ユーザーがコンピュータにログオンするときに Ticket Granting Ticket (TGT) を取得します。 リソースに対してユーザーを認証する必要がある場合、TGT がドメイン コントローラに提示され、 ドメイン コントローラが認証すべきサービス チケットを返します。 この処理は、Kerberos チケット保証サービス (TGS) 要求により実行されます。 リソースが別のドメインに存在する場合、 そのユーザーのドメイン コントローラはサービス チケットを発行できません。 代わりに、そのユーザーのドメイン コントローラは、 リソース ドメイン コントローラとの間に直接的な信頼関係がある場合は、 ユーザーがリソース ドメイン コントローラにアクセスするための紹介を発行します。 直接的な信頼関係がない場合は、 ドメイン コントローラは、信頼チェーン内の次のドメイン コントローラに紹介を発行します。 最終的にリソース ドメイン コントローラがユーザーにサービス チケットを発行します。 リソースが同じフォレスト内にある場合、 そのユーザーのドメイン コントローラは、 グローバル カタログを調べて、 リソースが同じフォレスト内に存在するかどうか確認できます。

フォレストの信頼によって接続されている別のフォレストにリソースが存在する場合、 グローバル カタログに別のフォレスト内のすべてのリソースの情報が含まれているわけではありません。 ただし、グローバル カタログは、 すべてのフォレスト TDO に関するフォレストの信頼情報を検索することにより、 このリソースを含むフォレストを判断できます。 情報を判断した後、紹介が発行されるので、 ユーザーはローカル フォレスト ルートに到達します。 その後、ローカル フォレスト ルートが、 信頼する側のフォレストのルートに対してユーザーを紹介します。 信頼する側のフォレストに紹介が到達すると、 ユーザーが正式にリソース ドメイン コントローラに紹介され、 サービス チケットを取得します。

信頼される側のフォレストのユーザーが信頼する側のフォレストのコンピュータにログオンしている場合、 Kerberos 認証サービス (AS) 要求が同じようにルーティングされます。 ただし、この場合、ユーザーは信頼パス内のすべてのドメインをスキャンする必要がなくなります。 代わりに、ユーザーは、 ルート ドメイン、および他のフォレスト内のユーザーのアカウントを含むドメイン コントローラに直接紹介されます。

fedfin05

図 5: 他のフォレストに対する認証プロセス

図 5 では、クライアントが Kerberos を使用して、 他のフォレスト内のサービスを認証する方法を示しています。

  1. クライアントはドメイン コントローラ (DC1) に接続して、 サービスを使用するためにサービス チケットを要求します。
  2. ドメイン コントローラは、 そのドメイン内にサービスが見つからないので、 グローバル カタログを調べます。 フォレストの信頼情報を検証した後、 グローバル カタログはサービスがおそらく別のフォレストに存在するというヒントを送信し、 ドメイン コントローラはその親に紹介を発行します。
  3. クライアントはドメイン コントローラ (DC2) に接続して、 サービスを使用するためにサービス チケットを要求します。 ルート ドメイン コントローラ (DC2) は、 他のドメインのルート ドメイン コントローラ (DC3) への紹介をクライアントに送信します。
  4. クライアントは、 他のフォレスト内のルート ドメイン コントローラ (DC3) に接続して、 サービスを使用するためにサービス チケットを要求します。 この例では、ルート ドメイン コントローラ (DC3) は、 独自のフォレストでグローバル カタログにクエリして、 そのフォレスト内にサービスが存在することを判断します。 ルート ドメイン コントローラ (DC3) では、 信頼パスの次のドメイン コントローラ (DC4) にクライアントを紹介します。
  5. クライアントは、 紹介されたドメイン コントローラ (DC4) (サービス ドメイン コントローラ) に接続して、 サービス チケットを要求します。 このドメイン コントローラは、サービスがそのドメイン内にあると判断するので、 クライアントにサービス チケットを発行します。
  6. クライアントは、 このサービス チケットを Kerberos KERB_AP_REQ メッセージでサーバーに提示します。 サーバーがこれに応答し、 セキュリティで保護された通信チャンネルを確立します。

オブジェクトピッカーツールの機能
オブジェクト ピッカー コマンド ライン ツールを使用して、 リソース上の DACL に、他のグループのメンバとして、 ユーザーまたはグループを追加できます。 たとえば、信頼する側のフォレストの管理者が、 信頼される側のフォレストのユーザーを信頼する側のフォレストに追加する場合、 管理者は Active Directory ユーザーとコンピュータ Microsoft 管理コンソール (MMC) スナップインを起動して、 必要なグループをクリックし、[メンバの追加] をクリックします。 オブジェクト ピッカー ツールでは、管理者にリモート フォレストのユーザーの名前を入力するように指示が表示されます。 オブジェクト ピッカーは、最初に、ユーザーが存在するドメインの検索を試みます。 ユーザーが別のフォレストから来ているので、 ローカル グローバル カタログはそのフォレスト内にユーザー名を見つけることはできません。 グローバル カタログは、フォレストの信頼情報を検証して、 要求されたオブジェクトが別のフォレスト内に存在するかどうか判断します。 オブジェクトが異なるフォレストに存在する可能がある場合、 他のフォレストのグローバル カタログに接続するために、 紹介がオブジェクト ピッカーに送信されます。 オブジェクト ピッカー ツールは、 リモート フォレストのグローバル カタログに接続して、 リモート フォレストのドメインがクエリされたオブジェクトを保持するかどうかを正式に判断します。 この判断により、オブジェクト ピッカーはそのドメイン内のドメイン コントローラに接続します。 その後、LDAP (Lightweight Directory Access Protocol) による検索を実行して、 そのセキュリティ識別子 (SID) など、 特定のオブジェクトの属性を取得します。 この情報を取得した後、DACL の設定、またはグループ メンバシップの変更を行うことができます。

信頼される側のフォレストからオブジェクトを選択する際のオブジェクト ピッカーによるサポートは、 Microsoft Windows XP オペレーティング システム、 または Windows XP 以降にリリースされたオペレーティング システムを実行しているコンピュータ上で利用できます。 オブジェクト ピッカーを使用して、 信頼される側のフォレストからオブジェクトを選択する場合、 ユーザーまたはグループの完全な UPN を入力する必要があることに注意してください。 検索にワイルドカード文字を使用可能にするオブジェクト ピッカーは、 Windows Server 2003 を実行しているコンピュータ上で利用できます。

リモート フォレストからユーザーを照合する場合は、 リモート フォレストに資格情報が必要なことに注意してください。 双方向の信頼関係がある場合、 リモート フォレストはローカル フォレストも信頼するので、 既定のローカル フォレストの資格情報を使用します。 ローカル フォレストがリモート フォレストのみを信頼する場合、 ローカル フォレストのユーザーは、 オブジェクト ピッカー ツールによってリモート フォレストの資格情報を要求されます。

注意
グループ メンバシップの規則により、 ユニバーサル グループとグローバル グループのどちらにも別のフォレストのメンバを含めないようにします。

Active Directory に関する推奨事例では、 各ドメインがそのドメインのユーザーを含むグローバル グループを持ち、 このようなグローバル グループをリソース ドメイン内のドメイン ローカル グループに追加します。

SID のフィルタ処理
認証要求が信頼される側のフォレストから送信されたとき、 そのフォレストを信頼して、 ユーザーの資格情報を正しく検証されます。 ただし、認証要求と一緒に、 セキュリティ識別子 (SID) の一覧の形式で承認情報も受信します。 すべての SID が信頼する側のフォレストの Enterprise Administrator の SID (または同様の特権を持つグループまたはユーザーの SID) に一致する場合、 信頼される側のフォレストのユーザーは、リソースに対する高い権限を取得します。 信頼される側のフォレストが偽の SID を割り当てる可能性を回避するには、 オペレーティング システムが常に SID のフィルタ処理を行い、 その SID が信頼される側のフォレストのドメイン SID のいずれかに関連していることを確認します。 この方法では、 信頼される側のフォレストが権威のあるドメインに関する承認情報のみを公開することを確認します。 たとえば、fabrikam.com フォレストのルート ドメインのドメイン コントローラは、 クライアントから要求を受信すると、 要求の SID をフィルタ処理して、 クライアントが承認されていない SID を渡していないことを確認します (図 5 の手順 4 を参照してください)。SID のフィルタ処理は、 フォレストの信頼上で自動的に有効になります。

SID フィルタ処理は、 フォレスト間の SID の履歴を破棄します。 fabrikam.com フォレストのユーザーが contoso.com フォレストに移行すると、 ユーザーの contoso.com アカウントの SID の履歴には、 そのユーザーの fabrikam.com フォレスト内のユーザー アカウントの SID が含まれます。 ユーザーが独自の contoso.com アカウントを使用して、fabrikam.com フォレストにあるリソースにアクセスしようとすると、 fabrikam.com アカウント SID が contoso.com の SID と一緒に表示されます。 fabrikam.com のルート ドメインのドメイン コントローラは、 ユーザーが提示する fabrikam.com アカウント SID が承認されず、 contoso.com のユーザー アカウントで提示されると判断して、 このアカウント SID をフィルタ処理します。 ユーザーは自分の以前のリソースにアクセスできないので、 この操作を行うと、SID 履歴が破棄されます。

信頼されたフォレストの管理者が、 承認されていない SID になりすましていないことを信頼できる場合、 SID のフィルタ処理を無効にすると、SID の履歴を有効にできます。 この操作を行うには、Windows Server 2003 サポート ツールに同梱されている Netdom ツール (Netdom.exe) を使用します。 Windows Server 2003 CD-ROM 上の Support\Tools フォルダから Windows Server 2003 サポート ツールをインストールできます。 この操作を行うには、Support\Tools フォルダの [Suptools.msi] ファイルを右クリックして、[インストール] をクリックします。

SID フィルタ処理および SID のなりすましの詳細については、 https://support.microsoft.com を参照してください。

認証の選択

[認証の選択] オプションは、 概念上、機能する方法の点でネットワーク ファイアウォールに似ています。 ネットワーク ファイアウォールが、 ファイアウォール経由で特定のネットワーク アクセス要求のみを許可するのと同様に、 [認証の選択] オプションは特定の認証要求のみを許可します。 [認証の選択] オプションを有効にする方法の詳細については、 この資料の「ウォークスルー」を参照してください。

信頼の程度に関する問題
ユーザーが信頼される側のフォレストから認証されると、 トークンに Authenticated Users SID を受信します。 フォレストのユーザーの既定の権利の多くは、Authenticated Users SID を使用して許可されます。 Authenticated Users グループはコンピュータ処理されたグループで、 その SID はユーザーが認証するサーバーに追加されるので、 グループのメンバシップは変更できません。 このため、他のフォレストのユーザーは、 フォレストの信頼をセットアップした後、Authenticated Users グループがアクセス可能な信頼する側のフォレスト内のすべてのリソースへの既定の権利を取得します。 信頼される側のフォレストに存在する一部のユーザーへのアクセスを許可するためだけに信頼をセットアップする場合は、 この操作を行わない場合があります。

解決策
[認証の選択] オプションは、 信頼の境界を超えて行われる認証要求のより細やかな制御を実現するために使用できる方法を提供します。 [認証の選択] オプションを有効にすると、 すべての認証がサービス ドメイン コントローラ上で検証されます。 サービス ドメイン コントローラは、 そのユーザーがリソースの認証を明示的に許可されていることを確認してから、 認証要求を許可します。 このため、信頼の境界を超えて [認証の選択] オプションを有効にするときは、 信頼の境界を超えてドメインのリソースを認証できるユーザーを指定する必要があります。 他のフォレストまたはドメインからその特定のユーザーまたはグループのオブジェクトに "認証を許可" コントロール アクセス権をセットアップすると、 この操作を実行できます。 [認証の選択] オプションが有効になった信頼でユーザーが認証されると、 特別な "Other Organization" SID がユーザーの認証データに追加されます。 この SID が存在する場合、サービス ドメイン上で検証が行われ、 ユーザーが特定のサービスを認証できることを確認します。 ユーザーが認証されると、 ユーザーが認証するサーバーは、 もう 1 つの SID である "This Organization" SID を追加します ("Other Organization" SID が存在しない場合に、"This Organization" SID が追加されます)。 たとえば、ユーザーは [認証の選択] オプションが有効になった信頼で認証を行わなかった場合、 "This Organization" トークンのみが存在します。 このため、これらの特別な SID のうちの 1 つだけが、 認証済みのユーザーのコンテキストに存在できます。

信頼ポートの構成

信頼は、さまざまなネットワーク境界を超えて展開される必要があります。 このため、信頼は 1 つ以上のファイアウォールにまたがる必要がある場合があります。 この場合、ファイアウォールでトラフィックをトンネル処理するか、 またはファイアウォール内の特定のポートを開いて、 信頼のトラフィックが通過することを許可できます。 Windows Server 2003 では、主な信頼サービス用の構成可能なリモート プロシージャ コール (RPC) を使用して、 この方法を簡単にします。2 つの主な構成可能な RPC ポートは以下のとおりです。

  • ローカル セキュリティ機関 (LSA) RPC ポート。 このポートは、信頼の作成、および他の LSA ポリシー データベースへのアクセスに使用します。 このポートは HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters レジストリ キーの TCP/IP Port エントリです。

    - および -

  • Netlogon RPC ポート。 このポートは、NTLM およびセキュリティで保護されたチャンネルに使用します。 このポートは、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters レジストリ キーの DCTcpipPort エントリです。

    さまざまな事例用に開くことができるポートの詳細を参照するには、 この資料の「付録 A : ポートの一覧」を参照してください。

ページのトップへ ページのトップへ

フォレストの信頼を展開する際の考慮点

ここでは、 フォレストの信頼を展開するときに留意すべきさまざまな考慮点と推奨事例について説明します。

UPN の考慮点

フォレストの信頼を展開するときに、 複数フォレスト間で明示的な UPN サフィックスを使用できます。 外部の信頼を持つ複数フォレスト間では、 明示的な UPN サフィックスを使用できません。 管理者は、明示的な UPN サフィックスを使用する場合、 フォレスト間の UPN 構造を慎重に計画する必要があります。 フォレスト間の UPN サフィックスは一意である必要があるので、 重複させないでください。

plant.contoso.com や contoso.com のような重複する UPN サフィックスを使用できますが、 この場合 TopLevelName 除外 (TLNEx) レコードも使用する必要があります。 これは、contoso.com の TopLevelName レコード (信頼される側のフォレストまたは信頼する側のフォレストの UPN サフィックスおよびツリー名を、 TopLevelName レコードとしてローカル フォレストに格納します) が、 contoso.com の下にあるすべての名前空間 (plant.contoso.com など) を申告するためです。 このため、 名前に対する要求をルーティングする場所 (server.plant.contoso.com など) に関して不一致が生じます。 この要求を適切なフォレストに確実にルーティングするために、 contoso.com への信頼を所有するすべてのフォレストは、 plant.contoso.com の TopLevelName 除外レコードをその信頼に追加する必要があります。 TopLevelName 除外レコードは、plant.contoso.com の下にある名前の要求がそのフォレストにルーティングされないことを指定します。 TopLevelName 除外レコードは新たなレベルの複雑性を追加するので、 管理者は重複しない UPN サフィックスを選択することをお勧めします。

2 つのフォレストが共に contoso.com を申告するなどの共有 UPN サフィックスは、 フォレストの信頼を使用する場合には許可されません。 フォレストのログインに共有 UPN サフィックスのみを使用したいと考える管理者 (ユーザーは、アカウントが存在するのと同じフォレストにログインするために UPN サフィックスのみを使用できます) は、 そのフォレストにまたがるサフィックスの定義を削除して、 ユーザー オブジェクト上の UPN 属性のみを定義する必要があります。 つまり、Active Directory ユーザーとコンピュータ MMC スナップインのユーザー インターフェイス (UI) を使用して、 User オブジェクト上で UPN サフィックスを設定することはできません。 このため、プログラムを作成してユーザー オブジェクトに属性を記述する必要があります。 Active Directory ユーザーとコンピュータ MMC スナップインを使用して、 フォレストで UPN サフィックスの定義を削除すると、 その UPN サフィックスは、サフィックスを共有する別のフォレストに反映されないので、 結果的に競合は生じません (競合は、2 つのフォレストが同一の TLN を要求する場合に生じることに注意してください)。 競合が発生すると、 フォレストの信頼は無効になります。 2 つのフォレストが同じ名前空間を申告する場合 (たとえば、2 つのフォレストが共に contoso.com を申告する場合) は、 除外レコードを設定できないことに注意してください。 この方法では、共有 UPN を使用して、フォレストの境界を超えてログオンすることはできません。 このため、別のフォレスト (ユーザー アカウントが存在するフォレスト以外のフォレスト) 内のコンピュータへのログオンが最も少ない場合のみ、 この方法を使用する必要があります。 共有の UPN を使用して、メンバであるフォレストのコンピュータにログオンすると、 別のフォレストのリソースにシームレスにアクセスできることに注意してください。

フォレストの信頼の範囲を制限する際の考慮点

信頼される側のフォレストからそのフォレストにアクセスできるユーザーを制限する際に使用できる方法は 2 つあります。

  • ドメインに対応する DomainInfo レコード、 または UI ツリーの TopLevelName レコードを無効にできます。 この方法は、他のフォレストの小さな部分が信頼されていない場合のみ役に立ちます。 DomainInfo レコードを無効にすると、 そのドメインのユーザーから認証要求のみが無効になることに注意してください。 DomainInfo レコードを無効にすると、 ローカル フォレスト内のユーザーが無効なドメインのリソースにアクセスしようとして、 認証要求を受け取る場合、認証要求は無効になりません。

    - または -

  • [認証の選択] オプションを使用できます。 このオプションは、少数のユーザーにアクセスを許可する場合のみ役に立ちます。 数多くのユーザーが多数のリソースにアクセスしようとしていると、 要求を管理して、"認証を許可" 権限をユーザーに与えることが難しくなります。 Active Directory 内のリソース オブジェクトへの Write_DAC アクセス許可を所有するユーザーのみがこのアクセス許可を設定できることに注意してください。 このアクセス許可は、 オブジェクトを作成した Domain Admins および委任された管理者両方に制限されています。 ユーザーが "ワークステーションをドメインに追加する" 特権を使用してコンピュータをドメインに参加させると、 Write_DAC アクセス許可を取得せず、 そのため、そのユーザーが参加したコンピュータ上で他のフォレストのユーザーに "認証の許可" 権限を許可できないことに注意してください。

スマート カード ログオンの考慮点

スマート カード ログオンをフォレスト間で使用するには、 ユーザーは公開キー基盤 (PKI) の信頼およびフォレストの信頼が必要になります。 つまり、ユーザーがログオンしているフォレストは、 ユーザーのスマート カード ログオン用のスマート カード証明書を発行した証明機関 (CA) を信頼する必要があります。 さらに、ユーザーがログオンしているコンピュータは、 サーバー認証のために、 ユーザーのドメインのドメイン コントローラ用のコンピュータ証明書を信頼する必要があります。 CA を信頼済みのルート CA に設定するか、 または限定従属のいずれかによって、この操作を実行できます。

外部の信頼からフォレストの信頼に移動する際のユーザー操作の変更
フォレストの信頼に移動した後、ユーザー操作に特定の変更が必要になる場合があります。 このような変更を最低限に抑え、 一貫性のある操作になることを保証するには、 Windows XP、Windows 2000、 または Windows NT Server 4.0 を実行しているコンピュータで最新の Service Pack にアップグレードします。 また、適切な QFE を適用する必要がある場合もあります。 次の一覧で、Service Pack および QFE の影響について説明します。

  • Windows ログオンと認証。 ユーザーが、ユーザー アカウントが存在するフォレスト以外のフォレストに参加するコンピュータにログオンするときに、 ログオン ダイアログ ボックスにそのアカウント ドメインが一覧されません。 ユーザーは、そのダイアログ ボックスにユーザー プリンシパル名 (UPN) を入力する必要があります。 これは、暗黙の UPN サフィックス (user_ID@DNS_domain_name.com)、 または管理者が明示的に定義する UPN サフィックス (someone@fabrikam.com など) になります。 Windows NT Server 4.0 スタイルの名前でログオンする場合は、 対応する QFE をコンピュータに適用する必要があります。 他のフォレストのドメインがログオン ボックスに表示されないことに注意してください。 ログオン ボックスに domain\user と名前を入力する必要があります。 ユーザーが現在 UPN を使用してログオンしていない場合、 Windows NT Server 4.0 スタイルの名前を使用すると、 ユーザーのログオン操作が一貫性のあるものになります。
  • 承認。Windows Server 2003 または Windows XP Service Pack 2 (SP2) のどちらも実行していないコンピュータでは、 別のフォレストのプリンシパルを参照して、DACL やグループにそのプリンシパルを追加できません。 代わりに、別のフォレストのプリンシパルの UPN または Windows NT Server 4.0 の名前を入力できます。 Windows Server 2003 または Windows XP SP2 のいずれかを実行しているコンピュータでは、 他のフォレスト内のプリンシパルを参照および検索できます。 Windows 2000 Service Pack 4 (または以下に指定する QFE)、 または Windows XP のいずれかを実行して、UPN 名または Windows NT Server 4.0 の名前を使用することにより、 他のフォレスト内のオブジェクト ピッカー ツールでプリンシパルを解決する必要があります。 Windows NT Server 4.0 を実行しているコンピュータでは、 他のフォレストに存在するユーザーの Windows NT Server 4.0 スタイルの名前を入力できます。 Windows 95、Windows 98、または Windows Millennium Edition (Me) を実行しているコンピュータでは、 ユーザーを参照するドメインを選択できます。 その後、そのユーザーを選択できます。Microsoft Exchange Server 5.5 管理者および Microsoft SQL Server™ 2000 管理者は、 ユーザーを追加して、メールボックスに関連付け、SQL Server ログオンを有効にできるように、 Windows ユーザーを選択するときに、 Windows NT Server 4.0 スタイルの名前を明示的に入力する必要があります。 他のフォレストに存在するユーザーを参照できないことに注意してください。

次の表では、 外部の信頼からフォレストの信頼に移動する場合の一般的なユーザー側の操作について説明します。

ログオンと認証

  Windows 95、Windows 98、Windows Me Windows NT Server 4.0 Windows 2000 Windows XP Windows Server 2003

ログオンボックス

変更なし

Windows NT Server 4.0 スタイルの名前を有効にする QFE を追加する

UPN 名でログオンして、Windows NT Server 4.0 スタイルの名前を有効にする QEF を追加する

UPN 名でログオンして、Windows NT Server 4.0 スタイルの名前を有効にする QEF を追加する

UPN 名でログオンして、Windows NT Server 4.0 スタイルの名前を有効にする QEF を追加する

共有 (UI)

変更なし

変更なし

変更なし

変更なし

変更なし

共有 (コマンドプロンプト)

変更なし

変更なし

変更なし

変更なし

変更なし

Microsoft Internet Explorer

変更なし

変更なし

変更なし

変更なし

変更なし

Outlook

変更なし

変更なし

変更なし

変更なし

変更なし

Microsoft Internet Information Server (IIS)

利用不可

変更なし

変更なし

利用不可

変更なし

Exchange Server 5.5

利用不可

変更なし

変更なし

利用不可

利用不可

Exchange 2000 Server

利用不可

利用不可

変更なし

利用不可

利用不可

Microsoft Exchange Titanium

利用不可

利用不可

変更なし

利用不可

変更なし

信頼済みフォレストのドメイン DFS

利用不可

利用不可

利用不可

利用不可

変更なし

SharePoint™Team Services from Microsoft 1.0

利用不可

利用不可

変更なし

利用不可

変更なし

Microsoft SharePoint Portal Server 2001

利用不可

利用不可

変更なし

利用不可

変更なし

Microsoft SQL Server 7.0

利用不可

変更なし

変更なし

利用不可

利用不可

SQL Server 2000

利用不可

変更なし

変更なし

利用不可

変更なし

グループポリシー

利用不可

利用不可

変更なし

変更なし

変更なし

参照と承認

  Windows 95、Windows 98、Windows Me Windows NT Server 4.0 Windows 2000 Windows XP Windows Server 2003

オブジェクトピッカーツール

利用不可

変更なし

最新の Service Pack にアップグレードして、 最新の QFE を適用します。 その後、UPN または Windows NT Server 4.0 の名前を入力します。

UPN または Windows NT Server 4.0 の名前を入力し、SP2 にアップグレードして、参照します。

変更なし

共有 (UI)

ユーザーを選択できるドメインを変更する必要があります。

変更なし

変更なし

変更なし

変更なし

共有 (コマンドプロンプト)

利用不可

変更なし

変更なし

変更なし

変更なし

IIS

利用不可

変更なし

変更なし

利用不可

変更なし

Exchange Server 5.5

利用不可

名前を入力する必要がある

名前を入力する必要がある

利用不可

利用不可

Exchange 2000 Server

利用不可

利用不可

変更なし

利用不可

利用不可

Exchange Titanium

利用不可

利用不可

変更なし

利用不可

変更なし

SharePoint™Team Services from Microsoft 1.0

利用不可

適用なし

変更なし

利用不可

変更なし

SharePoint Portal Server 2001

利用不可

適用なし

最新の Service Pack にアップグレードして最新の QFE を適用する場合、 または SharePoint Portal Server QFE を適用する場合は変更なし

利用不可

変更なし

SQL Server 7.0

利用不可

変更なし

変更なし

利用不可

利用不可

SQL Server 2000

利用不可

名前を入力する必要がある

名前を入力する必要がある

利用不可

変更なし

ページのトップへページのトップへ

Windows Server 2003 で複数フォレストの事例を有効にする

前のセクションで説明した Windows Server 2003 のテクノロジはそれぞれ、 複数フォレスト間の特定の機能を有効にするのに役立ちます。 このようなテクノロジは信頼の管理、認証、 および承認の問題に限定されることに注意してください。

他のテクノロジやツールを使用して、 アドレス帳の同期、 ユーザーの移行、DNS 構成など、その他の問題に対処する必要があります。 次のセクションでは、 この資料で説明する各テクノロジを使用して、 先に説明した複数フォレストの事例を有効にする方法について説明します。 また、その他の問題の対処に使用する必要があるその他のツールも説明します。

同一企業内の複数フォレスト

同一企業内に複数フォレストを展開する場合は、 最初に、あるフォレストから DNS 参照を実行して、 他のフォレストのドメイン コントローラを参照できるようにする必要があります。 フォレストが既に同じ DNS インフラストラクチャを使用している場合、 追加の作業を行う必要はありません。 フォレストが同じ DNS インフラストラクチャを使用していない場合、 DNS インフラストラクチャをマージするか、 条件付き転送を使用できます。 詳細については、Microsoft Web サイトの https://www.microsoft.com/downloads/details.aspx?FamilyID=aabff84b-0f21-4553-a0a5-6946eb074dd7で『Multiple Forest Considerations』デザイン ガイド (英語) を参照してください。

DNS を構成した後、contoso.com フォレストと hr.contoso.com フォレストの間で双方向の信頼をセットアップします。 plant.contoso.com には他のフォレストのリソースにアクセスするために必要なユーザー アカウントが含まれていないので、 管理者は、他の各フォレストに対して一方向の信頼をセットアップします。 この事例では、[認証の選択] オプションを有効にする必要はありません。 これは、 他のフォレストのリソースにアクセスする必要がある多くのユーザーが各フォレストに存在すること、 および各フォレストの管理者が他のフォレストに存在するユーザーを認証済みのユーザーとして抵抗なく扱えるためです。 さらに、contoso.com フォレストのユーザーは、 電子メール メッセージの送信に Exchange Server アドレス帳を使用する場合に、 hr.contoso.com フォレストのユーザーを参照できます。 この操作を行うには、Microsoft Metadirectory Services (MMS) を使用して、 両方のフォレストのアドレス帳を同期します。 MMS の詳細については、Microsoft Web サイトの https://www.microsoft.com/downloads/details.aspx?FamilyID=aabff84b-0f21-4553-a0a5-6946eb074dd7で『Multiple Forest Considerations』デザイン ガイド (英語) を参照してください。

hr.contoso.com フォレストは plant.contoso.com TopLevelName の plant.contoso.com フォレストを信頼し、 hr.contoso.com フォレストも contoso.com TopLevelName の contoso.com フォレストを信頼します。 このため、contoso.com の TopLevelName レコードにも plant.contoso.com が含まれるので、 名前空間の競合が発生します。 この競合を取り除くには、contoso.com フォレストの信頼から plant.contoso.com 名前空間を除外する必要があります。 この操作を行うには、contoso.com への信頼のために hr.contoso.com フォレストの FTInfo レコードに TopLevelName 除外レコードを設定します。 同様に、plant.contoso.com フォレストで別の除外レコードをセットアップして、 contoso.com フォレストへの信頼から hr.contoso.com 名前空間を除外する必要があります。 ただし、plant.contoso.com および hr.contoso.com 名前空間は重複しないので、 contoso.com で除外レコードをセットアップする必要はありません。

さらに、contoso.com フォレストの管理者は、hr.contoso.com フォレストのテスト ドメインである test.hr.contoso.com ドメインを信頼しません。 このため、管理者は、hr.contoso.com の信頼レコードにある test.hr.contoso.com ドメインの DomainInfo レコードを無効にできます。 この操作を行うと、test.hr.contoso.com ドメインが実行する認証は contoso.com によって受け入れられなくなります。 この事例の [認証の選択] オプションではなく、 フォレストの信頼にある [明示的な拒否] オプションを使用するほうが簡単であることに注意してください。 これは、信頼する側のフォレストの任意のリソースに対して、 信頼される側のフォレストの特定のドメイン内のすべてのプリンシパルの認証を防ぐためです。 信頼される側のフォレストに存在する特定のドメインの DomainInfo レコードを無効にするときに、 ドメインのユーザーによる認証要求も無効にすることに注意してください。 この操作を行うと、そのドメイン内のリソースに対する認証は無効になりません。

fedfin06

図 6: 同一企業内の複数フォレスト — 展開

異なる企業間の複数フォレスト

異なる企業間に複数フォレストを展開しようとするときは、 独特な課題が発生します。 信頼はファイアウォールをまたがるだけではなく、 すべてのリソースが適切に管理されていることを保証する必要があるので、 別のフォレストのユーザーが、見えないはずのリソースに誤ってアクセスすることはありません。

この事例では、Fabrikam および Contoso がフォレストの信頼を確立します。 各企業は、[認証の選択] オプションも有効にします。 管理者が [認証の選択] オプションを有効にすると、 信頼をの境界を超えて行われる認証は自動的に機能しません。 管理者は、信頼間で認証を明示的に有効にする必要があります。 Contoso フォレストの管理者は、 マーケティング グループのファイル サーバー コンピュータ アカウントに DACL を設定して、 Fabrikam フォレストのマーケティング グループのメンバがその DACL を認証できるようにします。 この処理の後、 管理者は Web サーバーのサービス アカウントに別の DACL を設定して、 Authenticated Users SID を持つすべてのユーザーがその DACL を認証できるようにします。 Contoso フォレストの管理者は、 Fabrikam の管理者が fabrikam.com を構成したのと同じように contoso.com フォレストを構成します。 これらのフォレストのいずれかがエクストラネット フォレストになる可能性があることに注意してください。

Contoso および Fabrikam 両方の管理者は、Netdom ツール (Netdom.exe) を使用して、 信頼を個別に作成します。 管理者は、信頼を作成した後、 この操作のために (各ドメインのドメイン コントローラ間で) Netlogon 固定ポートおよび RPC Endpointmapper ポートを開くことができるように信頼の検証を試みます。 管理者は、信頼を検証した後、ポートを閉じることができます。 Contoso および Fabrikam の管理者は、以下のファイアウォールの規則を作成します。

規則名 ポート 送信元 送信先

Kerberos 認証の着信

88 (UDP、TCP— 着信)

他の企業のサブネット

この企業のドメイン コントローラ

Kerberos 認証の送信

88 (UDP、TCP— 送信)

この企業のサブネット

他の企業のドメイン コントローラ

着信 DACL の照合

88 (UDP— 着信)、389 (TCP、UDP— 着信)、135 (TCP— 着信)、NTDS 固定ポート (TCP— 着信)、Netlogon 固定ポート (TCP— 着信)

他の企業のサブネット

この企業のドメイン コントローラ

送信 DACL の照合

88 (UDP— 送信)、389 (TCP、UDP— 送信)、135 (TCP— 送信)、NTDS 固定ポート (TCP— 送信)、Netlogon 固定ポート (TCP— 送信)

この企業のサブネット

他の企業のドメイン コントローラ

ファイアウォールの規則は、 両方の企業間で機能するように、 認証と照合を有効にします。 管理者は、インターネット プロトコル セキュリティ (IPSec) のポートのみを開いて、 上記の表で説明したトラフィックに IPSec トンネルも選択できることに注意してください。 既定の Windows サービスの多くは、 最初に、認証に Kerberos を使用して、 特定の認証が機能しない場合に NTLM を使用する Negotiate パッケージを使用します。 NTLM 認証も必要な場合は、 適切なポートを開く必要があります。 これらのポートは、この資料の「付録 A : ポートの一覧」で示しています。

fedfin07

図 7: 異なる企業間の複数フォレスト — 展開

境界ネットワークの事例

境界ネットワーク (別名、DMZ、非武装地帯、およびスクリーンド サブネット) では、 境界ネットワークのフォレストから contoso.com という企業のフォレストへの一方向の信頼が確立されます。 この一方向に信頼により、内部フォレストのユーザーは、 内部フォレストのアカウントを使用して、 境界ネットワークのフォレスト内のリソースにアクセスできるようになります。 この事例では、双方向の信頼はお勧めしません。 境界ネットワークのフォレストが危険にさらされると、 悪意のあるユーザーに企業のフォレストへのエントリ ポイントを提供することになります。 このため、管理者は以下のファイアウォールの規則を作成します。

規則名 ポート 送信元 送信先

信頼の作成

88 (UDP、TCP— 送信)、389 (UDP、TCP— 送信)、445 (TCP— 送信)

他の企業のサブネット

この企業のドメイン コントローラ

Kerberos 認証の送信

88 (UDP、TCP— 送信)

この企業のサブネット

境界ネットワークのドメイン コントローラ

着信 DACL の照合

88 (UDP、TCP— 着信)、389 (TCP、UDP— 着信)、135 (TCP— 着信)

NTDS 固定ポート (TCP— 着信)、Netlogon 固定ポート (TCP— 着信)

境界ネットワークのサブネット

内部ドメイン コントローラ

この表の説明は、以下のとおりです。

  • "信頼の作成" 規則は、 信頼が初めて作成されるときのみ、 管理者が適用する必要があります。 この規則は、内部フォレストから両方のドメインに信頼の作成を許可して、 信頼を作成するとすぐに無効になります。
  • "Kerberos 認証の送信" 規則は、 内部ユーザーが境界ネットワークのフォレストを認証できるように、 常に管理者が適用します。
  • "着信 DACL の照合" 規則は、 境界ネットワークのドメイン ローカル グループを変更して、 内部フォレストからグローバル グループまたはユニバーサル グループのいずれかを追加する必要がある場合のみ、 管理者が適用します。 この場合の変更は最小限に抑える必要があります。

fedfin08

図 8: 境界ネットワークの事例 — 展開

ページのトップへページのトップへ

ウォークスルー

これ以降は、連合フォレストのセットアップに使用できる詳細な実装手順を説明します。

ウォークスルーのセットアップ

このウォークスルーで説明するフォレストの構造の詳細は、次の図のとおりです。

fedfin09

図 9: ウォークスルー インフラストラクチャ

各ドメインには 1 台のドメイン コントローラがあり、 ドメイン コントローラの名前はそれぞれ CORP-DC-01、NW-DC-01、および MARKETING-DC-01 です。 CORP-DC-01 と NW-DC-01 ドメイン コントローラはどちらも、 それぞれのフォレストの Active Directory 統合 DNS サーバーをホストします。

フォレストの信頼の作成

この処理を始める前に、 すべてのドメイン コントローラが Windows Server 2003 を実行していることを確認します。 フォレストの信頼を作成するには、 ここで説明する方法を使用して、 以下の作業を実行します。

  • 両方のフォレストで信頼を準備します。
    • DNS を構成します。
    • フォレストとすべてのドメインの機能レベルを Windows Server 2003 に上げます。
  • contoso.com 上でフォレストの信頼を作成します。
  • nwtrader.com 上でフォレストの信頼を作成します。

DNS を構成する
ここでは、フォレストの信頼用に DNS を構成する際に使用する手順を説明します。

事例
Northwind Traders 社と Contoso 社の 2 社の管理者が DNS を構成して、 2 つのフォレスト間でネットワーク接続を確立します。 各フォレストの Active Directory 統合 DNS ゾーンは、 それぞれのルート ドメインに存在します。

DNS を構成するには、以下の手順を実行します。

  1. 管理者特権を使用して、corp.contoso.com ドメインにログオンします。
  2. DNS を構成します。
    1. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、[DNS] をクリックします。
    2. [CORP-DC-01] をクリックし、[プロパティ] をクリックします。
    3. [フォワーダ] タブの [新規作成] をクリックして、「nwtraders.com」と入力し、[OK] をクリックします。
    4. Northwind Traders DNS サーバーの IP アドレス (たとえば、「10.1.1.2」) を入力して、[追加] をクリックし、[OK] をクリックします。
  3. 以下のように接続を検証します。
    1. [スタート] ボタンをクリックして、[ファイル名を指定して実行] をクリックし、[名前] ボックスに「cmd」と入力して、Enter キーを押します。
    2. コマンド プロンプトで「ping nwtraders.com」と入力して、Enter キーを押します。
    3. 応答を受信します。

すべてのドメインとフォレストの機能レベルを Windows Server 2003 に上げる
ここでは、 フォレストの機能レベルを Windows Server 2003 に上げる方法を説明します。 この操作は、フォレストの信頼を確立するために必須です。 この操作を行うには、最初に、 フォレスト内の各ドメインのドメイン機能レベルを Windows Server 2003 機能レベルに上げる必要があります。 フォレスト内のすべてのドメインの機能レベルを Windows Server 2003 に上げると、 フォレストの機能レベルを Windows Server 2003 に上げることができます。

事例
Northwind Traders 社と Contoso 社の 2 社の管理者がフォレストの機能レベルを Windows Server 2003 に上げ、 フォレストの信頼を確立します。

すべてのドメインとフォレストの機能レベルを Windows Server 2003 に上げるには、 以下の手順を実行します。

corp.contoso.com ドメインのドメインコントローラの場合

  1. Active Directory ドメインと信頼関係 MMC スナップインを使用して、 corp.contoso.com ドメインの機能レベルを Windows Server 2003 に設定します。

    1. 管理者特権を使用して、corp.contoso.com ドメインにログオンします。
    2. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    3. [corp.contoso.com] を右クリックして、[ドメインの機能レベルを上げる] をクリックします。
    4. [利用可能なドメインの機能レベルを選択してください] ボックスの一覧で、 [Windows Server 2003]、[上げる]、[OK] の順にクリックして、その後、[OK] をクリックします。
  2. Active Directory ドメインと信頼関係 MMC スナップインを使用して、 フォレストの機能レベルを Windows Server 2003 に設定します。

    1. 管理者特権を使用して、corp.contoso.com ドメインにログオンします。
    2. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    3. [marketing.contoso.com] を右クリックします。
    4. [ドメインの機能レベルを上げる] をクリックします。
    5. [利用可能なドメインの機能レベルを選択してください] ボックスの一覧で、 [Windows Server 2003]、[上げる]、[OK] の順にクリックして、その後、[OK] をクリックします。
  3. Active Directory ドメインと信頼関係 MMC スナップインを使用して、 フォレストの機能レベルを Windows Server 2003 に設定します。

    1. 管理者特権を使用して、corp.contoso.com ドメインにログオンします。
    2. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    3. [Active Directory ドメインと信頼関係] を右クリックして、 [フォレストの機能レベルを上げる] をクリックします。
    4. [利用可能なドメインの機能レベルを選択してください] ボックスの一覧で、 [Windows Server 2003]、[上げる]、[OK] の順にクリックして、その後、[OK] をクリックします。

nwtraders.com ドメインのドメインコントロールの場合

  1. Active Directory ドメインと信頼関係 MMC スナップインを使用して、 nwtraders.com ドメインの機能レベルを Windows Server 2003 に設定します。
    1. 管理者特権を使用して、nwtraders.com ドメインにログオンします。
    2. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    3. [Nwtraders.com] を右クリックして、[ドメインの機能レベルを上げる] をクリックします。
    4. [利用可能なドメインの機能レベルを選択してください] ボックスの一覧で、 [Windows Server 2003]、[上げる]、[OK] の順にクリックして、その後、[OK] をクリックします。
  2. Active Directory ドメインと信頼関係 MMC スナップインを使用して、 フォレストの機能レベルを Windows Server 2003 に設定します。
    1. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    2. [Active Directory ドメインと信頼関係] を右クリックして、[フォレストの機能レベルを上げる] をクリックします。
    3. [利用可能なドメインの機能レベルを選択してください] ボックスの一覧で、 [Windows Server 2003]、[上げる]、[OK] の順にクリックして、その後、[OK] をクリックします。

フォレスト間での信頼の実装

ここでは、フォレストの信頼の実装方法について説明します。

フォレストでの認証と承認を有効にする
Northwind Traders 社と Contoso 社の 2 社の管理者が、 両方のフォレストで認証と承認を有効にします。 どちらの企業も、新しいユーザー名およびパスワードを入力する必要なく、 フォレスト内のユーザーが他のフォレストのリソースにシームレスにアクセスできるようにすることを望んでいます。 このため、企業はフォレスト間で双方向の信頼関係を確立する必要があります。

フォレストで認証と承認を有効にするには、以下の手順を実行します。

  • 以下のように Nwtraders.com ドメインへの接続を検証します。
    • corp.contoso.com ドメインにログオンします。
    • [スタート] ボタンをクリックして、[ファイル名を指定して実行] をクリックし、 [名前] ボックスに「cmd」と入力して、Enter キーを押します。
    • コマンド プロンプトで「ping nwtraders.com」と入力して、Enter キーを押します。
    • 応答を受信します。
  • フォレストの信頼を作成します。
    • [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。

    • [corp.contoso.com] をクリックし、[プロパティ] をクリックします。

    • [信頼] タブをクリックして、[新しい信頼] をクリックし、新しい信頼ウィザードで [次へ] をクリックします。

    • [名前] ボックスに、 信頼を構成するフォレストの名前 (この事例では、「nwtraders.com」) を入力して、[次へ] をクリックします。

    • [フォレストの信頼] をクリックして、[次へ] をクリックします。 [フォレストの信頼] を選択できない場合は、 前のセクションの手順を再度確認して、 フォレストの機能レベルを Windows Server 2003 に上げたことを確認します。

    • [双方向] をクリックして、[次へ] をクリックします。

    • [このドメイン] のドメインと [指定のドメイン] のドメインの両方をクリックして、[次へ] をクリックします。

    • nwtraders.com ドメインの資格情報ダイアログ ボックスで、 ユーザー名 (administrator) とパスワード (nwtraders) の両方を入力して、[次へ] をクリックします。

      信頼を作成するには、ドメインで信頼を作成する特権が必要なことに注意してください。

    • [フォレスト全体の認証。指定のフォレストのユーザーは、ローカル フォレストのすべてのリソースについて自動的に認証されます。このオプションは両方のフォレストが同じ組織に属している場合に推奨されます。] をクリックして、[次へ] をクリックします。

    • [フォレスト全体の認証。ローカル フォレストのユーザーは、Nwtraders.com フォレストのすべてのリソースについて自動的に認証されます。このオプションは両方のフォレストが同じ組織に属している場合に推奨されます。 ] をクリックして、[次へ] をクリックします。

      この操作を行うときは、 信頼の両側の [認証の選択] オプションを無効にすることに注意してください。 次のセクションで [認証の選択] オプションを有効にします。

    • 表示された変更点を見直し、[次へ] をクリックして変更を承認します。

    • [出力方向の信頼の確認] をクリックして、[次へ] をクリックします。

    • [出力方向の信頼の確認] をクリックして、[次へ] をクリックします。

    • 送信する名前のサフィックスを一覧するダイアログ ボックスが表示される場合は、 変更を行わないでください。[次へ]、[完了]、[OK] の順にクリックします。

  • Marketing.contoso.com ドメインにファイル共有を作成して、 共有へのアクセス許可を割り当てます。
    • Marketing-DC-01 サーバー上で、Marketingshare という名前のフォルダを作成し、 (メモ帳などの) テキスト エディタを使用して、テキストを含む Sampletext.txt ファイルを作成します。 その後、Sampletext.txt ファイルを C:\Marketingshare フォルダに保存します。

    • [MarketingShare] フォルダを右クリックし、[共有とセキュリティ] をクリックします。

    • [このフォルダを共有する] をクリックして、[アクセス許可] をクリックします。

    • [グループ名またはユーザー名] ボックスの [追加] をクリックして、 「administrator@nwtraders.com」と入力し、[OK] をクリックします。

    • [グループ名またはユーザー名] ボックスで [administrator@nwtraders.com] をクリックして、 [変更] および [読み取り] ボックス両方にあるすべてのチェック ボックスをオンにします。

    • [グループ名またはユーザー名] ボックスで [Everyone] をクリックして、[削除] をクリックします。

      この方法を使用する場合、DACL ファイル共有に直接ユーザーを追加して、 アクセス許可を与えることはできないことに注意してください。 ただし、ドメイン ローカル グループを作成して、 共有にアクセス許可を与えると、 リモート フォレスト グループをこのドメイン ローカル グループに追加することはできます。 ここでは、DACL にユーザーを直接追加します。 グループ メンバシップの規則の詳細については、次のセクションで説明します。

  • Marketing-DC-01 ドメイン、および作成した SampleText.txt ファイルにアクセスできることを確認します。
    • 管理者特権を使用して、NW-DC-01 サーバーにログオンします。
    • [スタート] をクリックして、[ファイル名を指定して実行] をクリックし、 [名前] ボックスに「\\Marketing-DC-01\Marketingshare」と入力して、Enter キーを押します。
    • [Sampletext.txt] ファイルをダブルクリックし、 ファイルを開いて読み取り可能なことを確認します。 ファイルを開けない場合、アクセス許可が適切に割り当てられていないことを確認します。
    • メモ帳などのテキスト エディタを使用して Sampletext2.txt ファイルを作成します。 その後、そのファイルを \\Marketing-DC-01\Marketingshare フォルダに保存して 、ファイルを共有に保存できることを確認します。

代替名サフィックスを追加する
contoso.com フォレストの管理者は、 ユーザーの電子メール名に対応する代替名サフィックスを追加します。 これにより、ユーザーは、user@e-mail.contoso.com などの電子メール名を使用してネットワークにログオンできます。 サフィックスは、ユーザーがそのサフィックスを使用できる他のフォレストで認識される必要があります。

以下の手順を使用して、 代替名サフィックスを追加し、 その名前サフィックスをユーザーの UPN 名に追加して、代替名サフィックスへのルーティングを可能にします。

  • corp.contoso.com ドメインに代替名サフィックスを追加します。
    • [スタート] をクリックして、[すべてのプログラム] をポイントして、[管理ツール] をクリックします。
    • [Active Directory ドメインと信頼関係] を右クリックして、[プロパティ] をクリックします。
    • [代わりの UPN サフィックス] に「e-mail.contoso.com」と入力して、[追加] をクリックします。
  • corp.contoso.com ドメインのユーザーの UPN に代替名サフィックスを追加します。
    • corp.contoso.com ドメインで testuser ユーザー ログイン名を使用して、 ユーザーを作成します。 この操作方法の詳細については、Microsoft Web サイトの https://www.microsoft.com/windows2000/ja/advanced/help/dsadmin_concepts_delegate.htm?id=375 を参照してください。
    • Active Directory ユーザーとコンピュータで、[testuser] を右クリックして、[プロパティ] をクリックします。
    • [アカウント] タブをクリックして、[ユーザー ログオン名] ボックスに「testuser」と入力して、 [ドメイン] ボックスの [e-mail.contoso.com] をクリックします。
  • nwtraders ドメインで代替名サフィックスへの送信を有効にします。
    • 管理者特権を使用して、nwtraders.com ドメインにログオンします。
    • [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    • 左ウィンドウの [nwtraders.com] を右クリックして、[プロパティ] をクリックします。
    • [信頼] タブをクリックして、[このドメインに信頼されるドメイン (出力方向の信頼)] ボックスの [corp.contoso.com] をクリックし、[プロパティ] をクリックします。
    • [名前サフィックス ルーティング] タブをクリックして、 corp.contoso.com フォレスト内の [名前サフィックス] ボックスの [*.e-mail.contoso.com] をクリックします。
    • [有効にする] をクリックして、[OK] をクリックし、[OK] をクリックします。

信頼関係からドメインを除外する
nwtraders.com フォレストの管理者は、marketing.contoso.com サブドメインとの信頼関係を必要としません。 そのため、管理者はそのドメインを信頼関係から除外します。

信頼関係からドメインを除外するには、以下の手順を実行します。

  • nwtraders.com ドメインにファイル共有を作成します。
    • 管理者特権を使用して、nwtraders.com ドメインにログオンします。
    • [スタート] をクリックして、[すべてのプログラム]、[アクセサリ] を順にポイントし、[Windows エクスプローラ] をクリックします。
    • 左ウィンドウの %SystemRoot% フォルダ (Windows をインストールするフォルダ) をクリックして、 右ウィンドウの空いている場所を右クリックし、[新規作成] をポイントして、[フォルダ] をクリックし、 フォルダ名に「nwshare」と入力します。
    • 右ウィンドウで作成した [Nwshare] フォルダを右クリックして、[共有とセキュリティ] をクリックします。
    • [このフォルダを共有する] をクリックして、[アクセス許可] をクリックし、[追加] をクリックします。
    • [選択するオブジェクト名を入力してください] ボックスに「administrator@marketing.contoso.com」と入力して、 [OK] をクリックします。
    • [グループ名またはユーザー名] ボックスの [Administrator@marketing.contoso.com] をクリックして、 [Administrator@marketing.contoso.com へのアクセス許可] ボックスの [許可] 列で [変更] をクリックします。 [Administrator@marketing.contoso.com へのアクセス許可] ボックスの [許可] 列で [読み取り] をクリックして、[OK] をクリックします。
    • [グループ名またはユーザー名] ボックスで [Everyone] をクリックし、[削除] をクリックして、[OK] をクリックします。
    • 管理者特権を使用してコンピュータにログオンしている間、 marketing.contoso.com 共有から Nwshare フォルダにアクセスできることを確認します。 この操作を行うには、[スタート] をクリックして、[ファイル名を指定して実行] をクリックし、 [名前] ボックスに「\\NW-DC-01\Nwshare」と入力して、Enter キーを押します。
  • nwtraders.com ドメインで marketing.contoso.com の DomainInfo レコードを無効にします。
    • 管理者特権を使用して、nwtraders.com ドメインにログオンします。
    • [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    • 左ウィンドウの [nwtraders.com] を右クリックして、[プロパティ] をクリックします。
    • [信頼] タブをクリックして、[このドメインに信頼されるドメイン (出力方向の信頼)] ボックスの [corp.contoso.com] をクリックし、[プロパティ] をクリックします。
    • [名前サフィックス ルーティング] タブをクリックして、[marketing.contoso.com] をクリックし、[無効にする] をクリックします。

TopLevelName 除外レコードをセットアップする
contoso.com フォレストの管理者は、plant.nwtraders.com を除く、 nwtraders.com に存在するすべての名前空間の nwtraders.com フォレストとの信頼関係をセットアップします。 plant.nwtraders.com フォレストが別の場所に存在すること、 および contoso.com フォレストの管理者がそのフォレストとの信頼関係をセットアップしようとしていることにより、 plant.nwtraders.com フォレストは、このサンプル事例で使用しない仮定のフォレストになることに注意してください。

TopLevelName 除外レコードをセットアップするには、以下の手順を実行します。

  1. 管理者特権を使用して、corp.contoso.com ドメイン コントローラにログオンします。
  2. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
  3. 左ウィンドウの [corp.contoso.com] を右クリックして、[プロパティ] をクリックします。
  4. [信頼] タブをクリックして、[このドメインに信頼されるドメイン (出力方向の信頼)] ボックスで [Nwtraders.com] をクリックし、 [プロパティ] をクリックします。
  5. [nwtraders.com へのルーティングから除外する名前サフィックス] タブをクリックして、[追加] をクリックします。 「*.plant.nwtraders.com」を入力して、[OK] をクリックします。その後、[OK] をクリックします。

認証の選択オプション

Contoso 社の管理者は、 セキュリティ上の制約により、Northwind Traders フォレストのすべてのユーザーをそのフォレストで認証することを許可できるわけではないと判断しました。 Contoso 社の管理者は、 他のフォレストからの Enterprise Admins グループのメンバのみに認証を許可します。 その結果、marketing.contoso.com ドメインのみに許可することになります。

[認証の選択] オプションを有効にするには、以下の手順を実行します。

  • corp.contoso.com の [認証の選択] オプションを有効にして、 nwtraders.com からの認証の選択のみを有効にします。
    • 管理者特権を使用して corp.contoso.com ドメインにログオンしていることを確認します。
    • [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
    • 左ウィンドウの [corp.contoso.com] を右クリックして、[プロパティ] をクリックします。
    • [信頼] タブをクリックして、[このドメインに信頼されるドメイン (出力方向の信頼)] ボックスで [Nwtraders.com] をクリックし、 [プロパティ] をクリックします。
    • [認証] タブをクリックして、 [認証の選択。指定のフォレストのユーザーは、ローカル フォレストのすべてのリソースについて自動的に認証されません。このダイアログを閉じた後、指定のフォレストのユーザーが利用できるようにする各ドメインおよびサーバーについて個々のアクセス権を許可してください。このオプションはフォレストがそれぞれ別の組織に属している場合に推奨されます。] をクリックし、[OK] を 2 回クリックします。
  • marketing.contoso.com ドメインにファイル共有を作成して、共有へのアクセス許可を割り当てます。
    • Marketing-DC-01 コンピュータで、[スタート] をクリックして、[すべてのプログラム]、[アクセサリ] の順にポイントし、 [Windows エクスプローラ] をクリックします。
    • 左ウィンドウの [ローカル ディスク (C:)] をクリックして、 右ウィンドウの空いている場所で右クリックし、[新規作成] をポイントして、[フォルダ] をクリックします。 新しいフォルダの名前に「Testfolder」と入力します。
    • 右ウィンドウの新しい [Testfolder] フォルダをダブルクリックして、 フォルダを開きます。 空いている場所で右クリックして、[新規作成] をポイントし、[テキスト ドキュメント] をクリックして、 ドキュメントの名前に「Testdoc.txt」と入力します。
    • 左ウィンドウの [Testfolder] フォルダを右クリックして、[共有とセキュリティ] をクリックします。
    • [このフォルダを共有する] をクリックして、[アクセス許可] をクリックします。 [追加] をクリックして、「administrator@nwtraders.com」と入力します。
    • [グループ名またはユーザー名] ボックスの [administrator@nwtraders.com] をクリックして、 [Administrator@ nwtraders.com へのアクセス許可] ボックスの [許可] 列で [変更] をクリックします。 [Administrator@ nwtraders.com へのアクセス許可] ボックスの [許可] 列で [読み取り] をクリックして、 [OK] をクリックします。
    • [グループ名またはユーザー名] ボックスで [Everyone] をクリックして、[削除] をクリックします。
  • Nwtraders.com から Marketing.contoso.com にアクセスできないことを確認します。
    • 管理者特権を使用して、NW-DC-01 コンピュータにログオンします。

    • [スタート] をクリックして、[ファイル名を指定して実行] をクリックし、 [名前] ボックスに「\\marketing-dc-01\marketingshare」と入力して、Enter キーを押します。

      [認証の選択] オプションを有効にしたので、 共有にアクセスできなくなります。 共有にアクセスできる場合は、アクセス許可が正しく構成されていることを確認します。

  • Marketing-DC-01 の [認証の選択] を有効にします。
    • 管理者特権を使用して、marketing.contoso.com コンピュータにログオンします。

    • [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ユーザーとコンピュータ] をクリックします。

    • [表示] メニューの [拡張機能] をクリックして、左ウィンドウの [ドメイン コントローラ] をクリックします。

    • 右ウィンドウの [MARKETING-DC-01] をクリックし、[プロパティ] をクリックします。

    • [セキュリティ] タブをクリックして、[追加] をクリックし、 「administrator@nwtraders.com」と入力して、[OK] をクリックします

    • [グループ名またはユーザー名] ボックスの [Administrator@nwtraders.com] をクリックして、 [Administrator@nwtraders.com のアクセス許可] ボックスにある [許可] 列の [認証を許可] チェック ボックスをオンにします。

      この操作の後、administrator@nwtraders.com ユーザーは、NW-DC-01 コンピュータを認証できます。

  • nwtraders.com から marketing.contoso.com にアクセスできることを確認します。
    • 管理者特権を使用して、NW-DC-01 コンピュータにログオンします。

    • [スタート] をクリックして、[ファイル名を指定して実行] をクリックし、 [名前] ボックスに「\\marketing-dc-01\marketingshare」と入力して、Enter キーを押します。

      この時点で、共有にアクセスできます。

ファイアウォール上でフォレストの信頼を有効にするための ISA Server 2000 の構成

ここでは、 ファイアウォール上で信頼と認証を有効にするように Microsoft Internet Security and Acceleration (ISA) Server 2000 を構成する方法について説明します。

信頼をセットアップする
この方法では、 信頼のセットアップ時にファイアウォール内部のネットワークから外部への接続のみを必要とするので、 内部コンピュータから両方のフォレストに信頼をセットアップすることをお勧めします。 この操作を行うには、ISA Server ファイアウォール クライアントを起動して、 内部のドメイン コントローラから LDAP (389 UDP と TCP) および Microsoft SMB (445 TCP) ポート両方の外部ドメイン コントローラにトラフィックを許可します。 フォレストの信頼をセットアップするには、 この操作のみ実行する必要があります。 その結果、信頼関係をセットアップした後、ISA Server ファイアウォール クライアントを閉じることができます。 また、別のルールを追加して、Kerberos (88 UDP) トラフィックを許可する必要もあります。 認証要求がファイアウォールを通過できるように、このルールを保持する必要があります。 ISA Server SP1 ファイアウォール クライアントでこの手順を使用するには、以下の手順を実行します。

  1. [スタート] をクリックして、[すべてのプログラム]、[Microsoft ISA Server] を順にポイントし、 [ISA の管理] をクリックします。

  2. コンソール ウィンドウで、[サーバーとアレイ]、[<サーバー>]、[アクセス ポリシー] を順にクリックして展開し、 [プロトコル ルール] をクリックします。 その後、[操作] メニューの [新規作成] をポイントして、[ルール] をクリックします。

  3. 「allow xforest setup」のように、このルールの名前を入力して、[次へ] をクリックします。

  4. [許可する] をクリックして、[次へ] をクリックします。

  5. [ルールの適用先] ボックスの [選択されたプロトコル] をクリックし、 [選択されたプロトコルのみを表示する] チェック ボックスをオフにして、 [Kerberos-Sec(UDP)] チェック ボックスをオンにします。 その後、[LDAP] チェック ボックスをオンにして、[次へ] をクリックします。

  6. [使用するスケジュール] ボックスの [常時] をクリックして、[次へ] をクリックします。

  7. [すべての要求] をクリックして、[次へ] をクリックし、[完了] をクリックします。

  8. 既定で定義されていない Microsoft-DS および LDAP UDP の両方のプロトコルの定義を作成します。

    1. 手順 1 から 7 までで新しいルールを作成した後、 結果ウィンドウでルールをダブルクリックして、[プロトコル] タブをクリックし、[新規作成] をクリックします。
    2. ルールの [新しいプロトコル] ダイアログ ボックスで、「LDAP UDP」 などのルールの名前を入力します。
    3. [ポート番号] ボックスに、「389」と入力します。
    4. [プロトコルの種類] ボックスで、[UDP] をクリックします。
    5. [方向] ボックスで、[受信後、送信許可] をクリックして、[OK] を 2 回クリックします。
  9. Microsoft-DS のプロトコル定義を追加します。

    1. 結果ウィンドウで、手順 1 から手順 7 までで作成したルールをダブルクリックして、 [プロトコル] タブをクリックし、[新規作成] をクリックします。
    2. 「microsoft-ds outbound」など、ルールの名前を入力します。
    3. [ポート番号] ボックスに、「445」と入力します。
    4. [プロトコルの種類] ボックスで、[TCP] をクリックします。
    5. [方向] ボックスで、[発信] をクリックして、[OK] を 2 回クリックします。
  10. ルールを作成した後、ファイアウォール サービスを再起動して、ルールを開始します。

    1. ISA 管理コンソールで、[サーバーとアレイ] をクリックして展開し、 サーバーをクリックします。[監視] をクリックして、[サービス] をクリックします。
    2. 結果ウィンドウで、[Firewall] サービスを右クリックして、[停止] をクリックします。
    3. 結果ウィンドウで、[Firewall] サービスを右クリックして、[開始] をクリックします。
  11. この資料の「フォレスト間での信頼の実装」にある手順に従って、 内部コンピュータからフォレスト上で信頼をセットアップします。

  12. 信頼のセットアップ ルールは既に必要ないので、削除します。

  13. コンソール ツリーで、[サーバーとアレイ] をクリックして展開し、 サーバーをクリックします。[アクセス ポリシー] をクリックして、[プロトコル ルール] をクリックします。

  14. [allow xforest setup] をダブルクリックして、[有効にする] チェック ボックスをオフにして、[OK] をクリックします。

  15. 手順 10 の方法を使用して、 ファイアウォール サービスを再起動すると、ルールが削除されます。

信頼の検証とネットワークログオン
外部コンピュータ上の共有に対する信頼の検証とネットワーク ログオンが必要な場合、 特定のポートを開く必要があります。 プロトコル ルールでは、LDAP UDP ポート、Kerberos sec UDP ポート、 任意の RPC サーバー ポート、DCE エンドポイント解決送信ポート、 および Microsoft-DS 送信ポートを開く必要があります。 さらに、内部フォレストのドメイン コントローラ上で LDAP UDP ポートと任意の RPC サーバー ポートの両方を公開する必要もあります。 この操作を行うには、以下の手順を実行します。

  1. [スタート] をクリックして、[すべてのプログラム]、[Microsoft ISA Server] を順にポイントし、 [ISA の管理] をクリックします。

  2. コンソール ツリーで、[サーバーとアレイ]、{<サーバー>}、[アクセス ポリシー] を順にクリックして展開し、 [プロトコル ルール] をクリックします。

  3. [操作] メニューの [新規作成] をポイントして、[ルール] をクリックします。

  4. このルールの名前 (「allow xforest validation」など) を入力して、[次へ] をクリックします。 [許可する] をクリックして、[次へ] をクリックします。

  5. [規則の適用先] ボックスの一覧で、[選択されたプロトコル] をクリックして、 [選択されたプロトコルのみを表示する] チェック ボックスをオフにします。

  6. 以下のチェック ボックスすべてのオンにします。

    • [Any RPC Server]
    • [Kerberos-Sec(UDP)]
    • [LDAP UDP]
    • [Microsoft-DS outbound]
  7. 作成した 4 つの定義 (DCE エンドポイント解決、LDAP TCP 着信、LDAP UDP 着信、および Kerberos UDP 着信) のチェック ボックスがオンであることを確認します。 残りのチェック ボックスがオフになっていることを確認したら、[次へ] をクリックします。

  8. ルールのスケジュールを選択して、[次へ] をクリックします。

  9. このルールを特定のクライアントのみに適用するか、 またはすべてのクライアントに適用するかを選択して、[次へ] をクリックし、[完了] をクリックします。

  10. DCE エンドポイント解決、LDAP TCP 着信、LDAP UDP 着信、および Kerberos UDP 着信のプロトコル定義は、 既定では利用できません。そのため、これらを作成する必要があります。 LDAP UDP 着信および Kerberos UDP 着信は両方とも次のセクションで使用されます。 プロトコルの定義を作成します。

    1. DCE エンドポイント解決のプロトコル定義を追加します。

      結果ウィンドウで、ルールをダブルクリックして、[プロトコル] タブをクリックし、[新規作成] をクリックします。

      ルールの名前 (「dce endpoint resolution – outbound」など) を入力します。

      [ポート番号] ボックスに、「135」と入力します。

      [プロトコルの種類] ボックスで、[TCP] をクリックします。

      [方向] ボックスで、[発信] をクリックして、[OK] をクリックします。

    2. LDAP TCP 着信のプロトコル定義を追加します。

      結果ウィンドウで、ルールをダブルクリックして、[プロトコル] タブをクリックし、[新規作成] をクリックします。

      ルールの名前 (「LDAP TCP inbound」など) を入力します。

      [ポート番号] ボックスに、「389」と入力します。

      [プロトコルの種類] ボックスで、[TCP] をクリックします。

      [方向] ボックスで、[着信] をクリックして、[OK] をクリックします。

    3. LDAP UDP 着信のプロトコル定義を追加します。

      結果ウィンドウで、ルールをダブルクリックして、[プロトコル] タブをクリックし、[新規作成] をクリックします。

      ルールの名前 (「LDAP TCP inbound」など) を入力します。

      [ポート番号] ボックスに、「389」と入力します。

      [プロトコルの種類] ボックスで、[UDP] をクリックします。

      [方向] ボックスで、[受信後、送信許可] をクリックして、[OK] をクリックします。

    4. Kerberos UDP 着信のプロトコル定義を追加します。

      結果ウィンドウで、ルールをダブルクリックして、[プロトコル] タブをクリックし、[新規作成] をクリックします。

      ルールの名前 (「kerberos UDP inbound」など) を入力します。

      [ポート番号] ボックスに、「88」と入力します。

      [プロトコルの種類] ボックスで、[UDP] をクリックします。

      [方向] ボックスで、[受信後、送信許可] をクリックして、[OK] をクリックします。

  11. 着信接続用のポートを公開します。

    1. コンソール ツリーで [公開] をクリックして展開し、[サーバー公開ルール] をクリックします。

    2. [サーバーの公開] をクリックして、サーバー名 (「LDAP UDP」など) を入力し、[次へ] をクリックします。

    3. 公開するサーバーの IP アドレスを入力して、 外部サーバーが内部サーバーに接続するときに経由する外部インターフェイスの IP アドレスを入力し、[次へ] をクリックします。

    4. 適切なプロトコル ([LDAP UDP inbound] など) をクリックして、[次へ] をクリックします。

    5. [特定のコンピュータ] をクリックして、[次へ] をクリックします。

    6. [追加] をクリックして、外部サーバーの IP アドレス用のクライアント セットを追加し、[OK] をクリックします。

    7. クライアントセットをクリックして、[OK]、[次へ]、[完了] の順にクリックします。

      手順 a から手順 g を繰り返して、"Any RPC Server" ルールのサーバーを公開します。

オブジェクトピッカー : サービス管理者に DACL のセットアップを許可する
オブジェクト ピッカーを使用するには、 任意の RPC サーバー、LDAP UDP 着信、LDAP TCP 着信、および Kerberos UDP 着信を公開する必要があります。 この操作を行うと、内部フォレストのオブジェクトを参照して、 外部フォレストにある DACL に追加できます。

フォレストの信頼を個別にセットアップする
この方法は推奨されていませんが、 内部サーバーから両方のフォレストに信頼を作成できない場合のみ使用します。 この方法は、内部のドメイン コントローラ上のポートの公開を伴い、 フォレストがそのドメイン コントローラに接続できるようにします。 前述の (両方のフォレストに信頼をセットアップする) 手順を使用して、 ファイアウォールの内側のフォレストに信頼を作成できます。 ファイアウォールの外側のフォレストに信頼を作成するには、 内部サーバーのドメイン コントローラ上で以下のポートを公開します。

  • Microsoft-DS (ポート 445)
  • LDAP TCP (ポート 389)
  • LDAP UDP (ポート 389)
  • Kerberos-sec UDP (ポート 88)
  • 前述の手順を使用すると、これらの各ポートのサーバーを公開できます。

既定ではローカル Direct Host SMB サービスがファイアウォール上のポート 445 を使用するので、 最初にこのサービスを無効にする必要があります。 この操作を行うには、次のレジストリ キーでレジストリ キーの DWORD 値をゼロ (0) に設定または作成して、 コンピュータを再起動します。

HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\NetBT\Parameters\SMBDeviceEnabled

この操作の後、ISA Server ファイアウォール クライアントは、ポート 445 にバインドして、 パケットを内部サーバーに転送できます。

エラーメッセージ
ファイアウォール上で信頼をセットアップしようとすると、 以下のエラー メッセージが表示されることがあります。

  • 指定されたドメインは、Windows ドメイン名ではありません。
    あるドメイン コントローラが他のドメイン コントローラを検出できない場合、 このエラー メッセージが表示されることがあります。DNS が正常にセットアップされていません。

  • パラメータが無効です。
    LDAP UDP ポートが開いていません。

  • アクセスが拒否されました。
    Kerberos ポートが開いていないか、またはリモート パスワードが間違っています。

  • RPC サーバーが利用できません。
    Microsoft-DS ポートが開いていません。

  • フォレスト機能レベルにクエリできません。フォレストが機能していません。
    LDAP TCP ポートが開いていません。

  • Endpointmapper にはこれ以上エンドポイントがありません。
    NTDS ポートと Netlogon ポートがどちらも開いていません。

    Kerberos ポートが開いていないか、またはリモート パスワードが間違っています。

  • 特定できないエラーです。
    Endpointmapper ポートが開いていることを確認します。

フォレストの信頼の削除

Contoso 社の管理者は、フォレストの信頼を既に必要としなくなりました。

この事例では、フォレストの信頼を削除します。 フォレストの信頼を削除するには、以下の手順を実行します。

  1. 管理者特権を使用して、corp.contoso.com ドメインにログオンします。
  2. [スタート] をクリックして、[すべてのプログラム]、[管理ツール] を順にポイントし、 [Active Directory ドメインと信頼関係] をクリックします。
  3. 左ウィンドウの [corp.contoso.com] を右クリックして、[プロパティ] をクリックします。
  4. [信頼] タブをクリックして、[このドメインに信頼されるドメイン (出力方向の信頼)] ボックスで [nwtraders.com] を右クリックし、[削除] をクリックします。
  5. [ローカル ドメインと他方のドメインの両方から信頼を削除する] をクリックします。
  6. [ユーザー名] ボックスに「Administrator」と入力して、[パスワード] ボックスにパスワードを入力します。
  7. [はい] をクリックして、信頼を削除するためのオプションを選択します。

手順 4 から手順 7 までを繰り返して、[このドメインを信頼するドメイン (入力方向の信頼)] ボックスの入力方向の信頼を削除します。

ページのトップへ ページのトップへ

付録 A – ポートの一覧

次の表では、信頼をセットアップする前に開く必要があるポートの一覧を示しています。

事例 発信ポート 着信ポート 接続元 - 接続先

内部フォレストから両方向の信頼のセットアップ

LDAP (389 UDP および TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

エンドポイント解決 - ポートマッパー (135 TCP) Netlogon 固定ポート

 

内部ドメインのドメイン コントローラ – 外部ドメインのドメイン コントローラ (すべてのポート)

内部フォレストのドメイン コントローラから外部フォレストのドメイン コントローラへの信頼の検証 (出力方向の信頼のみ)

LDAP (389 UDP)

Microsoft SMB (445 TCP)

エンドポイント解決 - ポートマッパー (135 TCP) Netlogon 固定ポート

 

内部ドメインのドメイン コントローラ – 外部ドメインのドメイン コントローラ (すべてのポート)

内部フォレスト内のオブジェクトをグループおよび DACL に追加するための外部フォレスト上のオブジェクト ピッカー

 

LDAP (389 UDP および TCP)

Windows NT Server 4.0 ディレクトリ サービスの固定ポート

Netlogon 固定ポート

Kerberos (88 UDP)

エンドポイント解決ポートマッパー (135 TCP)

外部サーバー – 内部ドメイン PDC (Kerberos)

外部ドメインのドメイン コントローラ – 内部ドメインのドメイン コントローラ (Netlogon)

外部フォレストから外部フォレスト上での信頼のセットアップ

 

LDAP (389 UDP および TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

外部ドメインのドメイン コントローラ – 内部ドメインのドメイン コントローラ (すべてのポート)

Kerberos 認証 (外部フォレストに対する内部フォレスト クライアント)

Kerberos (88 UDP)

 

内部クライアント – 外部ドメインのドメイン コントローラ (すべてのポート)

NTLM 認証 (外部フォレストに対する内部フォレスト クライアント)

 

エンドポイント解決 - ポートマッパー (135 TCP) Netlogon 固定ポート

外部ドメインのドメイン コントローラ – 内部ドメインのドメイン コントローラ (すべてのポート)

内部コンピュータから外部ドメインへのドメインの参加

LDAP (389 UDP および TCP)

Microsoft SMB (445 TCP)

Kerberos (88 UDP)

エンドポイント解決 - ポートマッパー (135 TCP) Netlogon 固定ポート

Windows NT Server 4.0 ディレクトリ サービスの固定ポート

 

内部クライアント – 外部ドメインのドメイン コントローラ (すべてのポート)

以下のキーを構成して、固定ポート上で実行するサービスを指定します。

  1. (NTDS 固定ポートと同じ) LSA (ローカル セキュリティ機関) RPC ポート – 信頼の作成および他の LSA ポリシー データベースへのアクセスに使用する HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters レジストリ キーの TCP/IP Port エントリ。
  2. NTLM、信頼のチャンネルに使用する Netlogon RPC ポート – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters レジストリ キーの DCTcpipPort エントリ。

ページのトップへ ページのトップへ

付録 B – この資料で使用する用語

この資料では、以下の用語を使用しています。

  • 外部の信頼 : 個別のフォレストに存在する 2 つのドメイン間の単一の信頼リンクです。 外部の信頼は、ドメインから他のドメインへの非推移性の信頼を確立します。 このような信頼は、管理者によって明示的に作成および保持される必要があります。 この信頼は、一方向または双方向の信頼になります。
  • 内部の信頼 : 同一フォレストに存在する 2 つのドメイン間の単一の信頼リンクです。 内部の信頼は、2 つのドメイン間の推移性の信頼を確立します。 たとえば、Domain A が Domain B を信頼して、Domain B が Domain C を信頼する場合、 Domain A は Domain C
  • フォレストの信頼 : 2 つのフォレストのルート ドメイン間の単一の信頼リンクです。 フォレストの信頼は、各フォレスト内のすべてのドメイン間に推移性の信頼を確立します。 たとえば、Forest A が Forest B を信頼する場合、Forest A のすべてのドメインは、 フォレストの信頼を使用して、Forest B のすべてのドメインを信頼します。 ただし、この信頼には、フォレスト間の推移性はありません。 たとえば、Forest A が Forest B を信頼して、Forest B が Forest C を信頼する場合、 Forest A が Forest C を自動的に信頼することはありません。 この信頼は、一方向または双方向の信頼になります。
  • 信頼されたドメインオブジェクト (TDO) : 2 つのドメインまたはフォレスト間の信頼を表す Active Directory 内に存在するオブジェクトです。
  • フォレスト TDO : フォレストの信頼を示すために設定されるビットを保持する既存の信頼の定義オブジェクトです。
  • 名前空間 : 別の種類の情報 (たとえば、セキュリティ プリンシパル) を象徴的に示すために使用できる名前、 およびその名前空間に属する名前を判断するために確立する特定の規則に関連する名前をグループ化したものです。 たとえば、名前空間が "a.contoso.com または b.contoso.com で終了する名前を除いた contoso.com で終了するすべての名前" になる可能性があります。 フォレストは、非常に良く似た多くの名前空間を管理しますが、 これらの名前空間を使って、 ユーザー プリンシパル名 (UPN)、 サービス
  • 最上位レベルの名前 (TLN) : 名前空間の識別に使用する名前です。 たとえば、corp.fabrikam.com は、server.corp.fabrikam.com、server1.corp.fabrikam.com、server2.corp.fabrikam.com など、corp.fabrikam.com の下にあるすべての名前を含む名前空間を識別する TLN です。
  • 最上位レベルの名前の除外 (TLNEx) : 名前空間の一部を除外するレコードです。 たとえば、fabrikam.com TLN 上の test.fabrikam.com の TLNEx は、 名前空間が、test.fabrikam.com の名前を除く、fabrikam.com にあるすべての名前で構成されることを指定します。
  • フォレストの信頼情報 (FTInfo) : 信頼される側のフォレストが管理を要求する (TLN で指定された) 名前空間のセットです。 これには、実際に各要求が信頼する側のフォレストに信頼されているかどうか示すフィールドがコメントとして付いています。 FTInfo は、フォレスト TDO 上に格納され、 認証や承認の要求を信頼される側のフォレストにルーティングするために使用されます。
  • ユーザープリンシパル名 (UPN) : 電子メール名のようなユーザー名のバリエーションですが、ログオンには使用できません。 構文は、user_name@string です。
  • 暗黙の UPN : 暗黙の UPN は、常に、user_id@DNS_domain_name.com 形式で構成されます。 この UPN は、明示的な UPN が定義されていない場合でも、 常にユーザーのアカウントに関連付けられます。
  • 明示的な UPN : 明示的な UPN は、string@any_string 形式で構成されています。 この場合の string および any_string は共に管理者が明示的に定義します。
  • UPN サフィックス : UPN の派生元の名前空間を示す文字列です。UPN サフィックスには、 完全な UPN のアット マーク (@) の右側のすべての文字が含まれています。 テキストに別のアット マークが含まれている場合でも、 アット マークの左側はすべて、ユーザー名と考えられます。 UPN サフィックスは構造内でフラットまたは階層のいずれかになることがありますが、 一般的に、フラットな名前空間を識別するために使用されます。
  • サービスプリンシパル名 (SPN) : コンピュータ アカウントに関連するサービスを識別するために使用するマルチコンポーネントの名前です。 一般的に、SPN は Kerberos サービス チケットの要求に使用されます。 構文は service_type/instance_name [:port_number] [/service_name [@domain] ] (例、host/server.contoso.com, MSSQLSvc/server.contoso.com:1433) です。
  • SPN サフィックス : SPN のコンポーネントの派生元の名前空間を示す文字列です。 SPN サフィックスは、instance_name または service_name コンポーネントの後続のサブ文字列で構成されることがあります。 これには、アット マーク (@) を除いたすべての domain コンポーネントが含まれることがあります。
  • セキュリティ識別子 (SID) : S-1-5-123232343434-544 など、 すべてのセキュリティ プリンシパルに関連する一意の識別子です。 SID は、ドメイン識別子と相対識別子 (RID) で構成されています。

ページのトップへ ページのトップへ