Active Directory 設計ガイド
Alan von Weltin - Microsoft Consulting Services
Microsoft 製品サポート サービス ホワイトペーパー
概要
この文書では、Microsoft® Windows® 2000 Server および Microsoft Active Directory・の展開を計画している企業を対象として、設計原則の概要を説明します。 大企業において検討しなければならない上位の決定事項をいくつか示します。この文書は、製品ドキュメント、プロジェクト計画、Microsoft Windows 2000 Server リソース キットの情報 (導入計画ガイドを含む) に代わるものではありません。
トピック
.gif "はじめに"){kind=icon}
はじめに
始める前に
ネットワーク インフラストラクチャ
フォレストの計画
ドメインの計画
組織単位の計画
サイト トポロジの計画
詳細情報
はじめに
本書の構成
この文書は以下の節で構成されます。
始める前に
ネットワーク インフラストラクチャ
フォレストの計画
ドメインの計画
組織単位の計画
サイト トポロジの計画
対象読者
このガイドは、Microsoft Windows NT® Server バージョン 4.0 および Microsoft Windows NT Workstation (ならびに Microsoft Windows® 95 および Microsoft Windows® 98) から Windows 2000 Server にプラットフォームを移行する大企業を対象としています。 Windows 2000 Server のインフラストラクチャ要素について説明することに主眼を置いており、デスクトップ クライアント (Microsoft Windows 2000 Professional など) を導入する際の留意事項には触れていません。
.gif "ページのトップへ"){kind=icon}
ページのトップへ
始める前に
Windows 2000 Server に関する情報を詳しく検討すると、先進技術が利用されていることから、展開作業は大変な難事業に思えるかもしれません。 大規模で複雑なプロジェクトには必ず言えることですが、大きなチームのメンバが個々に対応できる作業のリストを最初に作成するのが最善の方法です。 これによって、各メンバが他のメンバの作業が完了するのを待たずに検討作業に入り、結果を出すことができます。 できれば、定期的に会議を開いてプロジェクトの状況と現時点までの作業の成果を報告する Windows 2000 Server コア チームを編成してください。 この手段では、各チーム メンバが Windows 2000 Server 全体の概要を把握するのではなく、特定の領域に着目することによって、Windows 2000 Server に関する知識を深めていくことができます。
チームの役割
Microsoft Windows 2000 Server リソース キット の『導入計画ガイド』では、次のような役割を例として挙げ、作業内容を説明しています。
サーバーおよびインフラストラクチャの設計 - 全体的な設計とエンジニアリングを担当します。
Active Directory - フォレスト、ドメイン、組織単位、サイトの計画を担当します。
モバイルおよびデスクトップ設計 - 構築プロセスとポリシーの割り当てを定義します。
セキュリティ - アクセス許可、セキュリティ グループ、管理の委任、異種プラットフォームの相互運用性、公開キー基盤 (PKI) の実装および統合を担当します。
移行 - Windows NT Server 4.0 からの共存を含めた移行パスを定義します。
証明書サービス - 暗号化ファイルシステム (EFS) 、インターネットプロトコルセキュリティ (IPSec) 、スマートカードを担当します。
フリーシーティング - 「場所を選ばないデスクトップ」 という概念を作成します。
アプリケーション管理 - アプリケーションを作成、管理、展開する方法を決定します。
ページのトップへ
ネットワーク インフラストラクチャ
Windows NT Server 4.0 とは異なり、Windows 2000 Server は DNS (ドメイン ネーム システム) と統合されており、DNS を使ってサービスを検索します。 DNS は Active Directory が機能するうえできわめて重要な働きをします。 DNS は必ず使用しなければならないわけではありませんが、Windows 2000 Server に付属しており、自動的に多くのサービスを提供するため、付加価値をもたらします。 DNS が提供するサービスには、クライアントの動的登録 (安全な更新のみ有効にするオプションがあります)、レコードの自動清掃およびエージング、DHCP サービスの統合、増分マルチマスタ更新などがあります。 Windows 2000 Server DNS を使用する最大の利点は、DNS の複製および管理を別個の管理業務として分離し、DNS サービスを Windows 2000 Server オペレーティング システムに統合できることです。 注目すべき点は、Windows 2000 Server DNS に他の DNS サーバーとの相互運用性があることです。したがって、Berkeley Internet Name Domain (BIND) サーバーをセカンダリ DNS サーバーとして使用することもできます。
Windows 2000 Server の展開を計画する際には、最初の作業として以下の事項を明確化します。
現在、どのような DNS 名前空間があるか
現在どの DNS バージョンを使用しているか (BIND、Windows NT Server 4.0、Lucent QIP のいずれか)
DNS の管理は、どの技術グループが担当するか
外部名と異なる内部名が存在するか
Windows 2000 Server Active Directory 設計への影響
Active Directory をサポートするためには、使用する DNS が最低でもサービス ロケーション (SRV) リソース レコードをサポートしている必要があります (Request for Comments [RFC] 2052, "A DNS RR for Specifying the Location of Services")。 また、動的登録 (RFC 2136, "Dynamic Updates in the Domain Name System") もサポートする DNS の使用をお勧めします。Windows 2000 Server ドメイン コントローラと Windows 2000 Professional ワークステーションは、既定では A レコードを登録しようとするからです (動的ホスト構成プロトコル [DHCP] 提供のアドレス対応に設定した場合)。 さらに、増分ゾーン転送 (RFC 1995, "Incremental Zone Transfer in DNS") もサポートする DNS サーバーを使用するようお勧めします。これは、変更が発生したときに他の DNS サーバーの更新に必要となるネットワーク トラフィックと時間を削減するためです。
次の表に Active Directory DNS の要件を満たす主要なオプションを示します。
現在の DNS |
オプション |
長所 |
短所 |
|---|---|---|---|
Windows NT Server DNS |
|
|
|
|
|
|
|
BIND または QIP |
|
|
|
|
|
|
DNS 設計上の決定事項
DNS 設計の計画においては、以下の事項を決定する必要があります。
Active Directory を既存の名前空間に統合するか、それとも新たな委任 (corp.example.microsoft.com など ) を作成するか
どの DNS を Windows 2000 Server のサポートに使用するか
Windows 2000 Server DNS を使用する場合、ゾーンを Active Directory に統合するか
DNS ゾーンを Active Directory に統合する場合、安全な動的更新を有効にするか
Windows 2000 クライアントで A レコードおよび PTR レコードの自己登録を可能にするか
DHCP で Windows NT 4.0、Windows 95、Windows 98 などの前バージョンのクライアントを登録できるようにするか
RFC 1123 方式の DNS 名前付け規則 (A-Z、a-z、0-9、ハイフン) を必要とするか
Windows 2000 Server DNS を使用することには、他に次のような利点もあります。
既存の DNS サーバーに依存しない
他の DNS サーバーとの共存
DHCP 統合テストが不要
Windows NT のセキュリティ モデルに基づく安全な更新
マルチマスタ複製をサポートする (シングル マスタ DNS サーバーではない)
拡張文字セットをサポートする
レコード清掃をサポートする
ネットワーク インフラストラクチャのもう 1 つのコンポーネントとして、実際のネットワーク トポロジを定義する必要があります。 Windows 2000 Server では、管理者がネットワークの構成を定義でき、それによって Active Directory サイト (IP サブネットの集まり) やサイト リンクを作成できます。 Active Directory サイトとサイト リンクは、複製の最適化とクライアントのローカル認証において重要な役割を果たす要素です。また、クライアントがディレクトリに公開された Microsoft 分散ファイル システム (Dfs) のリンクやポインタなどのローカル リソースを使用するうえでも重要な働きをします。 これらはフォレスト全体で有効なネットワーク要素であるため、ディレクトリ対応のアプリケーションやサービスを新たに追加した場合、それらもサイト情報を使用できます。
以下の事項を確認し、書きとめてください。
ネットワークは完全にルーティングされているか
主要な接続ポイントはどこか
サイトの定義にはどのような基準を使用するか
主要なサイトをどのような種類のリンクで接続するか
小規模なサイトのユーザーをどのように接続するか
既存のドメイン コントローラはどこにあるか
リモート アクセス サービスをどのような方法でユーザーに提供するか
主要なサイトには何人のユーザーがいるか
ユーザーの場所から場所への移動はどのようなものになるか
ページのトップへ
フォレストの計画
Windows 2000 Server では、推移的な信頼関係で接続され、共通のスキーマ、構成、グローバル カタログを共有するドメイン ツリーの集まりをフォレストといいます。 最初に構築するドメインによってフォレストの開始ポイントが決まり、このドメインがフォレスト ルートとなります。
それ以降に作成するドメインは必ず次のいずれかとなります。
最初のドメインの子ドメイン (同じ名前空間)
そのフォレスト内で別のドメイン ツリーを構成する最初のドメイン (別の名前空間)
別のフォレストの最初のドメイン
フォレスト内のドメイン ツリーは、それぞれが 1 つの名前空間 (フォレスト ルートから継続しない) を定義します。 フォレストによって、1 つの企業で複数の名前空間 (エンティティ) を使うことができます。しかも、それらの名前空間は同じ Active Directory に属します。
フォレスト ルート ドメインは、いったん作成すると (Windows 2000 Server の現バージョンでは) 名前変更や削除ができないという意味で重要なものです。フォレスト ルート ドメインの名前変更や削除を行うと、フォレスト自体をクリアし、作成し直さなければならないからです。 フォレスト ルート ドメインにはこのような特殊性があるため、このドメインを保護および複製し、ドメインの可用性と回復性を保証する必要があります。
計画上の検討事項
フォレストの計画では、以下の点について検討し、結論の根拠を記述します。
フォレストをいくつ作成するか。 テスト用のフォレストを除き、複数のフォレストが必要となるのは、社内で共通の変更管理ポリシー (スキーマの変更など) を作成できない場合、完全な信頼モデル (推移的な信頼関係によって確立される) が不要である場合、または完全に独立した管理が必要な場合だけです。
複数のフォレストを作成すると煩雑になり、ユーザーがリソースにアクセスするときに手間がかかります。 Windows 2000 Server には、フォレスト間で自動的にオブジェクトの同期をとるプロセスが組み込まれていません (各フォレストが別々のグローバル カタログを持ちます)。 フォレスト間の信頼関係を有効にすることはできますが、信頼関係は明示的であって (Windows NT Server 方式) 推移的ではないため、ドメイン間に確立する必要があります。
Microsoft Exchange 2000 Server を使用する場合は、複数のフォレストを作成すると、単一 Exchange 組織を使用できなくなります。
フォレストの最初のドメイン (フォレスト ルート) には、Schema グループと Enterprise Administrators グループが属します。 これらのグループは、その機能がフォレスト内の他のドメインすべてに適用される特殊なグループです。
フォレストに名前を付けるときには十分な検討が必要です。合併や買収の可能性も考慮し、長期にわたって使用できる名前を選択してください。 Windows 2000 試用プログラムに参加した企業からの報告によると、フォレストが現在の社名にとらわれないように、社名の一部を使用した「プレースホルダ」ドメイン (adroot.example.microsoft.com など) をフォレスト ルートとして使用している企業もあるようです。 この方法では、Schema グループと Enterprise Administrators グループをそれぞれ固有のドメインに分けることができます。 このプレースホルダ ドメインは本質的に空です。ユーザー アカウントも公開された共有やプリンタなどのユーザー関連のオブジェクトも含まれていません。 ただし、プレースホルダ ドメインを使用するためには追加のハードウェアが必要であり、管理の負担も増えます。
Windows 2000 をいち早く導入した企業からの報告によると、複数のフォレストを必要とする企業は、他の企業のために Active Directory を運用するインターネット サービス プロバイダ (ISP) です。
「Building Enterprise Active Directory Services: Notes from the Field」に説明されているように、複数のフォレストを作成する場合は、最低でも、スキーマ、グローバル カタログ、セキュリティ、明示的な信頼関係、ドメインを各フォレストに定義する必要があります。
ページのトップへ
ドメインの計画
Windows 2000 Server のドメインは Windows NT Server 4.0 のドメインに似ていますが、機能が追加されています。 Windows 2000 のドメインには次のような特徴があります。
ディレクトリ名前空間を分割します。 フォレスト内の各ドメインがそれぞれ別のデータベースをホストし、各データベースにはドメインのオブジェクト (ユーザー、コンピュータ、プリンタなど) がすべて格納されます。これらのデータベースは同じドメイン内のドメイン コントローラにのみ複製されます。 このことが重要なのは、Active Directory が世界にまたがる 1 つのドメインにも、地理的な場所や職務に基づいて複数のドメイン パーティションを定義する高度分散モデルにも対応できるからです。
注
グローバル カタログ サーバーはオブジェクトをドメイン間で複製しますが、オブジェクトの属性は複製しません。セキュリティ ポリシーや認証の境界として機能します。
組織単位構造を含んでおり、Windows NT Server では複数のドメインを必要とする機能の委任が可能です。
DNS 名の他に NetBIOS 名も必要です。
計画上の検討事項
ドメインの計画では、以下の点について検討し、結論の根拠を記述します。
フォレスト内にドメインがいくつ必要か
ドメインの範囲を指定するために、地理的な境界とビジネス機能のどちらを使用するか。または両方を使用するか。
各ドメインに DNS 名と NetBIOS 名が必要です。 DNS の考え方は一意の名前付けを基礎としているため、インターネット上で解決されることがないドメインについても、登録されたドメイン名のみを使用するようお勧めします。
なぜ複数のドメインが必要なのか
複数のドメインが必要かどうかを判断する際には、以下の点を考慮してください。
Windows 2000 Server のドメインには、Windows NT Server ドメインの制約は当てはまりません。 Windows NT Server Security Accounts Manager (SAM) とは異なり、Active Directory は数百万のオブジェクトに対応でき、属性単位の複製とサイトという概念に基づいてネットワーク トラフィックを最適化します。
Windows 2000 で複数のドメインを作成する正当な理由としては、すべてのビジネス機能に同じセキュリティ ポリシー (パスワードの複雑さや変更の間隔など) を適用できない場合や、完全に独立した管理が必要である場合が考えられます。
Windows NT Server からアップグレードする場合は、既存のアカウント ドメイン モデルが有効であれば、統合する必要はありません (ただし、この点についてドメインを追加した場合のコストとの比較で検討することが必要です)。
ネットワーク トポロジによっては、オブジェクトとその属性 (ユーザー アカウントなど) がユーザーのローカル認証が行われない場所に複製されないように、Active Directory を物理的に分割するために複数のドメインが必要になることがあります。
各ドメインを作成するごとに、2 つ以上のドメイン コントローラが必要となり、Domain Administrators グループが有効となります。また、新たな信頼関係リンクが作成され、構成およびスキーマ名前付けコンテキストの複製が拡張されます。さらに、Knowledge Consistency Checker (KCC) がサイト トポロジを計算し接続オブジェクトを生成する際の時間が影響を受けることもあります。
地理的なドメイン設計
従来のディレクトリ サービス インフラストラクチャは地理的な境界上に構築されていました。その理由は単純で、ディレクトリ複製のトラフィックが最適化されることと、一般に地理的な境界に基づいて管理構造を決定することです。 多くのディレクトリ サービス インフラストラクチャが地理的な境界に基づいているのは、従来のディレクトリ サービス製品における特有の制約によるものです。 こうした製品の中には、拡張性がなく、厳密にネットワークと合致させなければならないものもありました。 Windows 2000 Server には、そのような制約はありません。
地理的なドメイン設計の問題点は、ビジネスに関する条件を考慮しない面があることです。 たとえば、世界規模の分散型企業であれば、地理的なインフラストラクチャ上で個々のコンテナとして表すことになります。 こうした地理的なドメイン設計では、管理や通信が無用に複雑化しがちです。 その一方で、各支店から構成される会社のように、地理的な構造を持つ企業もあります。 その場合は、地理的なドメイン設計が最適かもしれません。
長所 |
短所 |
|---|---|
|
|
ビジネス機能ドメイン設計
地理的な設計とは対照的に、ビジネス指向の設計は企業の機能単位と合致します。 ただし、ビジネス機能ドメイン設計では、その呼び方が示すとおり、組織運営上の理由から無用に複雑さを増すことがあります。 さらに、Active Directory の設計者は変更が多い企業の特性に配慮しなければなりません。 この設計では、企業の規模が大きい場合など、頻繁な組織の再編成に対応しきれません。 組織の再編成によって多くのディレクトリ オブジェクトを移動しなければならない場合、コストが増大する可能性があります。 場合によっては、既存のコンテナとしてドメインを使用するより、地理的なドメイン設計で組織単位 (製造、流通など) を使用する方が妥当です。
ビジネス機能ドメイン設計では、1 つの物理的な場所に複数のビジネス単位が存在するために、地理的なドメイン設計より多くのハードウェアが必要になることもあります。 そのようなビジネス単位を 1 つのドメインで表す場合には、そのドメインのドメイン コントローラを物理的な場所ごとに配置する必要が生じます。 その場所に複数のビジネス単位があれば、そこにも各ビジネス単位のドメインのドメイン コントローラを配置する必要があります。したがって、地理的なドメイン設計であれば 1 つのドメインで済むのに対し、2 つのドメインをサポートするハードウェアが必要になります。
このような危険もドメインのかわりに組織単位を使用することによって軽減できます。 それによって、両方のビジネス単位が同じドメインに属すため、そのドメインのドメイン コントローラだけで対応できます。
したがって、必然的にビジネス機能ドメイン設計を検討の対象外とする傾向が生まれます。 ただし、大企業では、多くの場合、ビジネス機能ドメイン設計を検討の対象から外すことはできません。 実際のところ、そのような設計がきわめて望ましい場合もあります。 大企業では、ビジネス単位の従業員が数万人に達することもあります。 たとえば、分散型の企業であれば、同じ組織に属していながら、ビジネス単位の間にコミュニケーションがほとんどないことがあります。 そのような場合、組織のビジネス モデルを正確に表現するうえで、ビジネス機能ドメイン設計が大いに役立ちます。
分散型の大企業では、ビジネス単位どうしの直接対話がほとんどなく、管理がビジネス単位ごとに独立していれば、ビジネス機能設計を選択し、コンテナとしてドメインを使用できます。 この場合、各ビジネス単位の情報をそれぞれの固有のドメイン コントローラに分割できます。 各ビジネス単位の情報は、それを使用することがないビジネス単位には複製する必要がないため、リソースの浪費を防ぐことができます。 さらに、多くの場合、ドメインに固有のセキュリティ境界はビジネス単位間のセキュリティ境界と一致します。
これまでの説明とは逆に、一部の企業では、サーバーと管理を統合し、リソースの共有とプールを進める傾向が強まっています。 このような要求と目標を達成するには、地理的なドメイン設計を選択するか、2 つの設計方法を併用する方が適しています。
長所 |
短所 |
|---|---|
|
|
地理的なドメイン設計とビジネス機能ドメイン設計の併用
これまで紹介したモデルについて説明したとおり、多くの企業では地理的なドメイン設計とビジネス機能ドメイン設計の併用が必要となります。 この併用方式は、ビジネス単位ごとの管理が必要な一方でコンピューティング リソースの一部を地域コンテナに集める場合の妥協策です。
通常、この設計は管理上の理由から導入します。 グループやコンテナの全部または一部をそれぞれに異なるスタッフが管理します。 管理方法に基づいて管理の委任を設定します。
長所 |
短所 |
|---|---|
|
|
どのドメイン モデルが最適か
言うまでもなく、この問いに対する答えは企業によって異なります。 問題は、最適なモデルを見いだし、定義することです。 まず始めに、現在のドメイン設計を検証し、社内のビジネス設計と比較します。 最適化が必要な部分はあるか、 近いうちに合併や買収によって変更が発生する可能性はあるか、などについて検討します。 ドメイン計画では、段階的なアプローチを採用し、複数のステップを必要とするエンドポイント設計を定義します。
実際にいくつのドメインが必要か
Windows NT Server から Windows 2000 Server に移行する企業では、1 つのドメインが望ましいにもかかわらず、複数のドメインからなる Active Directory 環境を設計するという決定にいたることがあります。 ここでは、こうした決定がなされる背景について例を挙げて説明します。 いずれの場合も、ドメイン設計計画において特定のアプローチを選択した理由を明らかにしなければなりません。 必ず始めに単一ドメインについて検討し、複数のドメインが必要となる場合の設計オプションをすべて考慮に入れてください。
Windows NT Server からの移行
プラットフォームの移行はドメイン計画を作成するうえで大きな役割を果たします。 その大きな理由は、Windows 2000 Server を早期に導入した企業の多くが、フォレストを一から定義するのではなく、同一場所でのアップグレード方法を選択したことにあります。 同一場所でのアップグレード方法を使用する場合、前のプロジェクトで既存の Windows NT Server アカウント ドメイン構造を統合していなければ、Windows 2000 Server のドメイン設計は以前と変わっていないように見えます。 このシナリオは段階的なアプローチへと容易に結びつき、次のステップではアップグレード済みのアカウント ドメインを 1 つの Windows 2000 Server ドメインに統合します。 フォレスト内でセキュリティ原則を移動するのは簡単です。既存のセキュリティ識別子 (SID) が保持されるからです。
ネットワークおよび複製の分割
大企業では、必要なオブジェクト数に Windows 2000 Server が対応できるとしても、単一ドメインを使用したがらないものです。 リスクの面から、インフラストラクチャ全体を 1 つのドメインに置くことを避けようとします。 単一ドメインで事が起きると、組織全体が機能不全に陥りかねません。 また、大企業ではデータをいたるところに複製することも避ける必要があります。特に、データの大部分を必要としない場所への複製は望ましくありません。 ドメイン コントローラのディスク容量を拡張する必要が生じるだけでなく、正式の復元に要する時間が長くなる可能性もあります。 逆に、グローバル カタログのドメイン数は少なくなり、その結果、グローバル カタログがあるドメイン コントローラのオーバーヘッドは小さくなります。 単一ドメイン モデルでは、すべてのドメイン コントローラをグローバル カタログ サーバーにすることができます。
セキュリティ上の問題
セキュリティ上の要求から複数ドメイン モデルへと到達する場合もあります。 2 つのビジネス単位が完全には信頼しあっていない場合、それらの間にセキュリティ境界が設定されることがあります。 また、ビジネス単位または組織単位に許可を委任できる集中的な強い管理権限が存在しない場合もあります。 こうした場合には、ドメインを使ってビジネス単位を表現した方がどちらかと言えば妥当です。 このようなドメイン設計の方が、ビジネス単位間のセキュリティ境界が強固になります。 また、ビジネス単位が固有のドメインを「所有」するため、ビジネス単位に管理権限を与えることができます。 管理権限の委任は中央の権限には依存しません。
再編成についての考慮点
上記のような要求事項がない企業では、単一ドメイン モデルの簡素さが評価されます。 もちろん、もっと複雑なモデルが適した企業にとっても、単一ドメイン モデルの簡素さは大きなメリットとなります。 このメリットが特に顕著となるのは、大規模な再編成を頻繁に行う企業においてです。 そうした企業の再編成では、ドメイン境界を越えて多くのオブジェクトを移動する必要があります。 Microsoft やその他のサードパーティ ベンダは、ユーザーをドメイン間で簡単に移動できるユーティリティを提供しています。
ページのトップへ
組織単位の計画
組織単位は、最も柔軟性の高い Active Directory 設計要素です。 組織単位は汎用コンテナであり、それによってほとんどのオブジェクト クラス (ユーザー、コンピュータ、プリンタなど) を管理目的 (管理作業の委任やグループ ポリシーの適用など) でグループ化することができます。 組織単位は、企業の設計要素を Active Directory インフラストラクチャにマップします。 さらに、組織単位を使用して、Windows NT Server 4.0 でリソース ドメインとして提供された機能やオブジェクトを表現し、グループ化することもできます。 Active Directory への移行時に、Windows NT Server リソース ドメインが組織単位階層に組み入れられます。
組織単位は変更および構成管理プロセスの作成に欠かせない要素です。オブジェクトには、その階層内の位置に基づいて定義済みの設定が適用されるからです。
「ドメインの計画」の場合と同様、組織単位の設計もいくつかのカテゴリに分かれ、ただ 1 つの最良の設計方法というものはありません。 ただし、組織単位の場合もドメインを計画する場合と同じようなプロセスをたどります。 たとえば、企業の主要な帰属単位がビジネス単位である場合は、ビジネス単位によってドメイン境界が定義されます。 これらのビジネス単位内では、物理的な場所が二次的な帰属単位を表します。 この場合、次のように地理的な条件によってドメイン内の組織単位モデルが定義されます。
フラットモデル - 単一レベルで最小限のネストで構成される組織単位設計
ネスト化モデル - ネスト順は各レベルに指定されたオブジェクトによって定義されます。
地理的モデル - 地域に基づく組織単位設計
ビジネス / 機能モデル - ビジネスグループに基づく組織単位設計
ハイブリッドモデル - 地理的な境界とビジネス機能を融合し、フラットモデルとネスト化モデルを併用して実装する組織単位設計
組織単位計画プロセス
組織単位の設計には高度の機能性が求められます。現在の組織図をモデル化するのではなく、「バランスのとれた」組織単位設計をめざす必要があります。 各コンテナの存在意義を検証します。 組織単位設計に着手するときには、まず Windows NT Server リソース ドメインが現在どのように使用されており、それらをどのように組織単位として再作成できるかを検討します。 あるいは、管理方式の検討から始めることもできます。 ユーザーの大部分が対象となる管理モデルが集中モデルなのか分散モデルなのかを明らかにします。
入念に設計された組織単位となるように、以下のことを行ってください。
組織単位構造の第 1 レベルを定義します。
たとえば、ビジネス機能、サイト、地域などを組織単位の第 1 レベルとします。
組織単位構造の第 2 レベルを定義します。
たとえば、プリンタ、コンピュータ、ユーザーなどのオブジェクトを収容するコンテナを作成します。
組織単位構造の第 3 レベルを定義します。
たとえば、どのコンテナを第 3 レベルに位置づけるかを決定します。
組織単位のネスト レベルに制限はありませんが、5 レベルまでとすることをお勧めします。 この制限は、あくまでも作業上の推奨事項であり、技術的な限界を示すものではありません。
次の図に組織単位計画の実例を示します。
.gif "actdir01")
第 1 レベル :
地域 - LAN トポロジによって定義される地理的な地域
サーバー - 複数の地域にまたがるエンタープライズ レベルのサーバー
ユーザー - 組織内の全ユーザー
GPO - グループ ポリシー オブジェクトを収容する。 グループ ポリシーの利用は、すべてこの 1 つの場所からリンクされます。
第 2 レベル - Regional の下位 :
ローカルサイト - サイトコードによって定義されます。
サーバー - 地域のサーバー
第 3 レベル - ローカル サイトの下位 :
コンピュータ - コンピュータ アカウント
サーバー - ローカルサーバー
プリンタ - サイト プリンタ
ページのトップへ
サイト トポロジの計画
Active Directory では、サイトという概念を使用してネットワークを定義します。 この定義 (IP サブネット グループのマッピング) がサーバーとクライアントで使用されることによって、個々のプロセスがローカルで実行されます。 こうしたプロセスの例としては、次のようなものがあります。
クライアント認証 (必ずローカル ドメイン コントローラが使用される)
ドメイン コントローラ間の複製
分散ファイル システム (Dfs) 複製
プリンタの検索
作成したサイト定義は、フォレスト内のすべてのドメインで構成名前付けコンテキストとして共有されます。 複数のドメインが 1 つまたは複数の定義済みサイトにまたがることもできます。
サイト計画プロセス
サイト計画プロセスでは、最初に何をサイトと見なすかを定義します。 サイトの例として、ビル全体、構内、地域などがあります。 Active Directory では、サイトに良好な (高速で信頼性の高い) ネットワーク接続が必要です。
主要なサイトを定義したら、それをもとにドメイン コントローラとサービス (グローバル カタログ サーバー、DNS、DHCP、Dfs など) を配置します。 次に、サイト間の複製を可能にするためにサイトどうしを結ぶリンクを作成します。
Active Directory には「サイト範囲」という概念もあります。これは、ドメイン コントローラを持たないサイト内のクライアントが自動的に適切なサイトによって認証されるというものです。 支店などでは、ドメイン コントローラのないサイトを定義することがあります。
注
ユーザー基盤をサポートするために必要なドメイン コントローラ数を求めるには、Active Directory Sizer が役に立ちます。このツールは Windows 2000 Web サイト https://www.microsoft.com (英語) からダウンロードできます。
次に、以下の点について検討し、結論を出します。
推移的なサイト リンクを使用するか - 既定では、サイト リンクは推移的です。 特殊なケース (ルーティングされていないネットワークなど) では、サイト間の接続にサイト リンク ブリッジが必要となることがあります。
KCC 作成の接続オブジェクトを使用するか - ほとんどの場合は、Knowledge Consistency Checker を使用してドメイン コントローラ間の接続を自動作成することをお勧めします (サイト内およびサイト間の両方について)。
グローバル カタログ、ドメイン コントローラ、ブリッジヘッド サーバー、DNS の配置 - サイト計画では、グローバル カタログ サーバー、ブリッジヘッド サーバー (手動で作成した場合)、ドメイン コントローラ、DNS サーバーの位置を必ず指定します。
サイト リンクのスケジュール、名前付け、コスト - サイト計画には、サイト リンクの名前付け規則 (通常は site_name - site_name と指定)、サイト リンクを有効にするスケジュール (既定では 180 分)、およびコスト モデルを指定します。 既定のコスト モデルは値 100 です。 接続速度に基づいて値のマトリックスを先に作成することをお勧めします。
伝送方法 (IP か SMTP か) - 既定の伝送方法は IP です。 特殊なケースでは、実装を明確に把握している特定の構成において SMTP を使用できます。
サイト間の通知を有効にするか - 既定では、スケジュールに従ってサイト間の複製が行われます。 このサイト間の複製に対応するものとして、1 つのサイト内のドメイン コントローラ間で行われる複製があります。 サイト内の複製には変更通知が使用されます (変更は蓄積され、5 分おきに取り出されます)。 サイト通知によって、複数のサイトが 1 つの大きなサイトとして機能することを (サイト リンク単位で) 指定できます。 たとえば、2 つのサイト間の接続 (Synchronous Optical NETwork [SONET] リングなど) が非常に良好でありながら、それぞれ別個のサイトとして扱い、クライアント中心の機能 (認証でのローカル ドメイン コントローラの使用、 ローカル Dfs 複製の使用、ローカル プリンタの検索など) でサイト情報という概念を利用する必要がある場合などは、サイト通知を利用できます。
ページのトップへ
詳細情報
Active Directory の最新情報については、以下の資料を参照してください。
導入計画ガイド (英語)
注
このページに示された URL は、本来はそれぞれ 1 行に収まるべきものです。しかし、読みやすさを考慮して 2 行にわたっているものもあります。
このドキュメントは暫定版であり、このドキュメントに記載されている情報は、このドキュメントの発行日におけるマイクロソフトの見解を示すものです。マイクロソフトは市場の変化に対応する必要があるため、このドキュメントの内容に関する責任をマイクロソフトは問われないものとします。また、発行日以降に発表される情報の正確性を保証できません。
このドキュメントに記載されている内容は情報の提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。
（この文書で例として挙げられている企業、その他の組織、製品、職業、イベントは、仮想のものです。それらが、いずれかの実際の企業、組織、製品、人物、またはイベントを指していることはなく、そのように解釈されるべきではありません。 本書は、情報の通知のみを目的としており、マイクロソフトは本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。 ）
適用し得るすべての著作権法を順守する責任はユーザーにあります。 本書中のいかなる部分も、Microsoft の書面による許可なしには、いかなる目的のためであれ、いかなる形態、手段 (電子的、機械的、コピー機の使用、記録など) によっても複製、検索システムへの格納、または伝送してはなりません。
この文書の内容に関する特許、特許出願、商標、著作権、およびその他の知的財産は、マイクロソフトが所有します。 マイクロソフトとの書面によるライセンス契約に明記されていない限り、本書の提供が、以上の特許、商標、著作権、あるいはその他の知的財産権の利用を認めるものではありません。
© 2000 Microsoft Corporation. All rights reserved.
Microsoft、Active Directory、Windows、および Windows NT は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
この文書に登場する実在の企業名や製品名は、各所有者の商標である場合があります。
ページのトップへ