Windows 2000 システム展開ガイド

  • [アーティクル]

第 10 章 ‐ ドメイン移行方針の決定

Microsoft® Windows NT® 3.51 (以下 Windows NT 3.51) および Microsoft® Windows NT 4.0 (以下 Windows NT 4.0) を Microsoft® Windows® 2000 (以下 Windows 2000) に適切に移行するには、現在のシステムを慎重に解析し、詳細な計画を作成する必要があります。アップグレード プロセスの論理設計に関わるネットワーク エンジニアは、この章で説明する推奨される設定と手順をよく理解しておかなければなりません。ここで説明する推奨事項は、比較的小規模な企業にも適用できますが、特に 2,500 台以上のパーソナル コンピュータを持つ企業を対象にしています。

この章では、ドメインのアップグレードと再構成、Windows NT ドメインのアップグレードによる Microsoft® Active Directory™ (以下 Active Directory) ディレクトリ サービスのネームスペースの計画について説明するため、Active Directory のネームスペースの計画は、ほぼ完了していなければなりません。また、この章を始める準備として、Windows 2000 に展開できる機能、企業への展開目的、企業の現在のドメイン モデル、および現在のネットワークを設定するハードウェアとソフトウェアについて理解しておく必要があります。

トピック

移行計画プロセスを開始する
ドメイン アップグレードを計画する
ドメインの再構成を計画する
ドメイン移行ツール
移行計画の作業リスト

この章の目的
この章では、次の計画書を作成します。

  • 移行プロジェクトのロードマップ

  • Active Directory のネームスペースの改訂計画文書

  • ドメイン移行計画

Resource Kit の関連情報

  • Active Directory、ドメイン ネーム システム (DNS) のネームスペースの設計、サイト トポロジ、またはグループの詳細については、このマニュアルの「第 9 章 Active Directory 構造の設計」を参照してください。

  • Windows 2000 Server の自動インストールの詳細については、このマニュアルの「第 13 章 サーバーの自動インストールと自動アップグレード」を参照してください。

  • Windows 2000 Professional の自動インストールの詳細については、このマニュアルの「第 25 章 クライアントの自動インストールと自動アップグレード」を参照してください。

移行計画プロセスを開始する

ドメイン アップグレードまたは再構成を始める前に、計画プロセスを理解しておくことが重要です。

メモ この章で説明する手順および提案は、非複製コンピュータのアップグレードに基づいています。Windows 2000 Server にアップグレードできるのは、現在 Windows NT Server 3.51 および Windows NT Server 4.0 を実行しているコンピュータだけです。これより古いバージョンは、Windows 2000 Server にアップグレードできません。この章で使用する "Windows NT" という用語は、Windows NT Server Version 3.51 および 4.0 を指しています。

プロセスの各フェーズを計画する

ドメインを移行するための計画プロセスは、次のフェーズで構成されます。

  1. Windows 2000 フォレストを設計します。Windows 2000 フォレストの設計方法の詳細については、このマニュアルの「第 9 章 Active Directory 構造の設計」を参照してください。

  2. Windows NT ドメインの Windows 2000 のネイティブ ドメインへの移行を計画し、Windows 2000 Server の新機能を展開します。

  3. Windows 2000 ドメインの再構成を計画します。

    このフェーズは、企業によって必要ない場合も、後で行うのが適切な場合もあります。ドメインの再構成方法の詳細については、この章の後の「ドメインの再構成を計画する」を参照してください。

図 10.1 に、Windows 2000 Server に移行するために必要な基本手順を示します。この章では、最初の計画フェーズからドメインのアップグレードと再構成に必要な作業まで、各手順を詳しく説明します。

sdgc1001

図 10.1: 移行計画のフローチャート

移行ロードマップを決定する

計画プロセスでは、重要な決定を下し、これを具体化していきます。移行計画で何を選択するかによって、一部のシステム機能の展開を後日まで延期しなければならない場合があります。移行ロードマップを作成する最初の手順では、移行目標を特定して優先順位を付け、選択した移行プロセスが及ぼす影響を理解します。

Windows 2000 への移行を決定したときに、展開する機能および利点を特定しました。ここでは、一般的な移行目標を取り上げ、それぞれの目標の主な概念と影響について説明します。これを終了すると、移行プロジェクトのロードマップを完成させるために必要な情報を獲得することができます。

移行目標
移行計画には、主な移行目標を反映させる必要があります。移行目標には、ビジネスに関連した目標と、移行自体に関連した目標があります。

多くの場合、ビジネス関連の目標から、移行の基本的な決定が導かれます。たとえば、スケーラビリティの向上およびセキュリティの改善がこれに当たります。ビジネス関連の目標は、何を導入するかを選択するときに考慮し、可能性のあるトレードオフを評価するときに使用できます。通常は、何らかの準拠表を準備して、後で最終的なプラットフォームに導入するテクノロジと製品機能を特定するときに使用します。これらのテクノロジおよび機能は、ビジネス関連の目標を達成する上で役立ちます。

移行関連の目標では、業務システムへの悪影響、最終的なシステム パフォーマンス、故障間の時間を延長する方法などを考慮します。これらの目標から、どのようにテスト計画と許容基準を作成すれば良いかを決めることができます。

移行関連の目標は、Windows 2000 Server の特定の技術的機能を導入する必要性から導かれるわけではなく、移行プロセスそのものが関係します。表 10.1 に、移行関連の目標の例を示します。

表 10.1 移行関連の目標

目標

移行プロセスの影響

業務環境への悪影響を最小限に抑える。

移行中および移行後、データ、リソース、およびアプリケーションへのユーザー アクセスを維持する必要があります。
ユーザーの使い慣れた環境は、移行中および移行後にも維持されなければなりません。

システム パフォーマンスを維持する。

移行中および移行後、データ、リソース、およびアプリケーションへのユーザー アクセスを維持する必要があります。
ユーザーの使い慣れた環境は、移行中および移行後にも維持されなければなりません。

故障間の時間を縮小する。

移行中および移行後、データ、リソース、およびアプリケーションへのユーザー アクセスを維持する必要があります。
ユーザーの使い慣れた環境は、移行中および移行後にも維持されなければなりません。

管理オーバーヘッドを最小限に抑える。

ユーザー アカウントをシームレスに移行する必要があります。

 

可能な場合には、ユーザーが各自のパスワードをそのまま維持できなければなりません。

 

管理者がクライアント コンピュータを訪れる回数は、最小限に抑えなければなりません。

 

リソースへの新しいアクセス許可の設定は、最小限に抑えなければなりません。

"quick wins(先手必勝)" を最大化する。

企業は、新しいプラットフォームの主要機能に最短の方法でアクセスする必要があります。

システムのセキュリティを維持する。

セキュリティ ポリシーへの影響を最小限に抑える必要があります。

Windows 2000 のテクノロジの利点を最大限に利用し、移行関連の目標をすべて理解するには、できるだけ早く Windows 2000 ドメインをネイティブ モードに切り替えることをお勧めします。ただし、既存ネットワークの設定によっては、ドメインからすべての Windows NT バックアップ ドメイン コントローラ (BDC) を排除するまで、ネイティブ モードに切り替えられない場合があります。ネイティブモードの定義については、この章の後の「ネイティブ モードに移行するタイミングを決定する」を参照してください。

Windows 2000 クライアントおよびメンバ サーバーは、ドメイン インフラストラクチャをアップグレードする前でも展開できます。詳細については、この章の後の「クライアントとサーバーをアップグレードする」を参照してください。

移行の概念
目的のインフラストラクチャには、次の 2 とおりの方法で到達できます。

  • ドメイン ** アップグレード – "インプレース アップグレード" または "アップグレード" とも呼びます。

    ドメイン ** アップグレードは、Windows NT ドメインのプライマリ ドメイン コントローラ (PDC) と BDC を Windows NT Server から Windows 2000 Server にアップグレードするプロセスです。

  • ドメインの再構成 ; "ドメインの集約" とも呼びます。

    ドメインの再構成は、ドメイン構造を完全に再設計し、通常は少数の大規模なドメインにするプロセスです。これは、現在のドメイン構造に不満を持っているか、アップグレードによる業務環境への重大な影響を回避できない場合の選択肢です。

アップグレードと再構成は、相互に排他的ではありません。まず、アップグレードしてから再構成することも、最初から再構成することもできます。どちらの場合も、行う前に慎重に考慮し、計画する必要があります。

クライアントとサーバーをアップグレードする
この章では、ドメインのアップグレードと再構成について説明しますが、ドメイン インフラストラクチャをアップグレードするまで、Windows 2000 クライアントおよびメンバ サーバーを配置できないわけではありません。既存の Windows NT 環境で Windows 2000 クライアントとサーバーを使用しても、新しいテクノロジから多くの利点を得ることができます。表 10.2 に、クライアントとサーバーを Windows 2000 にアップグレードすることにより得られる利点を挙げます。

表 10.2 単純なクライアントまたはサーバーのアップグレードによる利点

利点

機能

管理性

プラグ アンド プレイ

 

デバイス マネージャのハードウェア ウィザード

 

USB (ユニバーサル シリアル バス) のサポート

 

Microsoft 管理コンソール

 

新しいバックアップ ユーティリティ

セットアップ ツールとトラブルシューティング ツール

アプリケーションの自動インストールでは、ユーザーまたはユーザー グループが常に使用できるようにする一連のアプリケーションを指定できます。要求されたアプリケーションを必要なときに使用できない場合、システムに自動的にインストールされます。

ファイル システムのサポート

NTFS 5.0 では、ディスク クォータのサポート、ディレクトリ構造の最適化、およびディスク I/O の圧縮が改善されています。

 

FAT32

アプリケーション サービス

Win32® ドライバ モデル

 

DirectX® 7.0

 

Windows スクリプト ホスト

情報の共有と発行

Windows 2000 Server 用の Microsoft 分散ファイル システム (Dfs) では、ユーザーがネットワーク上のデータを簡単に検索および管理できます。

 

統合インターネット シェル

プリント サーバー サービス

インターネットから Active Directory プリンティングを通じて簡単にプリンタを検索できます。

スケーラビリティとアベイラビリティ

対称型マルチプロセッサのサポートが改善されています。

セキュリティ

ファイル システムを暗号化します。

ドメイン移行の考慮事項

ここでは、移行のために必要となる重要な計画と準備を行います。正確な手順はそれぞれの計画プロセスで決まりますが、ここでは考慮する必要のある内容について説明します。

アップグレードの決定

ドメインのアップグレード方法を決めるときには、次の内容について考慮してください。

  • アップグレードが適切かどうか。

    次の条件に当てはまるものがある場合には、アップグレードするのが適切です。

    • 現在のドメイン構造に満足しています。

    • ドメイン構造にほぼ満足しており、Windows 2000 へのアップグレード、および問題解決のための再構成の 2 フェーズの移行を遂行できます。

    • 業務環境に影響を与えずに、移行できると考えています。

  • どの順序でアップグレードするか。

    アップグレードする順序は、ドメイン コントローラのアップグレード順に従うか、ドメインのアップグレード順に従うかによって異なってきます。

  • どの順序でドメイン コントローラをアップグレードするか。

    ドメイン内のアップグレード順序は単純です。まず、PDC をアップグレードします。このとき、アップグレード対象のドメインで LAN Manager 複製サービスを使用するなど、エクスポート ディレクトリを処理する PDC が複雑になる可能性を認識しておかなければなりません。この場合、PDC をアップグレードする前に、エクスポート ディレクトリ ホストを変更しておきます。LAN Manager 複製サービスの詳細については、この章の後の「LAN Manager 複製サービスのプロセス」を参照してください。

  • どの順序でドメインをアップグレードするか。

    最初にアカウント ドメインをアップグレードすると、管理および委任が簡単になります。次に、リソース ドメインをアップグレードします。

  • どの順序でサーバーおよびクライアントをアップグレードするか。

    サーバーとクライアントは、いつでもアップグレードでき、Windows 2000 のインフラストラクチャに左右されません。

  • いつドメインをネイティブ モードに切り替えるか。

    より優れたディレクトリのスケーラビリティ、ユニバーサル グループとドメイン ローカル グループ、グループのネストなど、Windows 2000 の機能をすべて利用するには、できる限り早急にドメインをネイティブ モードに切り替える必要があります。

メモ すべてのドメイン コントローラのアップグレードが完了するまで、ドメインをネイティブ モードに切り替えることはできません。

再構成の決定

ドメインを再構成するかどうか、またその方法を決定するときには、次の内容について考慮してください。

  • 再構成が必要かどうか。

    次の条件に当てはまるものがある場合には、再構成が必要です。

    • ドメイン構造にほぼ満足しており、Windows 2000 へのアップグレード、および問題解決のための再構成の 2 フェーズの移行を遂行できます。

    • 現在のドメイン構造に不満を持っています。

    • 移行による業務環境への影響を回避できないと考えています。

  • いつ再構成が必要か。

    再構成が必要なタイミングは、再構成する理由によって異なります。

    • 2 フェーズによる移行で移行の要件を解決できる場合には、アップグレード後に再構成します。

    • 現在のドメイン構造をそのまま利用できない場合には (たとえば、Active Directory の改善機能を利用するには、ディレクトリ サービス インフラストラクチャを再設計する必要がある場合)、移行プロセスの最初に再構成を行います。

    • 業務環境への影響を回避できない場合には、移行プロセスの最初に再構成を行います。

メモ アップグレードの完了後、アプリケーションの展開、新しいグループ ポリシーなどの機能を使用する前に、再構成することをお勧めします。これらの機能を使用してから再構成すると、移行プロセスの最初に再構成するよりも複雑になることがあります。

アプリケーションの互換性
ドメイン全体の移行方法を決定したら、使用している業務アプリケーションに Windows 2000 との互換性があるかどうかを判断することが重要です。これは、適切な配置に不可欠な手順で、アプリケーション サーバーをいつどのように移行するかを決定する前に行わなければなりません。方針アプリケーションを特定したら、これらのアプリケーションをテスト計画に組み込みます。方針アプリケーションは、移行プロセスを開始する前に、すべてテストしておかなければなりません。アプリケーション サーバーの移行の詳細については、このマニュアルの「第 15 章 メンバ サーバーのアップグレードとインストール」を参照してください。

アプリケーションについて、次の内容を明確にしておくことが重要です。

  • アプリケーションを Windows 2000 で実行できるか。

    実行できない場合、アップグレード計画に影響することがあります。

  • アプリケーションを BDC で実行する必要があるか。

    アプリケーションを BDC で実行する必要があり、Windows 2000 で実行できない場合、アップグレード済みのドメインをネイティブ モードに切り替えるのが困難になります。

  • アプリケーションのソフトウェア ベンダに問い合わせ窓口があるか。

    アプリケーションを Windows 2000 で実行して問題が起こった場合、アプリケーション ベンダの Windows 2000 のサポート計画を認識しておく必要があります。

  • 社内で開発したアプリケーションの場合、Windows 2000 対応版を開発する計画があるか。

    アプリケーションを Windows 2000 で実行できない場合、Windows 2000 をサポートするための計画について認識しておく必要があります。

  • クライアントとサーバーに展開されているオペレーティング システムは何か。

    オペレーティング システムによっては、移行パスに影響することがあります。Windows 2000 へのアップグレード パスがサポートされていないソフトウェアがあります（たとえば、Windows NT 3.5)。

メモ Windows NT 3.51 では、ユニバーサル グループまたはドメイン ローカル グループのメンバーシップがサポートされないため、リソース ドメインに Windows NT 3.51 サーバーを残したくない場合があります。Windows NT 3.51 では、Windows 2000 ドメイン間で移動したユーザー アカウントの SIDhistory 機能が認識されません。

これらの内容を明確にしておくと、重要な問題を網羅したテストを作成できます。また、提案されている移行を含み、正常に動作しないさまざまなアプリケーションの影響を詳細に示すプロジェクトのリスク評価を開発することもできます。

業務アプリケーションのテストの詳細については、このマニュアルの「第 21 章 アプリケーションの Windows 2000 互換性テスト」を参照してください。

メモ Windows NT ルーティングとリモート アクセス サービス (RRAS) など、Windows NT 用に設計されている一部のアプリケーション サービスは、ユーザー アカウント情報への未認証アクセスが前提となっています。Active Directory の既定のセキュリティ許可では、アカウント情報への未認証アクセスは許可されません。Active Directory インストール ウィザードには、アクセス許可を追加付与して、Active Directory のセキュリティの互換性を設定できるオプションがあります。Active Directory のセキュリティを緩和して RRAS サーバーの使用を許可すると、セキュリティ ポリシーに危害が及ぶ可能性がある場合は、RRAS サーバーを最初にアップグレードする必要があります。

LAN Manager 複製サービスを使用してドメイン内のスクリプトを複製する場合、エクスポート ディレクトリを処理するサーバーを最後にアップグレードする必要があります。

相互運用性の要件
次に、Windows 2000 システムを、従来の Windows システムおよび Microsoft 以外のオペレーティング システムと相互運用させる必要がある範囲を考慮します。Windows 2000 以外のネットワーク オペレーティング システムが含まれる異種環境を維持する場合には、すべてのプラットフォームで受け入れ可能な機能を維持するために、従来のアプリケーションおよびサービスのどれをそのまま維持し、どれをアップグレードしなければならないかを判断する必要があります。

相互運用性について、次の 2 つの内容について考慮します。

  • 異種環境での運用について、どのような相互運用性の要件があるか。

    これには、移行後の環境で、他のオペレーティング システムおよびネットワーク サービスとの間で必要になる相互運用性の程度が含まれます。

    重要な考慮事項には、次のものがあります。

    • Windows 2000 以前のクライアントを維持する必要性。ネーム解決をサポートするには、Windows インターネット ネーム サービス (WINS) などのサービスを維持するように計画しなければなりません。

    • Windows 2000 以前のドメインを維持する必要性。明示的な信頼を維持および管理する必要があります。

    • UNIX など Microsoft 以外のオペレーティング システムと相互運用する必要性。この理由から、Kerberos 認証を幅広く使用できるように、迅速に移行を行うことがあります。

  • ソース環境について、どのような相互運用性の要件があるか (何から移行するか)。

    移行中の環境は管理が複雑になることがあるため、次に説明するように慎重に計画する必要があります。

Active Directory オブジェクトのディスク記憶域の要件
移行計画の早い段階で、Active Directory がオブジェクトの格納に必要とするディスク容量を考慮することが重要です。必要な合計ディスク容量は、Windows 2000 フォレストのサイズによって異なります。このフォレストの設計の詳細については、このマニュアルの「第 9 章 Active Directory 構造の設計」を参照してください。

表 10.3 に、Active Directory の各オブジェクト タイプで必要になるディスク容量を示します。

表 10.3 Active Directory オブジェクトに必要なディスク容量

オブジェクト

必要なディスク容量 (バイト)

ユーザー オブジェクト

3.6 K

組織単位 (OU) オブジェクト

1.1 K

属性 (10 バイト)

100

公開キー証明書 (Windows 2000 証明書サービスで発行される X.509 v3 証明書)

1.7 K

ドメイン アップグレードを計画する

ドメインの移行に関連する問題を考慮して、発生する問題を解決する計画を作成したら、実際のアップグレード プロセスを計画することができます。

メモ アップグレードを計画する前に、Windows 2000 フォレストの設計を完了しなければなりません。このフォレストの設計の詳細については、このマニュアルの「第 9 章 Active Directory 構造の設計」を参照してください。

ドメイン ** アップグレードは、Windows NT ドメイン内の PDC と BDC を Windows NT Server から Windows 2000 Server にアップグレードするプロセスです。アップグレードでは、システム設定、環境設定、およびインストール済みプログラムのほとんどがそのまま維持されるため、最も簡単でリスクの少ない移行手段です。

Windows 2000 Server では、最大限の相互運用性で混在ネットワークがサポートされるため、ドメイン内のサーバーをすべてアップグレードしなくても、Windows 2000 の機能を利用できます。PDC のアップグレードは、単にプロセスの最初の段階と考えてください。BDC およびメンバ サーバーをアップグレードすると、さらに多くの利点を得ることができます。

移行プロセスは、新たなインストールではなく、オペレーティング システムをアップグレードするため、Windows 2000 の機能を有効にしても、既存のドメイン構造、ユーザー、およびグループはそのまま維持されます。アップグレードを完了し、高度な Windows 2000 の管理ツールおよび機能を利用できるようになった時点で、ドメインの再構成について考慮する場合があります。ただし、ドメインの再構成は単純な作業ではありません。構造の変更が目標に含まれている場合には、アップグレード後ではなく、移行の初期段階でドメインを再構成することを考慮してください。どちらにしても、作業を進める前に両方の選択肢を慎重に検討してください。

ドメイン アップグレードには、次の特長があります。

  • 既存の Windows NT の信頼関係を通じた Windows NT ドメインへのアクセスが維持されます。

  • Windows NT サーバー、Windows 95 および Windows 98 クライアントへのアクセスが維持されます。このアクセスは、クライアント コンピュータのユーザーに対して透過的です。

  • ユーザー アカウントのパスワードが維持されるため、ユーザーは同じパスワードで同じアカウント ドメインにログオンできます。

アップグレードを計画するときには、次の作業を行う必要があります。

  • サポートされているアップグレード パスを判断します。

  • 既存のドメイン構造を検証します。

  • 回復計画を開発します。

  • ドメインのアップグレード順序を決定します。

  • ドメイン コントローラのアップグレード方針を決定します。

  • ネイティブ モードに切り替えるタイミングを決定します。

メモ クライアントをアップグレードする前に、サーバー インフラストラクチャを Windows 2000 Server にアップグレードする必要はありません。また、ドメイン コントローラをアップグレードする前に、クライアントとメンバ サーバーをアップグレードすることもできますが、ドメイン コントローラをアップグレードするまで Active Directory の機能を利用できなくなります。

サポートされているアップグレード パスを判断する

アップグレードを計画するときに、現在のオペレーティング システムを直接 Windows 2000 にアップグレードできるかどうかを判断しなければなりません。表 10.4 に、現在サポートされているアップグレード パスの一覧を示します。オペレーティング システムを直接アップグレードするパスがサポートされていない場合、まず、クライアントのオペレーティング システムを Windows 95、Windows 98 などにアップグレードするか、クライアントとサーバーを Windows NT にアップグレードする必要があります。この中間的な手順をアップグレード計画に反映させてください。

メンバ サーバーのアップグレードの詳細については、このマニュアルの「第 15 章 メンバ サーバーのアップグレードとインストール」を参照してください。

表 10.4 サポートされているアップグレード パス

オペレーティング システム

Windows 2000 Professional へのアップグレード

Windows 2000 Server へのアップグレード

Windows 3.x

なし

なし

Windows NT 3.1

なし

なし

Windows NT Workstation 3.51

あり

なし

Windows NT Server 3.51

なし

あり

Windows 95 および Windows 98

あり

なし

Windows NT Workstation 4.0

あり

なし

Windows NT Server 4.0

なし

あり

既存のドメイン構造を検証する

現在のオペレーティング システムを Windows 2000 にアップグレードできることを確認できたら、既存のドメイン構造を検証します。ここで説明する概念を理解するために、図 10.2 に示す Windows NT のドメイン構造について考えてみます。この例は、多くの企業で採用されている複数マスタ ドメイン モデルに基づいています。一般にはアカウント ドメインを最初にアップグレードしますが、この例でも、最初にこのドメインをアップグレードします。

sdgc1002

図 10.2: 複数マスタ ドメイン モデルの例

既存の Windows NT のドメイン構造を検証するときには、次の内容について考慮してください。

  • ドメイン構造のタイプ。

    既存のドメイン構造は、ドメイン アップグレードの計画方法を決定するときに役立ちます。

  • フォレストには組み込みたくない既存の信頼関係 (一方向または双方向) とドメインがあるかどうか。

    既存の Windows NT ドメインは、明示的な一方向の信頼でフォレストに接続しますが、Windows 2000 Server にアップグレードし、同じフォレスト内に指定されたドメインは、双方向の変遷的な信頼で接続されます。そのため、どの信頼を明示的な信頼関係のまま残すかを明確にしておくことが重要です。アップグレード前から存在する信頼は、すべて維持されることに注意してください。

  • ドメイン コントローラがいくつあるか、また各ドメインのどこに配置されているか。

    この情報は、特定のドメインをアップグレードするときに必要な作業量を計画するときに役立ちます。

  • 企業内にどのような DNS ネームスペースが存在するか。

    Windows 2000 ではドメイン名を変更できないため、企業で使用しているネームスペースは何か、フォレストに固有なネームスペースを作成できるように企業でさらに許可するネームスペースは何かを明確にしておくことが必要です。

回復計画を開発する

アップグレード中の不慮のデータ損失を回避するには、回復計画を開発することが重要です。この計画では、ドメイン コントローラ、アプリケーション、およびその他のデータをどのようにバックアップするかを明確にする必要があります。計画の綿密さによって、必要時にはオリジナルの設定に戻すことができるか、または後戻りできなくなってしまうかが分かれます。回復計画を開発するときには、段階的な移行を停止し、完全な移行を開始できる時点を判断してください。

移行を実行する前に、次の作業を完了してください。

  • 単一のドメイン コントローラ、つまり PDC だけを保持する Windows NT ドメインに BDC を追加します。これによって、PDC のアップグレードに失敗した場合でも、ドメインが孤立することがありません。

  • ファイル サービス、プリント サービス、動的ホスト設定プロトコル (DHCP) などのサービスが PDC および BDC で実行されているかどうかを判断します。

    これらのサービスをテープにバックアップし、このバックアップ テープをテストします。

  • すべての BDC を PDC に 完全に同期します。

    PDC と BDC を Windows 2000 Server にアップグレードする前に、BDC の 1 つをオフラインにします。移行を開始する前に、テストとして次の手順を実行します。

    1. オフラインの BDC を PDC に昇格し、データをチェックします。

    2. 移行後もこの PDC をオフラインの状態で使用できるようにし、残りの BDC を定期的にバックアップします。

    注意
    オフラインの PDC がオフラインの状態にある間、ドメインへのすべての変更 (たとえば、新しいアカウントおよびパスワードの更新) を追跡してください。Windows 2000 のドメイン コントローラに事故が起こった場合には、オフラインの PDC の状態に戻す必要があります。オフラインの PDC がオフラインの間行われたドメインの変更を追跡していないと、オフラインの PDC から BDC にデータを複製したときに、変更が失われます。アカウントを再作成するとセキュリティ識別子 (SID) が保持されるため、一部のリソースにアクセスできなくなることがあります。

    図 10.1 に示したフローチャートの手順ごとに、次の内容を明確にします。

    • システムをどのように回復状態に戻すか。

    • アップグレードおよび回復を実行するために必要な管理ツールは何か。

Windows 2000 フォレストへの移行を管理する

ドメイン アップグレードを計画するときに、設計した Windows 2000 フォレストへの移行を慎重に管理しなければなりません。このとき、次のことを忘れないでください。

  • フォレストのネームスペースを適切に定義します。ネームスペースが適切に定義されていないと、ネームスペースを修正するためにフォレストを再構成しなければなりません。

  • フォレストのルート ドメインを慎重に作成します。いったん作成したルート ドメインは、変更できません。

  • 子ドメインを慎重に作成します。子ドメインをフォレストの間違った部分に追加すると、計画外の再構成を行わなければなりません。

  • グループおよびアクセス制御リスト (ACL) の使用に関するポリシーなど、将来的な計画を妨害しないようにポリシーを設定します。

Windows 2000 フォレストの設計の詳細については、このマニュアルの「第 9 章 Active Directory 構造の設計」を参照してください。

リソース ドメインのアップグレードを考慮する

インプレース アップグレードを実行するときに、リソース ドメインをアップグレードすることがあります。Windows NT では、リソース ドメインは、サーバー、クライアント コンピュータなどのコンピュータ アカウントを保持するために使用されていました。リソース ドメインは、主に次の役割を果たしていました。

  • アカウント データベースのサイズを制限する。

    Windows NT のセキュリティ アカウント マネージャ (SAM) アカウント データベースの推奨最大サイズは、40 MB です。ユーザー アカウント、セキュリティ グループ、Windows NT クライアントおよびサーバー アカウントを保持するドメインでは、ユーザー アカウント数が 20,000 個以下に制限されます。企業をこれ以上のユーザー アカウントに拡大するには、ユーザー アカウントをアカウント ドメインに格納し、コンピュータ アカウントをリソース ドメインに格納する必要があります。これが Windows NT の標準的な構成であり、通常、リソース ドメインは、単一のアカウント ドメイン (マスタ ドメイン モデル) または多数のアカウント ドメイン (複数マスタ ドメイン モデル) のいずれかへの明示的な一方向の信頼で作成されます。

  • ローカル管理機能を提供する。

    施設が地理的に分散している多くの分散化企業では、リソースの管理権限を保持する人員をローカルに配備するのが適切です。このような責任の分散を Windows NT システムで可能にするため、リソース ドメインをそれぞれの管理構造で作成することが推奨されていました。SAM のサイズ制限を超えた拡大と同様に、これは、企業内のアカウント ドメインへの明示的な一方向の信頼を持つマスタまたは複数マスタ ドメイン構造になります。このような信頼の一方向の性質により、リソース ドメイン管理者の管理範囲は、そのリソース ドメインに限定されていました。

メモ アップグレードを計画するときに、リソース ドメインのアップグレードが及ぼす影響を管理モデルに反映させなければなりません。既にアカウント ドメインのアップグレードが完了し、これからリソース ドメインをアカウント ドメインの子としてアップグレードする場合、両方のドメイン間に変遷的な信頼が確立されます。そのため、この変遷的な信頼がリソースのローカル管理に及ぼす影響を考慮する必要があります。

リソース ドメインを超えて管理許可を拡張したくない場合、次に挙げるその他の選択肢を考慮することができます。

リソース ドメインを組織単位に再構成する
ドメイン構造を再検討して、後からリソース ドメインを組織単位 (OU) としてアップグレード済みのアカウント ドメインに結合することができます。このようにすると、明らかに、検討中のドメイン アップグレード順序に影響します。

既存のフォレスト内のリソース ドメインをアップグレードし、 Windows 2000 の管理権限の委任機能を使用する
アカウント ドメインと同じフォレストに入るようにリソース ドメインをアップグレードし、Windows 2000 の管理権限の委任機能を使用して、ローカル管理者の権限を制限することができます。これを行う前に、リソース ドメイン内の管理グループをチェックして、アカウント ドメインの管理者以外の管理者をすべて削除します。管理者グループがローカルのリソース ドメイン管理者だけの場合、1 人以上のアカウント ドメイン管理者を追加します。追加された管理者は、アップグレード中のドメインを管理できます。また、念のため、このリソース ドメイン管理者がローカル コンピュータ アカウントを通じてドメイン コントローラに対する管理アクセスを保持しないようにします。

PDC をアップグレードしたら、リソース管理者を保持する新しいドメイン ローカル グループを作成し、Windows 2000 の管理権限の委任機能を使用して、管理者が各自の役割を遂行するために必要な特権を与えることができます。

リソース ドメインを新しいフォレストのツリーとしてアップグレードする
リソース ドメインをアップグレードして新しいフォレスト内のツリーにし、明示的な一方向の信頼によりアカウント ドメインにリンクすることができます。これにより、アップグレード前に存在していた構造を効果的に反映させることができます。

ドメイン コントローラのアップグレード方針を決定する

ドメイン アップグレード プロセスでは、まず PDC を Windows 2000 Server にアップグレードします。PDC をアップグレードしたら、できるだけ早くドメイン内のすべての BDC をアップグレードします。これは、Windows NT の BDC でサポートされていない Windows 2000 の機能が付加されることによる影響を最小限に抑えるために必要な手順です。

Windows 2000 のドメイン モード
PDC が Windows 2000 にアップグレードされていないドメインは、Windows NT ドメインと見なされます。PDC と BDC のアップグレード プロセスで、ドメインは混在モードと呼ばれる中間的な動作状態になります。ドメインは、そのまま混在モードで運用することも、ネイティブモードと呼ばれる最終的な運用状態に移行することもできます。

混在モード
次のどちらかの状態にあるドメインは、混在モードと見なされます。

  • PDC はアップグレードされているが、アップグレードされていない BDC がある。

  • PDC およびすべての BDC がアップグレードされているが、ネイティブ モード スイッチが有効になっていない。

表 10.5 に、混在モードで使用できる Windows 2000 の機能と、ネイティブ モードへの切り替えによって使用できる Windows 2000 機能をまとめます。ドメインをネイティブ モードに切り替えるのを躊躇している場合、移行目標を見直して、混在モードのままにしても目標に妥協することがないかどうか、またそのトレードオフを許容できるかどうかを判断してください。

表 10.5 混在モードで使用できる Windows 2000 の機能

機能

混在モードでの使用状況

Kerberos 認証のための変遷的な信頼

使用できます。Windows 2000 Server および Windows 2000 Professional では、Windows 2000 ドメイン コントローラで使用可能な Kerberos サービスが使用されます。

Active Directory の組織単位 (OU)

使用できますが、Windows 2000 の管理ツールでのみ表示できます。Windows NT の BDC またはメンバ サーバーからは管理できません。

Active Directory のセキュリティ グループ

使用できません。使用できるのは、グローバル グループとローカル グループだけです。

IntelliMirror

使用できますが、Active Directory 環境で Windows 2000 を実行しているクライアント コンピュータだけです。

Windows インストーラ

使用できます。

64 ビット メモリ アーキテクチャ

ハードウェアでサポートされていれば、使用できます。

Active Directory のスケーラビリティ

使用できますが、すべての BDC がアップグレードされ、Active Directory が実行されている場合だけです。混在モードのドメインにも新しい Windows NT の BDC を追加できるため、この機能を使用するときには注意が必要です。この機能は、回復計画で重要になることがあるため、注意が必要です。

Kerberos 認証

Active Directory を実行する Windows 2000 コンピュータであれば、使用できます。

Microsoft 管理コンソール (MMC)

使用できます。

グループ ポリシー

使用できますが、Active Directory 環境で Windows 2000 Professional を実行しているクライアント コンピュータだけです。

セキュリティの設定と解析

使用できます。

Active Directory の複数マスタによる複製

アップグレード済みの PDC および BDC 間で使用できます。

ドメインをネイティブ モードに切り替えるよう決定するまで、すべての BDC をアップグレードしても、ドメインは混在モードのままです。

ネイティブ モード スイッチを設定するときに、ドメインに Windows NT Server 4.0 を実行するメンバ サーバー、Windows NT Workstation 4.0、Windows 95、または Windows 98 を実行するクライアントが保持されていてもかまいません。

図 10.3 に、Windows NT ドメインからネイティブ モードの Windows 2000 ドメインへの移行を示します。

sdgc1003

図 10.3: ドメイン アップグレードのモード

ネイティブ モード
ネイティブ ** モードとは Windows 2000 の最終的な運用状態のことで、ユーザー インターフェイスのスイッチを設定することにより有効になります。この状態では、アップグレード済みのドメインは Windows 2000 ドメインと見なされ、この章の後の「ネイティブ モードに移行する理由」で説明する Windows 2000 の機能をすべて利用できます。すべてのドメイン コントローラを Windows 2000 にアップグレードすると、ドメインをネイティブ モードに移行できるようになります。スイッチの切り替え中は、次のような状態になります。

  • ネットログオン同期のスイッチがオフに切り替えられ、ドメインでは、ドメイン コントローラ間の Active Directory の複数マスタによる複製のみが使用されます。

  • ネットログオン同期がオフに切り替えられているため、Windows NT の BDC をドメインに追加できなくなります。

  • 複数マスタによる複製が有効になっているため、以前の PDC はドメインのマスタでなくなり、すべてのドメイン コントローラでディレクトリ更新を実行できるようになります。ただし、Windows 2000 は、PDC エミュレータの役割を以前の PDC に指示します。通常、以前の PDC は PDC エミュレータとして機能し続けるため、ネイティブ モード環境では、パスワードの変更がその他のドメイン コントローラから以前の PDC に優先的に複製されます。

    Windows 2000 以前のすべてのクライアントでは、PDC の検索およびパスワードの変更に PDC エミュレータが使用されます。また、Windows NT のリソース ドメインでは、信頼の確立に PDC のロケーション情報が使用されます。PDC エミュレータについては、この章の後で定義します。

    グループのネスト、ユニバーサル グループ、ドメイン ローカル グループなどの Windows 2000 のグループ タイプを使用できます。

 

sdgc1004

決定の重要ポイントドメインを Windows 2000 のネイティブ モードに切り替えるよう決定するまで、ドメインは混在モードのままです。ドメイン内のすべての BDC をアップグレードしても、ドメインを混在モードのまま運用できます。ただし、いったんネイティブ モードに切り替えたドメインは、混在モードにも Windows NT ドメインにも戻せません。

Windows NT の PDC をアップグレードする
ドメイン内のすべての BDC を同期して、PDC で最近行われた変更をすべて複製すると、PDC をアップグレードしてアカウント ドメインのアップグレードを開始できます。PDC にコアとなるオペレーティング システムをインストールすると、Windows 2000 セットアップにより、アップグレードされるドメイン コントローラが検出されます。次に、自動的に Active Directory インストール ウィザードが起動され、サーバーに Active Directory をインストールするよう指示が出されます。

Windows 2000 Server のインストール方法の詳細については、このマニュアルの「第 13 章 サーバーの自動インストールと自動アップグレード」を参照してください。

Active Directory インストール ウィザードでは、次のオプションが提示されます。

  • 新しいフォレストに最初のツリーを作成する。

  • 既存のフォレストに新しいツリーを作成する。

  • 既存のドメインの新しいレプリカを作成する。

  • 子ドメインをインストールする。

どのオプションを選択するかは、ネームスペース計画の結果によって異なります。ネームスペース計画の詳細については、この章の準備となる「第 9 章 Active Directory 構造の設計」を参照してください。

アップグレード プロセスで、Windows NT のアカウント データベース (SAM) の内容が Active Directory にコピーされます。これらのオブジェクトは、セキュリティ プリンシパル (ユーザー アカウント、ローカル グループおよびグローバル グループ、コンピュータ アカウント) です。アカウント ドメインが大きいほど、このプロセスに時間がかかります。

Active Directory では、Kerberos 認証もサポートされます。Active Directory インストール ウィザードが完了すると、Windows 2000 システムで Kerberos 認証サービスを使用できるようになります。この時点で、アップグレード済みの PDC を保持するドメインを既存のツリーに追加すると、親ドメインとの間に変遷的な信頼 (双方向) が確立されます。PDC のアップグレード前に作成された信頼関係は、そのまま明示的な一方向の信頼のまま維持されます。

Windows 2000 の PDC エミュレーション
Active Directory では、複数マスタによる更新がサポートされるため、Windows 2000 のドメイン コントローラは、Windows NT 4.0 の PDC と同じようには機能しません。Windows NT の PDC を Windows 2000 のドメイン コントローラにアップグレードすると、PDC エミュレータの役割を持つ PDC として機能します。Windows 2000 では、フォレスト内のドメインごとに PDC エミュレータが 1 つずつ存在します。

PDC エミュレータでは、次のように Windows NT クライアント、メンバ サーバー、およびドメイン コントローラのほか、Windows 95 および Windows 98 クライアントがサポートされます。

  • Windows NT、Windows 95、または Windows 98 クライアントは、PDC エミュレータでディレクトリ書き込み (たとえば、パスワードの変更) を実行します。

  • パスワードがチェックされます。

  • PDC エミュレータから Windows NT の BDC に 複製されます。

  • Windows NT ブラウザ サービスを実行するネットワークでは、PDC エミュレータは、ドメイン マスタ ブラウザの役割を果たし、NetBIOS 名のドメイン名 <0x1B> を登録します。

Windows NT クライアント、メンバ サーバー、およびドメイン コントローラのほか、Windows 95 および Windows 98 クライアントをすべてアップグレードすると、PDC エミュレータのこれらの機能は必要なくなります。

メモ Windows 2000 クライアント、ADClient パッケージがインストールされているすべての Windows 95 および Windows 98 クライアントは、ドメイン内の任意のドメイン コントローラを使用して、パスワードの変更などディレクトリ書き込みを実行できます。これらの動作は、それ自身を PDC としてアドバタイズしていたドメイン コントローラだけに限定されなくなります。

PDC エミュレータは、完全にアップグレードされた Windows 2000 ドメインでも一部の機能を持ち続けます。同じドメインのほかのドメイン コントローラによるパスワードの変更は、優先的に PDC エミュレータに複製されます。このドメイン内の他のドメイン コントローラで不正なパスワードにより認証要求が失敗した場合、ドメイン コントローラは、この認証要求を拒否する前に PDC エミュレータに転送します。この動作は、パスワードが変更されたばかりの状況に備えて実行されます。アカウントのロックアウトは、PDC エミュレータで処理されます。また、サーバーでグループ ポリシー オブジェクトを編集した場合も、グループ ポリシーは既定で PDC エミュレータに転送されます。

セキュリティ ポリシーの詳細については、『Microsoft® Windows 2000 Server Resource Kit Distributed Systems Guide』を参照してください。

PDC エミュレータの特性
PDC エミュレータは、複製中に Active Directory 内のデータを、BDC を含む Windows 95、Windows 98、および Windows NT コンピュータにフラット ストアとして公開し、下位互換性を提供します。この互換性は、次のように表されます。

  • PDC エミュレータは、他の Windows 2000 コンピュータに対しては Windows 2000 ドメイン コントローラとして表現され、アップグレードされていないコンピュータに対しては Windows NT の PDC として表現されます。

  • PDC エミュレータは、新しいセキュリティ プリンシパルの作成、およびこれらの変更の Windows NT の BDC への複製にも使用できます。

  • Windows 95、Windows 98、および Windows NT クライアントは、ログオン可能なサーバーとして PDC エミュレータを使用できます。

  • PDC エミュレータがオフラインになるか、使用できなくなった場合、ドメイン内に別の Windows 2000 ドメイン コントローラが存在するときには、このドメイン コントローラを PDC エミュレータにする必要があります。ドメイン内にこれ以外の Windows 2000 ドメイン コントローラがない場合、Windows NT の BDC を PDC に昇格し、Windows 2000 Server にアップグレードできます。

競合の解決
複数マスタによる複製では、特定のドメイン コントローラがネットワークから切断されている場合でも、任意の Windows 2000 ドメイン コントローラで更新を実行できます。たとえば、切断されているドメイン コントローラで更新を行い、同時に他のユーザーが別のドメイン コントローラでこれと衝突する更新を行った場合、ネットワークの接続が復元されたときに両方の更新が複製されます。更新が衝突する場合でも、結果的にはすべてのドメイン コントローラが同じ値に収束します。この収束プロセスを "衝突の解決" と呼びます。

衝突には、解決が困難なものもあります。異なるドメイン コントローラで、衝突するバージョンのディレクトリ スキーマが使用されている場合を考えてみます。スキーマの衝突は、Active Directory が一般の衝突を解決する規則 (最後の書き込みが優先される) で解決できます。

アクセス制御コンポーネント
PDC のアップグレード中にセキュリティ プリンシパルを Active Directory に移動する場合、この移動がリソースへのアクセスに及ぼす影響が重要になります。ここでは、リソース アクセスを制御するコンポーネントについて説明します。

セキュリティ識別子
Windows NT のセキュリティ モデル (Windows NT および Windows 2000 のセキュリティの基礎) では、セキュリティ識別子 (SID) によってユーザー、グループ、コンピュータ、ドメインなどのセキュリティ プリンシパルが識別されます。SID は、ドメインに固有な値で、ユーザーやグループが作成される時、またはコンピュータや信頼がドメインに登録される時に作成されます。

SID のコンポーネントは、階層型規約に従います。SID には、リビジョン番号を識別する部分、SID を割り当てた機関、ドメイン、および発行機関に関するセキュリティ プリンシパルを一意に識別する副機関の可変番号または相対識別子 (RID) の値が保持されます。

重要すべてのシステムにわたる汎用グループおよびユーザーを識別する既知の SID がありますが、ここで説明するセキュリティ プリンシパルは、ドメインのコンテキスト内で識別されます。これらのセキュリティ プリンシパルは、SID を変更しない限りドメイン間で移動できません。SID が何らかの方法で変更された場合には、リソース アクセスに影響します。ただし、アップグレードの間、セキュリティ プリンシパルは作成されたドメインにとどまり、セキュリティ プリンシパルを識別する SID は変更されないため、リソース アクセスがアップグレードの影響を受けることはありません。

認証とアクセス トークン
認証は、Windows NT のセキュリティ モデルに不可欠なコンポーネントです。認証は、ユーザーが、通常はユーザー名とパスワードによる資格情報を提示して、ドメインに対して識別される手段です。セキュリティ サブシステムは、この資格情報を受け入れ可能なものと想定し、ユーザーのアクセス トークンを作成します。アクセス トークンには、プライマリ SID (ユーザーの SID) とユーザーがメンバになっているすべてのドメインおよびローカル コンピュータの SID が含まれます。アプリケーションの実行など、ユーザーが作成するすべてのプロセスには、ユーザー アクセス トークンが付随します。

ユーザー アクセス トークンは、システムに提示される一種のユーザー ID と考えることができ、システムがユーザーにシステム リソースへのアクセスを与える必要があるかどうかを判断するときに使用されます。

認証とセキュリティ記述子
ユーザー アクセス トークンに対し、ファイルまたはプリンタなどのリソースに付随するセキュリティ記述子があります。セキュリティ記述子には、アクセス制御エントリ (ACE) で構成されるアクセス制御リスト (ACL) が保持されます。ACE は、SID のほか、SID で識別されるセキュリティ プリンシパルに読み取り、書き込み、実行許可などリソースへの特定のアクセスが与えられるか、拒否されるかを表すインジケータで構成されます。システムは、アクセス チェック検証を実行し、アクセス トークンの SID と ACL の SID を比較して、要求されたアクセス許可を与えるかどうかを判断します。

ドメインのアップグレード順序を決定する

ドメイン コントローラのアップグレード方針が完成したら、次にどのドメインを最初にアップグレードするかを決定します。どのドメインを選択するかは、全体的なアップグレード目標によって異なります。たとえば、特定のドメインを再構成するよう計画している場合は、どのドメインを最初にアップグレードするかはあまり重要ではありません。また、既存のドメインをフォレスト ルートにする場合には、このドメインを最初にアップグレードしなければなりません。

次の順序でドメインをアップグレードすることをお勧めします。

  1. アカウント ドメイン

  2. リソース ドメイン

アカウント ドメインをアップグレードするためのガイドライン
多くの場合、管理しなければならないユーザー数はコンピュータ数より多いため、一般には最初にアカウント ドメインをアップグレードするのが適切です。アカウント ドメインを Windows 2000 にアップグレードすると、次のような利点が得られます。

  • Active Directory のスケーラビリティが向上 — 多くの企業では、既存のユーザーおよびグループ数が SAM の推奨上限サイズを超えています。Active Directory のスケーラビリティは、幅広いアプリケーションを実行する多数のユーザーをサポートできるよう改善されています。

  • 管理権限の委任 — Windows 2000 のインフラストラクチャでは管理権限を細かく委任できるため、ローカル管理者に絶対的な権限を与える必要がありません。

アカウント ドメインが複数ある場合、次のガイドラインを利用してアップグレード順序を選択します。

リスクを抑えて、制御を維持するラボまたはパイロット プロジェクトの移行によってアップグレード方針をテストしていても、業務環境での最初の移行には大きなリスクが伴います。リスクを抑えるには、最もアクセスしやすいドメイン コントローラのあるアカウント ドメインをアップグレードします。

混乱を最小限に抑えるまず、ユーザー数およびドメイン コントローラのローカル制御が少ないアカウント ドメインをアップグレードします。これにより、特に初めて展開プロセスを経験する場合には、混乱が多数のユーザーに及ぶのを最小限に抑えることができます。

作業を完了する導入を経験し、導入プロセスに自信が持つことができ、リスク要因を減らすことができたら、他のドメインの集約点になる可能性の高い大きいアカウント ドメインをアップグレードします。ユーザー数が増えるほど、Windows 2000 の機能が発揮されます。

再構成の対象となるアカウント ドメインを特定するアカウント ドメインの再構成を計画している場合、まず再構成の対象となる可能性の高いアカウント ドメインをアップグレードします。ドメインは、存在しないターゲット ドメインには集約できません。再構成するアカウント ドメインを特定します。

リソース ドメインをアップグレードするためのガイドライン
リソース ドメインが複数ある場合、次のガイドラインを利用してアップグレード順序を決定します。

Windows 2000 プラットフォームまたは機能が必要な新規アプリケーションを導入するドメインを選択するまず、Exchange Platinum (Microsoft Exchange の次期メジャー リリース) で必要になる Active Directory など、Windows 2000 インフラストラクチャまたは機能が必要なアプリケーションを展開するドメインをアップグレードします。

多数のクライアントを保持するドメインを選択する次に、多数の Windows NT クライアントを保持するドメインをアップグレードします。これにより、Microsoft® IntelliMirror・(以下 IntelliMirror) など Windows 2000 インフラストラクチャのコンポーネントを利用できるようになります。

再構成の対象となるドメインを選択するアカウント ドメインと同様に、リソース ドメインの再構成を計画している場合には、まず再構成の対象となる可能性の高いドメインをアップグレードします。再構成するリソース ドメインのうち、規模の小さいものを特定します。

子ドメインと信頼
親ドメインのドメイン コントローラは、結果的にすべてのスキーマおよび設定情報を新しい子ドメインにコピーします。この情報が複製されると、アップグレード済みのドメインは、Windows 2000 ツリーの完全な機能メンバになります。ドメインをネイティブ モードに切り替えるよう決定するまで、ドメインは混在モードのままになり、利用できる Active Directory の機能は限定されます。

Windows 2000 Professional、Windows 95 または Windows 98 (Active Directory クライアント ソフトウェアを実行) を実行するコンピュータなど Active Directory 対応のクライアントは、Active Directory を使用し、グローバル カタログ (GC) を照会してリソースおよびユーザーの検索などの作業を実行できます。また、フォレスト内のクライアントは、変遷的な信頼によって、このフォレスト内のすべてのリソースにアクセスできます。その動作方法は、クライアントで Windows 2000 と Windows NT、Windows 95、Windows 98 など Windows 2000 以前のクライアントのどちらが実行されているか、またターゲット ドメインがアップグレードされているかどうかによって異なります。クライアントが次のようなドメインにある場合には、変遷的な信頼を通じてフォレスト全体のリソースを使用できます。

  • ネイティブ モードのドメイン

  • すべてのドメイン コントローラが Windows 2000 にアップグレードされている混在モードのドメイン

  • Kerberos または NTLM 認証要求を処理するドメイン コントローラが Windows 2000 にアップグレードされている混在モードのドメイン

いずれの場合も、クライアントが使用できるのは、アップグレード前からある既存の一方向の明示的な信頼関係を通じてアクセスできるリソースだけです。図 10.4 に、親ドメインと子ドメイン間で変遷的な信頼がどのように機能するかを示します。双方向の矢印は、ドメイン間の変遷的な信頼を表します。

sdgc1005

図 10.4: 親ドメインと子ドメイン間の変遷的な信頼の例

NTLM 認証を使用する
NTLM は、Windows NT でネットワーク認証に使用される既定の認証プロトコルです。このプロトコルは、Windows NT の各バージョンを実行するクライアントおよびサーバーとの互換性を保つため、Windows 2000 でも維持されています。

たとえば、図 10.5 のように、ユーザーが混在モードのドメイン reskit-acct.reskit.com に、同じドメインにある Windows NT ワークステーション ntws からログオンする場合を考えてみます。次に、ネイティブ モードの Windows 2000 ドメイン reskit-other.reskit.com にある Windows NT サーバー nts へのネットワーク接続を確立しようとします。このとき、ntws は Windows 2000 以前のクライアントであるため、NTLM が使用されます。

nts では、引き渡された資格情報に指定されているドメイン名 reskit-acct.reskit.com がそれ自体のアカウント データベースを参照していないと判断します。そこで、nts は、認証のために、そのドメイン内のドメイン コントローラにログオン要求を送信します。ドメイン コントローラはドメイン名をチェックしますが、このドメイン コントローラのドメイン名に一致していないため、このドメインが信頼あるドメインかどうかを確認します。ドメイン reskit-acct.reskit.com および reskit-other.reskit.com はどちらも同じルート reskit.com の子であるため、2 つのドメイン間には変遷的な信頼が存在します。そこで、ドメイン コントローラは、ログオン要求を信頼あるドメインのドメイン コントローラに引き渡します。ログオン要求を受け取ったドメイン コントローラは、ユーザー名およびパスワードをそれ自体のドメイン アカウント データベースと照合し、資格情報が一致した場合には、アカウント識別情報とグループ メンバーシップ リストを問い合わせ元のドメイン コントローラに返し、ここからさらにサーバーに返されます。

次に、サーバーは、ユーザーの SID およびユーザーがメンバになっているすべてのドメイン グループの SID を保持するユーザーの代理アクセス トークンを作成します。クライアント要求を処理するサーバーは、スレッドにユーザーのセキュリティ コンテキストの代理役を実行させます。これにより代理トークンが作成され、ユーザーに代わってリソースへのアクセスが試行されます。

この例は、混在モードのドメイン内にある Windows 2000 以前のクライアントが、NTLM を使用して変遷的な信頼を通じてネイティブ モードのドメインにある Windows 2000 以前のサーバーにアクセスできることを示しています。同じフォレスト内のすべてのツリーは、変遷的な信頼でリンクされるため、2 つのドメインが異なるツリーにある場合も同じことが言えます。

さらに、ユーザーが混在モードのドメイン reskit-res1.reskit-other.reskit.com にある Windows NT サーバー nts 上のリソースにアクセスしようとする場合も、サーバーからログオン要求を受け取るドメイン コントローラで Windows 2000 が実行されていれば、変遷的な信頼を通じてフォレスト全体のリソースにアクセスできます。

Kerberos 認証を使用する
Kerberos サービスは、Windows 2000 を実行するコンピュータの既定のネットワーク認証プロトコルです。また、Windows 2000 ドメイン内およびドメイン間のネットワーク認証には、Secure Sockets Layer (SSL) および NTLM 認証を使用することもできます。Kerberos 認証は、チケットに基づくプロトコルです。ユーザーは、ドメインへの初回ログオン時に、Windows 2000 のドメイン コントローラのキー配布センター (KDC) からチケット保証チケット (TGT) を発行されます。TGT には、ユーザーに関する認証情報が保持され、KDC が認識するキーで暗号化されます。クライアントが取得した TGT は、ドメイン内の他のサーバーに接続するための追加サービス チケットの要求の一部として、ドメイン コントローラに提示できます。いったんユーザーに TGT が与えられると、ドメイン コントローラは TGT の暗号を解除するだけでユーザーの資格情報をチェックできるため、以降のチェックは効率良く短時間で行われます。サービス チケットは TGT に似ていますが、サーバーとドメイン コントローラが共有するキーで暗号化されます。

図 10.4 の例では、ユーザーは、前と同じドメイン reskit-acct.reskit.com に、今度は Windows 2000 を実行する同じドメイン内のコンピュータ w2kpro からログオンし、reskit-other.reskit.com ドメインの Windows 2000 サーバー w2ksrv にネットワーク接続を確立します。w2kpro は Windows 2000 クライアントであるため、クライアントは Kerberos プロトコルを使用しようとします。

Kerberos プロトコルは NTLM と同様に、ドメイン境界を超えて機能します。2 つのドメイン間に信頼関係が確立されている場合、一方のドメインのクライアントは、他方のドメインのサーバーから認証を受けることができます。信頼を確立したドメインは、ドメイン間キーを交換します。各ドメインの認証サービスは、それぞれのドメイン間キーを使用して、他方のドメインの KDC に対するチケットを暗号化します。

クライアントがリモート ドメインのサーバーにアクセスする場合、TGT を取得するために、クライアントのホーム ドメインにあるドメイン コントローラに問い合わせます。次に、クライアントがリモート ドメインまたはその親ドメインと直接信頼関係を結んでいる場合は、リモート ドメインのドメイン コントローラの KDC に TGT を提示します。このプロセスは、クライアントのホーム ドメインとリモート ドメインの間に信頼経路が構築されるまで、中間にあるすべてのドメインで繰り返されます。

クライアントは、リモート ドメイン コントローラの KDC に紹介 TGT を提示して、クライアント ドメイン内のサーバーへのチケットを要求します。リモート ドメイン コントローラは、そのドメイン間キーを使用して、クライアントの TGT の暗号化を解除します。リモート ドメイン コントローラは、暗号化を正常に解除すると、その TGT が信頼ある機関から発行されたものであることを確認できます。確認後、要求されたサーバーへのチケットをクライアントに与えます。

図 10.4 は、2 つのドメイン reskit-acct.reskit.com および reskit-other.reskit.com が同じルートの子で、ドメイン間に変遷的な信頼が存在するため、ドメイン間に信頼経路を構築できること示しています。ターゲット ドメインのドメイン コントローラは、紹介 TGT を受け取ると、問題になっているサーバーの共有キーを保持しているかどうかを確認します。共有キーを保持している場合、ドメイン コントローラは、クライアントにサービス チケットを発行します。w2ksrv は Windows 2000 コンピュータで、共有キーが存在するため、チケットを w2kpro に発行できます。

この例で重要なのは、Kerberos KDC を実行するターゲット ドメイン内にドメイン コントローラが存在することと、ドメイン コントローラとサーバー間に共有キーが存在することです。Windows 2000 のドメイン コントローラは、Active Directory のインストール プロセスで Kerberos サービスが有効になるため、メンバ サーバーを Windows 2000 ドメインに追加すると、共有キーが作成されます。そのため、w2kpro は、セッション チケットの発行に使用できる Windows 2000 ドメイン コントローラがある限り、Kerberos を使用して w2ksrv.reski-res1.reskit-other.reskit.com にアクセスできます。

w2kpro が nts.reskit-res1.reskit-other.reskit.com などの Windows NT コンピュータにアクセスしようとすると、Kerberos 認証は失敗します。そこで、クライアントは前の「NTLM 認証を使用する」で説明した NTLM 認証を行います。

ネイティブ モードに移行するタイミングを決定する

ドメインを混在モードからネイティブ モードに切り替えるのは簡単ですが、いったん切り替えたドメインは元に戻せません。切り替えるタイミングを決定するには、ここで説明するすべての要因を考慮する必要があります。ドメインに Windows NT ドメイン コントローラが保持されているか、後で保持される場合、ドメインをネイティブ モードに切り替えることはできません。

混在モードのまま運用する理由
ドメインを混在モードのまま運用する理由には、主に次のものがあります。

アプリケーション サーバーをアップグレードできない
アップグレードできないか、メンバ サーバーに降格できないアプリケーション サーバーがあります。たとえば、高いスループットを実現するには、パススルー認証を回避するため、一部のアプリケーションを BDC にインストールする必要があります。このようなアプリケーションを処理する BDC をアプリケーションサーバーと呼びます。

BDC の物理的なセキュリティが不適切
セキュリティは、ドメイン計画で重要な考慮事項です。セキュリティの根本的な要素に、コンピュータ自体の物理的なセキュリティがあります。物理的に簡単にアクセスできるコンピュータは、攻撃を受けやすいためです。 ここでは、PDC だけによる SAM の単一マスタ更新と、すべてのドメイン コントローラによるアカウント データベースの Active Directory の複数マスタ更新の違いについて考慮します。

Windows NT のディレクトリ更新には単一マスタが使用されるため、BDC のセキュリティが比較的緩和されている方が便利な場合があります。この場合、BDC を Windows 2000 のドメイン コントローラにアップグレードするときに、これを再検討する必要があります。BDC のセキュリティを適切にアップグレードできない場合、アップグレード中に BDC をメンバ サーバーに降格し、別のロケーションに新しい Windows 2000 ドメイン コントローラを追加するか、場合によっては提案されているドメイン構造を再検討します。

完全に Windows NT に戻す必要性が残される
混在モードでは、後方互換性が維持されます。混在モードでは、問題が発生した場合に、新しい BDC をドメインに追加し、アカウント データベースを再度同期することができます。他に Windows 2000 ドメインがなければ、BDC を PDC に昇格することもできます。

回復計画も必要ですが、Windows 2000 の機能をすべて利用するには、後で新しい環境に完全に切り替えることになります。

ネイティブ モードに移行すると、ネストされたグループを含むすべての Windows 2000 グループを使用できるようになります。この時点で、どのグループをユニバーサル グループに昇格するかを考慮する必要があります。

ネイティブ モードに移行する理由
PDC および BDC をアップグレードし、ドメインを混在モードのまま運用しても多くの利点が得られますが、できるだけ早くネイティブ モードに切り替えることをお勧めします。ネイティブ モードでは、次のようにネットワークの全体的な機能性を向上させることができます。

  • 新しい Windows 2000 のグループ タイプを使用できます。

  • ネイティブ モードのドメインでは、ユニバーサル グループおよびグループのネストを使用できます。

前に説明したように、自動的にはネイティブ モードに切り替えられません。ネイティブ モードに切り替えるには、Microsoft 管理コンソール (MMC) で Active Directory ドメインと信頼関係スナップインを使用して変更しなければなりません。このスナップインの使用方法の詳細については、Windows 2000 Server のヘルプ ファイルを参照してください。

Windows 2000 のグループを検証する

Windows 2000 に移行することによって、セキュリティ ポリシーおよび Windows 2000 以前のグループ構造にどのような影響があるかを判断することが重要です。セキュリティ ポリシーを変更すると、多くの場合、グループの再構成が必要になります。

Windows 2000 では、次の 4 つのタイプのセキュリティ グループがサポートされます。

  • ローカル

  • ドメイン ローカル

  • グローバル

  • ユニバーサル

ローカル グループ
Windows NT に存在するローカルグループには、同じフォレスト内、その他の信頼あるフォレスト内、または信頼ある Windows 2000 以前のドメイン内の任意の場所にあるメンバを保持できます。ただし、ローカル グループで与えることができるのは、このグループが存在するコンピュータ上のリソースに対するアクセス許可だけです。

ただし、PDC に作成された Windows NT のローカル グループは例外です。BDC 間でのドメイン SAM の複製により、これらのローカル グループは、PDC および BDC 間で共有されます。混在モードでは、Windows NT のローカル グループと Windows 2000 のローカル グループは同じように機能します。ネイティブ モードでは、ドメイン コントローラのローカル グループがドメイン ローカル グループになります。ドメイン ローカル グループについては、次に説明します。一般に、ローカル グループは、ローカル コンピュータ上のリソースへの特定アクセスを与えるときに使用します。

ドメイン ローカル グループ
ドメイン ** ローカル ** グループは Windows 2000 の新機能ですが、その概念および使用は Windows NT ドメインに作成されたローカル グループに似ています。

ドメイン ローカル グループを使用できるのは、ネイティブ モードのドメインだけで、同じフォレスト内、信頼あるフォレスト内、または信頼ある Windows 2000 以前のドメイン内の任意の場所のメンバを保持できます。ドメイン ローカル グループで与えることができるのは、このグループが存在するドメイン内のリソースに対するアクセス許可だけです。一般に、ドメイン ローカル グループは、ドメイン内のリソースへのアクセスを制御するために、フォレスト全体からセキュリティ プリンシパルを収集するときに使用します。

グローバル グループ
Windows 2000 のグローバルグループの効果は、Windows NT のグローバル グループと同じです。Windows 2000 のグローバル グループに保持できるのは、このグループが存在するドメイン内のメンバだけです。これらのグループには、同じフォレスト内または信頼あるフォレスト内にあるドメインのリソースに対するアクセス許可を与えることができます。

ユニバーサル グループ
ユニバーサル ** グループには、フォレスト内の任意の Windows 2000 ドメインのメンバを保持でき、同じフォレスト内または信頼あるフォレスト内の任意のドメインにアクセス許可を与えることができます。ユニバーサル グループには、同じフォレスト内の混在モードのドメインのメンバも保持できますが、混在モードではユニバーサル グループを使用できないため、ユニバーサル グループをそれぞれのアクセス トークンに追加できません。また、ユニバーサル グループにユーザーを追加することもできますが、メンバーシップをグローバル グループに限定することをお勧めします。ユニバーサル グループを使用できるのは、ネイティブ モードのドメインだけです。

ユニバーサル グループを使用すると、企業内の共通機能を実行するグループを作成できます。これには、たとえば仮想チームがあります。大規模な企業では、このようなチームのメンバーシップが全国、全世界、またフォレスト全体にわたることがあり、チーム リソースを同じように分散できます。この環境では、ユニバーサル グループを、各子会社または部門のグローバル グループを保持するコンテナとして使用し、ユニバーサル グループの単一の ACE でチーム リソースを保護することができます。

ユニバーサル グループとそのメンバの一覧は、グローバル カタログ (GC) に格納されます。また、グローバル グループおよびドメイン ローカル グループの一覧も GC に格納されますが、そのメンバは格納されません。GC に格納される内容は、GC の複製トラフィックに影響するため、ユニバーサル グループを使用するときには、注意が必要です。ネットワーク全体の接続が高速な場合、単純にすべてのグループにユニバーサル グループを使用すれば、グローバル グループとドメイン ローカル グループを管理せずに済みます。ただし、ネットワークがワイド エリア ネットワーク (WAN) に及ぶ場合には、グローバル グループとドメイン ローカル グループを使用することにより、パフォーマンスを向上できます。

グローバル グループとドメイン ローカル グループを使用する場合にも、変更頻度が少なく広範に使用されるグループをユニバーサル グループに指定できます。

表 10.6 に、Windows 2000 のグループの特性を示します。

表 10.6 Windows 2000 のグループの特性

グループタイプ

格納されるメンバーシップ

範囲

混在モードでの使用状況

ローカル

同じフォレスト
他の信頼あるフォレスト
信頼ある Windows 2000 以前のドメイン

コンピュータ全体

使用可

ドメイン
ローカル

同じフォレスト
他の信頼あるフォレスト
信頼ある Windows 2000 以前のドメイン

ローカル ドメイン

使用不可

グローバル

ローカル ドメイン

任意の信頼あるドメイン

使用可

ユニバーサル

同じフォレスト

任意の信頼あるネイティブ モードのドメイン

使用不可

グループをネストする
Active Directory ストアは、1 回のトランザクションで更新できなければならないため、グループのサイズを 5,000 メンバに制限することをお勧めします。グループのメンバーシップは、単一の複数値の属性に格納されるため、メンバーシップを 1 つ変更しただけで、メンバーシップ一覧全体を 1 回のトランザクションによりドメイン コントローラ間で複製し、更新しなければなりません。テストされ、サポートされているのは、最大 5,000 メンバまでのグループ メンバーシップです。

グループをネストすると、有効メンバ数を増やすことができます。また、グループ メンバーシップの変更を複製するトラフィックを軽減できます。選択できるネスト オプションは、ドメインがネイティブ モードにあるか、混在モードにあるかによって異なります。次の一覧に、ネイティブ モードのドメインに存在するグループに保持可能なメンバについて説明します。保持できるメンバは、グループの範囲によって決まります。

  • ユニバーサル グループには、任意のドメインのユーザー アカウント、コンピュータ アカウント、ユニバーサル グループ、およびグローバル グループを保持できます。

  • グローバル グループには、同じドメインのユーザー アカウントとコンピュータ アカウント、および同じドメインのグローバル グループを保持できます。

  • ドメイン ローカル グループには、任意のドメインのユーザー アカウント、コンピュータ アカウント、ユニバーサル グループ、およびグローバル グループを保持できます。また、同じドメイン内の他のドメイン ローカル グループを保持することも可能です。

混在モードのドメインのセキュリティ グループに保持できるのは、次のグループだけです。

  • 信頼あるドメインのグローバル グループとユーザー アカウントを保持できるローカル グループ

  • ユーザー アカウントだけを保持できるグローバル グループ

グループ メンバーシップの展開
ユーザーがクライアントにログオンするか、サーバーにネットワーク接続を確立すると、ユーザー アクセス トークンの作成過程でユーザーのグループ メンバーシップが展開されます。グループは、次のように展開されます。

  • クライアントへの対話型ログオンの過程で、クライアントはドメイン コントローラに問い合わせ、ユーザーの資格情報を検証し、Kerberos TGT を取得します。ドメイン コントローラは、このユーザーのすべてのグループ メンバーシップの一覧から次のグループ タイプを展開します。

    • フォレストの任意の場所で定義されているユニバーサル グループ

    • グローバル グループ

    • ユーザー アカウントと同じドメインのドメイン ローカル グループ

  • これらのグループ一覧は、認証データとして TGT に含まれています。

  • クライアントがサーバーへのネットワーク接続を確立する場合、サーバーがユーザー アカウントとは異なるドメインにあると、ドメインを越えた紹介が使用され、サーバーの KDC からサービス チケットが取得されます。サービス チケットが発行されると、グループが展開され、ユーザーがメンバになっているドメイン グループがサーバーのドメインに追加されます。これらのグループは、TGT のグループ一覧と一緒にサービス チケットの認証データに追加されます。また、サーバーがユーザー アカウントと同じドメインにある場合には、最初の対話型ログオンの時点から、TGT でドメイン ローカル グループを使用できます。

  • クライアントがサーバーに接続すると、ユーザー アカウントまたはユーザーがメンバになっているいずれかのグループがサーバーの任意のローカル グループのメンバである場合、ローカル グループが展開されます。

ユーザーのアクセス トークンが作成されるときに、ドメイン コントローラまたはリソース サーバーで展開されたグループ メンバーシップ情報がユーザーの識別に使用されます。

アップグレードがグループに及ぼす影響
PDC を Windows 2000 にアップグレードしても、そのままではグループに何の効果もありません。Windows NT のローカル グループが Windows 2000 のローカル グループになり、Windows NT のグローバル グループが Windows 2000 のグローバル グループになるだけです。実際の変化は、ドメインをネイティブ モードに切り替えたときに起こります。この時点で、PDC のローカル グループはドメイン ローカル グループになります。

Windows 2000 で NetBIOS を使用する

NetBIOS は、Windows 2000 以前のネットワーキング コンポーネントで使用されていた高度ネットワーク プログラミング インターフェイスです。NetBIOS のネームスペースでは、ネットワーク リソースは固有な NetBIOS 名で識別されます。WINS は、NetBIOS 名の IP アドレスへの動的マップの登録をサポートし、NetBIOS 名を解決するために Windows NT Server 4.0 で提供されていたサービスです。

Windows 2000 で NetBIOS 名前付けインターフェイスが必要になるのは、クラスタ サーバーだけです。そのため、DNS と Active Directory を使用すれば、NetBIOS は必要なくなります。

ドメインを Windows 2000 にアップグレードしても、ネットワークで NetBIOS をサポートする必要がなくなるわけではなく、現在のサポート レベルに影響することもありません。たとえば、ネットワークがマルチ分割されている場合、NetBIOS のブラウズ一覧を作成するには WINS が必要です。WINS を使用しないネットワークでは、リソースをブラウズするときに Active Directory に依存しなければならず、Windows 以前のクライアントに大きな影響を与える可能性があります。

次の条件が満たされていれば、アップグレードしたら、NetBIOS および WINS の使用を廃止することができます。

  • NetBIOS を使用する Windows NT を実行しているクライアント (Windows for Workgroups、Windows 95、Windows 98、Windows NT など) およびサーバーがない。ただし、以前のバージョンの Windows オペレーティング システムを実行しているクライアントでは、ファイル サービスおよびプリント サービスを提供するため、また従来のアプリケーションをサポートするために、NetBIOS 名が必要になることがあります。

    テスト計画で、従来のアプリケーションおよびサービスへの影響を必ず評価してください。テストの詳細については、このマニュアルの「第 4 章 Windows 2000 テスト ラボの構築」を参照してください。

  • Windows 2000 だけのネットワークを使用し、ネットワーク上のすべてのコンピュータおよびアプリケーションが DNS など別の名前付けサービスでも確実に機能する。ネットワークの名前付けは、NetBIOS 名が不要な場合でも、ネットワーク全体のコンピュータとリソースを検索できる重要なサービスです。

    Windows 2000 の WINS クライアントは、解決された名前をローカルにキャッシュし、DNS に照会を送出する前に、キャッシング リゾルバというコンポーネントを使用してキャッシュを調べます。HOST ファイルは、クライアントの起動直後にキャッシュされ、HOST ファイルへの更新はすぐにキャッシュに反映されます。名前は次の手順で解決されます。

    1. クライアントは、クライアント キャッシュから名前を解決しようとします。

    2. クライアント キャッシュによる解決に失敗した場合、クライアントは、DNS で名前を解決しようとします。

    3. DNS による名前の解決に失敗すると、クライアントは、WINS で名前を解決しようとします。

これらの基準が満たされ、従来の状態をすべて排除し、新しくアップグレードしたクライアントに適切な変更制御を適用できれば、NETBIOS および WINS からシームレスに移行できます。

ファイル複製サービスに移行する

Windows NT Server には、LAN Manager 複製サービスという複製機能が備わっていました。Windows 2000 Server では、LAN Manager 複製サービスに代わってファイル複製サービス (FRS) が使用されます。

メモ Windows 2000 Server では、混在モードでもネイティブ モードでも LAN Manager 複製サービスはサポートされません。LAN Manager 複製サービスを使用していた場合には、FRS に移行して同じ機能を提供するための方針をアップグレード計画に盛り込む必要があります。

LAN Manager 複製サービスのプロセス

LAN Manager 複製サービスでは、インポート ディレクトリとエクスポート ディレクトリという概念が使用されます。LAN Manager 複製サービスは、エクスポート ディレクトリを処理する 1 台のサーバーと、インポート ディレクトリを処理する多数のサーバーを選択して設定します。ディレクトリを処理するサーバーは、必ずしもドメイン コントローラである必要はなく、一般のメンバ サーバーでもかまいません。図 10.5 に、LAN Manager 複製サービスのプロセスを示します。

sdgc1006

図 10.5: LAN Manager 複製サービスのプロセス

FRS のプロセス
Windows 2000 Server の FRS は、すべてのドメイン コントローラがシステム ボリューム (SYSVOL) の複製を保持するように自動設定されます。ドメイン コントローラの SYSVOL に格納されているログオン スクリプトを変更すると、複数マスタ方式でその他のドメイン コントローラに複製されます。一般のメンバ サーバーがインポート ディレクトリおよびエクスポート ディレクトリを処理できる LAN Manager 複製サービスとは異なり、FRS で SYSVOL を処理できるのは、ドメイン コントローラだけです。図 10.6 に、FRS のプロセスを示します。

sdgc1007

図 10.6: FRS のプロセス

混在環境で LAN Manager 複製サービスを維持する
アップグレード中、Windows NT の BDC と Windows 2000 のドメイン コントローラで動作するメンバ サーバーで構成される混在環境を維持できます。Windows 2000 Server では LAN Manager 複製サービスがサポートされないため、混在環境で LAN Manager 複製サービスを維持することが問題になる場合があります。LAN Manager 複製サービスをサポートするには、LAN Manager 複製サービスと FRS が両方機能するように、双方の間にブリッジを作成する必要があります。ブリッジを作成するには、Windows NT のエクスポート ディレクトリにファイルをコピーする Windows 2000 のドメイン コントローラを選択します。ファイルは、L-bridge.cmd という定期的にスケジュールされたスクリプトでコピーされます。

メモ 混在環境と混在モードを混同しないでください。混在モードは、Windows 2000 ドメイン内にある PDC と 0 個以上の BDC を指します。また、混在環境は、Windows 2000 以前のクライアントまたはサーバーを保持する混在モードまたはネイティブ モードの Windows 2000 ドメインを表します。

LAN Manager 複製サービスと FRS 間にブリッジを設定する
LAN Manager 複製サービスと FRS 間にブリッジを作成する前に、次の作業を行っておかなければなりません。

  • 問題になっているディレクトリの Windows NT エクスポート サーバーを判断します。

  • このディレクトリにファイルをプッシュできる Windows 2000 コンピュータを選択します。

各ドメイン コントローラまたはメンバ サーバーをアップグレードする前に、[コントロール パネル] の [サービス] を使用して、手動で LAN Manager 複製サービスを使用不可にすることをお勧めします。または、アップグレード後に MMC からディレクトリ レプリケータを使用不可にすることもできますが、この方法はお勧めしません。

Windows 2000 にアップグレードする前にエクスポート サーバーをアップグレードするには、次の手順に従います。

  1. 現在のエクスポート サーバーで SrvMgr.exe を実行し、エクスポート ディレクトリを削除します。

  2. 新しいエクスポート サーバーで SrvMgr.exe を使用して、エクスポート リストにエクスポート ディレクトリを追加します。

バッチ ファイルにより、Windows NT のスクリプト ディレクトリと Windows 2000 のシステム ボリュームがリンクされます。この方法では、2 つの複製メカニズムが互いに分離されるため、Windows 2000 のドメイン コントローラで従来のサービスが使用されます。

LAN Manager 複製サービスと FRS 間のブリッジ用のバッチ ファイルを設定するには、次の手順に従います。

  1. Windows 2000 のドメイン コントローラを選択します。

  2. 次の例のように、ログオン スクリプトを Windows NT のエクスポート サーバーにコピーする L-bridge.cmd というバッチ ファイルを作成します。

    xcopy \\domain.com\Sysvol\domain.com\scripts \\Srv3\Export\scripts /s /D

    「/D」コマンド ライン スイッチは、新しいファイルだけをコピーするよう xcopy に指示します。また、「/s」コマンド ライン スイッチは、空でないディレクトリおよびすべてのサブディレクトリをコピーするよう xcopy に指示します。

  3. Windows 2000 のスケジュール サービスを使用して、バッチ ファイルを実行する適切な間隔を設定します。特に「/D」オプションを使用すると、不要なファイルのコピーが作成されないため、2 時間ごとに実行すれば十分です。

L-bridge.cmd のサンプルは、「Windows 2000 リソース キット」の CD に収録されています。

アップグレード中に LAN Manager 複製サービスを使用できるようにする
アップグレード中に LAN Manager 複製サービスを使用できるようにするには、インポート ディレクトリを処理するその他すべてのサーバーをアップグレードしてから、エクスポート ディレクトリを処理するサーバーをアップグレードします。エクスポート ディレクトリを処理するサーバーが PDC の場合は、新しいエクスポート サーバーを選択して、LAN Manager 複製サービスを再設定する必要があります。このとき、新しいサーバーには、最後に Windows 2000 にアップグレードするサーバーを選択することをお勧めします。そうでないと、サーバーが順にアップグレードされるため、別のエクスポート サーバーを選択して、このプロセスを繰り返さなければなりません。

混在環境でルーティングとリモート アクセス サービスを使用する

Windows NT 環境でルーティングとリモート アクセス サービス (RRAS) を使用してユーザーに企業ネットワークへのリモート アクセスを提供する場合、メンバ サーバーのアップグレード プロセスの早い段階に RRAS サーバーをアップグレードすることを考慮してください。ユーザーの RRAS アクセスまたはダイアルバックのアベイラビリティなど、RRAS プロパティをチェックする Windows NT の RRAS の動作から考えると、早い段階にアップグレードするのが適切です。

ユーザーがまったくシステムにログオンしていないときでも、RRAS を実行しなければなりません。このサービスは、LocalSystem として実行されます。サービスが LocalSystem としてログオンするときには、空白の資格情報でログオンするため、ユーザー名もパスワードも提供されません。そのため、リモート コンピュータが空白の資格情報 (空白のセッション) によるアクセスを許可しない限り、NTLM 認証に依存するネットワーク リソースへのアクセスにこのアカウントを使用できません。Windows NT の RRAS では、LocalSystem アカウントが使用されます。

既定の Active Directory では、空白のセッションによるオブジェクトの照会が許可されません。そのため、混在環境では、次のすべての条件が満たされていなければ、Windows NT の RRAS サーバーがユーザーの RRAS プロパティを検索できません。

  • ドメインが混在モードで、Windows NT の RRAS サーバーが BDC でもあります。この場合、RRAS は SAM へのローカル アクセスを保持します。

  • ドメインが混在モードで、Windows NT の RRAS サーバーが Windows NT の BDC に問い合わせるため、動作が現在の Windows NT の動作と同じになります。この動作は、セキュリティで保護されたチャネルの位置に基づきます。

  • ドメインが混在モードまたはネイティブ モードで、Active Directory のセキュリティが緩和され、組み込みユーザーに任意のユーザー オブジェクトの任意のプロパティを読み取る "Everyone" のアクセス許可を与えることができます。Active Directory インストール ウィザードでは、ユーザーが特定の Active Directory オブジェクトの "Weaken the permissions" オプションでこの設定を選択できます。

最後の条件に挙げた方法は、Active Directory のセキュリティへの影響を理解した上で使用してください。この方法が、セキュリティ要件と衝突する場合には、Windows NT の RRAS サーバーを Windows 2000 にアップグレードし、これを Windows 2000 の混在またはネイティブ ドメインのメンバにすることをお勧めします。これによって、2 番目の条件に挙げた混在モードのドメインの矛盾した動作を回避できます。

ドメインの再構成を計画する

ドメイン アップグレードでは、ドメイン構造など現在の環境をできる限り維持できますが、ドメインを再構成すると、企業の必要性に応じてフォレストを再設計できます。ドメインの再構成による結果はさまざまですが、一般には、現在の構成を少数の大規模なドメインに再編成します。

Windows 2000 は次の機能を備えているため、ドメインの再構成が可能です。

  • セキュリティ プリンシパルはドメイン間で移動でき、移動前に使用可能だったリソースへのアクセスは維持されます。

  • オペレーティング システムをすべて再インストールしなくても、ドメイン コントローラをドメイン間で移動できます。

メモ ドメインの再構成は、Windows 2000 Server の配置に必ずしも必要なわけではなく、必要なときに行うことができます。コンピュータを新しいドメインに移動してアクセス制御を更新または検証する作業は、集中的に行わなければならず、時間がかかります。

ドメインの移行を支援するドメイン移行基本ユーティリティが作成されています。これらのユーティリティは、環境順応型の管理ユーティリティの基礎を構成する一連のコンポーネント オブジェクト モデル (COM) オブジェクトとサンプル スクリプトで構成されており、Microsoft が文書化およびテストした多数のドメイン移行サンプルをサポートしています。これらのサンプルは、カスタマからの移行要件に関するフィードバックに基づいて開発されています。基本ユーティリティ ClonePrincipal については、この章の後で説明します。

ドメインを再構成する理由を判断する

この章では、主に Windows NT から Windows 2000 への基本的な移行について説明しています。ここで説明する再構成の方法には、移行後に便利なものもあります。

ドメインを再構成する理由はさまざまですが、主な理由として、Windows 2000 の機能をすべて利用することが挙げられます。Windows 2000 には、ドメインをより有効に使用して、企業の必要性を反映する機能が備わっています。ドメインを再構成すると、主に次のような利点が得られます。

スケーラビリティの向上SAM アカウント データベースのサイズ制限に合わせて Windows NT のドメイン構造を設計したため、マスタまたは複数マスタ ドメイン モデルが採用されている場合があります。Active Directory ではスケーラビリティが大幅に向上しており、数百万個のユーザー アカウントまたはグループに拡大できるため、現在の Windows NT ドメインを少数の大規模な Windows 2000 ドメインに再構成することができます。

管理権限の委任管理権限を委任するためにリソース ドメインを導入している場合があります。Windows 2000 の OU には、任意のタイプのセキュリティ プリンシパルを保持できるため、必要に応じて管理権限を委任できます。多くの場合、管理権限を委任するには、リソース ドメインを OU に変換するのが適切です。

細かい管理権限の設定企業の買収などにより細かく管理権限を適用するために、ドメイン構造を複雑な信頼の網で接続している場合があります。このようなドメインを OU として導入すれば管理を単純化でき、ドメイン モデルを再設計すれば明示的な信頼関係を減らすことができます。

次に説明する例では、アップグレードが完了していなくてもかまいませんが、再構成する方法のいくつかには、再構成するドメインの BDC がすでにアップグレードされていなければならないものがあります。

ドメインを再構成するタイミングを決定する

移行計画によって、ドメインの再構成をアップグレード直後に行うか、アップグレードせずに行うか、または将来的に行われる汎用ドメインの再設計で行うことができます。 これらの再構成のタイミングについて、次に説明します。

アップグレード後
ドメインの再構成は、Windows 2000 への移行の第 2 フェーズとしてアップグレード後に行うのがほとんどです。この場合、信頼構成が本質的に適切で、管理上問題のないドメイン グループなど、より単純な移行状態になります。

アップグレード後に再構成する場合、複雑さを軽減するため、または低い権限を持つ管理者のリソース ドメインをセキュリティで保護された方法でフォレストに組み込むため、ドメイン構造を操作する作業が目標に含まれてきます。

アップグレードしない
現在のドメイン構造をそのまま利用できない (たとえば、Active Directory を利用するには、ディレクトリ サービスのインフラストラクチャを再設計する必要がある) 場合、または移行中に現在の業務環境が不安定になるのを許容できない場合があります。どちらの場合も、純粋なフォレスト、つまり現在の業務環境から分離された適切な Windows 2000 フォレストを設計および作成するのが最も簡単な移行方法です。この方法では、パイロット プロジェクトの操作中も通常どおりビジネスを遂行し、最終的にはパイロット プロジェクトを業務環境にすることができます。

パイロット プロジェクトを作成したら、少数のユーザー、グループ、およびリソースをパイロットに移行して、ドメインの再構成を開始することができます。このフェーズを正常に完了できたら、パイロット プロジェクトを新しい環境に移行します。その後、Windows 2000 を業務環境にし、古いドメイン構造を廃止し、残りのリソースを再配置します。

移行後
この段階では、純粋な Windows 2000 環境での汎用ドメインの再設計としてドメインの再構成を行います。数年たってから、組織変更や企業の買収などにより現在の構造が適切でなくなったときに行う場合もあります。

ドメインの再構成が及ぼす影響を検証する

ドメインを再構成する理由を判断し、タイミングを決定したら、再構成が及ぼす影響を検証する必要があります。ここでは、次の内容について説明します。

  • セキュリティ プリンシパル、ユーザー グループとグローバル グループ、コンピュータ、メンバ サーバーを移動する

  • 信頼関係を確立する

  • セキュリティ プリンシパルを複製する

セキュリティ プリンシパルを移動する
基本的に、ドメインの再構成が可能なのは、 Windows 2000 のドメイン間でセキュリティ プリンシパルとドメイン コントローラを移動できるためです。また、再構成は、システムによるセキュリティ プリンシパルの識別方法、およびリソースへのアクセスの維持方法に重要な影響を及ぼします。このような影響が、ドメインを再構成する方法に影響を及ぼすことがあります。

SID への影響
ドメインに関連する SID の性質には、次のような因果関係があります。ユーザー、グループなどのセキュリティ プリンシパルをドメイン間で移動する場合、セキュリティ プリンシパルに新しいドメインのアカウント用の新しい SID を発行しなければなりません。

Windows NT のセキュリティ モデルでは、リソースへのアクセスは、オペレーティング システムがユーザー アクセス トークンを調べ、ユーザーのプライマリ SID およびユーザーがメンバになっているすべてのグループの SID をリソースのセキュリティ記述子の ACL と比較する方法に影響されます。ACL に保持される SID の一覧には、SID で識別されるセキュリティ プリンシパルにアクセスを許可または拒否できる情報が含まれるため、SID の変更は大きな影響を及ぼします。

SID の変更が及ぼす影響を次の例と図 10.7 に示します。Bob は Reskit 社の社員で、Windows NT のアカウント ドメイン Reskit-Acct 内にアカウントを持っています。また、Bob は同じドメインのグローバル グループ "Finance Analysts" のメンバです。

Reskit 社は、リソース ドメイン Reskit-Res1 内の多数の Windows NT サーバーで Windows NT の財務アプリケーションを実行しています。PDC に作成されたローカル グループは、このドメイン内のすべてのドメイン コントローラで共有されるため、このアプリケーションを実行するサーバーは、このドメインの BDC として設定されています。共有ローカル グループ "Financial Resources" は PDC に作成され、このアプリケーションが使用するファイルの ACL で使用されます。グローバル グループ "Reskit-Acct\Finance Analysts" は、"Reskit-Res1\Financial Resources" のメンバです。

sdgc1008

図 10.7: リソース アクセスの例

拡大表示する

このほか Bob は、リソース ドメインのファイル サーバー Fin_Files1 へのアクセスも保持しています。Fin_Files1 は、メンバ サーバーとして設定されている Windows NT サーバーです。Fin_Files1 では、Fin_Files1\Finance Files のメンバである Reskit-Acct\Finance Analysts に関連するファイルの ACL のローカル グループ "Finance Files" が使用されます。Bob は、個人的なプロジェクトに従事し、Fin_Files1 にディレクトリを持ち、Bob だけがこのディレクトリ内のファイルにアクセスできるよう保護されています。このディレクトリの ACL には、ディレクトリに対するすべての制御を Bob に許可する単一のエントリが保持されています。

セキュリティ プリンシパルの移動が及ぼす影響は、ドメインの再構成で行われる移行の過程で Reskit-Acct\Bob を別のドメインに移動した場合、何が起こるかを追跡すればわかります。この例では、Reskit-Acct が Windows 2000 にアップグレードされ、ルート ドメイン reskit.com の子として Windows 2000 フォレストに追加されています。ドメイン Reskit-Acct はネイティブ モードに切り替えられていますが、再構成され、メンバがフォレストの別の部分にある Reskit-Acct2 という Windows 2000 ドメイン に移動されています。

メモ この例は、"SIDhistory" という Windows 2000 の機能を使用できない場合に何が起こるかを示しています。再構成の過程でこのような状況に遭遇した場合、どのように処理すれば良いかを理解しておくことが重要です。SIDhistory については、この章の後で説明します。

グローバル グループ メンバーシップへの影響
Reskit-Acct\Bob は、グローバル グループ Reskit-Acct\Finance Analysts のメンバです。グローバル グループに保持できるのは、そのドメイン自体のメンバだけであるため、Bob を新しいドメインに移動すると、Bob の新しいアカウントが Reskit-Acct\Finance Analysts から除外され、Bob は、Reskit-Acct\Finance Analysts で使用できる有効なリソースへのアクセスを失います。

新しいドメインとリソース ドメイン間に適切な信頼関係が結ばれている場合、この状況はさまざまな方法で解決できます。

新しい SID をリソースの ACL に追加する
Bob が以前 Reskit-Acct\Finance Analysts のメンバとしてアクセスを保持していたすべてのリソースの ACL に、Bob の新しい SID を追加することにより、リソースへのアクセスを維持できます。この解決方法は、次の理由から時間がかかり、複雑になります。

  • ドメインの再構成にかかる時間は、時間が経過するほど長くなります。また、その間に、新しいリソースが Reskit-Acct\Finance Analysts に作成されないとも限りません。そのため、再構成の間も "アクセス許可の再付与" が必要です。

  • Bob の職務が変更され、Reskit-Acct\Finance Analysts のメンバである必要がなくなった場合、Bob を参照するリソースの ACL を変更するより、Reskit-Acct\Finance Analysts から Bob を削除するほうが簡単です。ユーザーおよびユーザーの職務は変更される可能性があるため、個々のユーザーではなくグループを使用して ACL を設定することをお勧めします。

グループを移動する
Windows 2000 では、セキュリティ プリンシパルを移動できるため、Reskit-Acct\Finance Analysts を新しいドメインに移動することが可能です。ただし、このグループを参照する ACL もグループ SID を参照するため、リソースに新しい SID を参照するためのアクセス許可を与える必要があります。

ターゲット ドメインに " 並列 " グループを作成する
Reskit-Acct\Finance Analysts を別のドメインに移動する場合、すべてのグループ メンバを 1 回のトランザクションで移動しないと問題が発生します。これは、このグループを古いドメインで維持し、新しい "並列" グループを新しいドメインに作成しなければならないためです。リソースへのアクセスは、オリジナルのグループとそのメンバで維持されますが、新しいグループへのアクセスを与えるために、リソースに再度アクセス許可を与える必要があります。このようにグループが両方のドメインに存在している間は、アクセス許可の再付与を続けなければなりません。

これは、SIDhistory を使用できない場合です。SIDhistory については、この章の後で説明します。

ユーザーを直接参照する ACL への影響
Bob の SID はメンバ サーバー Fin_Files の ACL にあるため、Reskit-Acct\Bob にはこのサーバーの一部のリソースへの直接アクセスが与えられています。ユーザーをリソースの ACL に追加するのが合理的ですが、Reskit-Acct\Bob を移動すると、このサーバーのリソースに対するアクセス権を再付与しなければなりません。これにより、Bob のアカウントに新しいドメインの SID が追加されます。

SIDhistory
Windows 2000 には SIDhistory という機能があるため、多くの場合、Reskit 社の例に示した作業は必要ありません。SIDhistory は、Active Directory のセキュリティ プリンシパルの属性で、ユーザー、セキュリティ グループなど移動されたオブジェクトの以前の SID を格納するために使用されます。

Microsoft が提供する Windows 2000 ユーティリティを使用してユーザーを移動すると、Active Directory 内のこのユーザー オブジェクトの SIDhistory 属性が以前の SID で更新されます。その後、ユーザーがシステムにログオンすると、システムによりユーザーの SIDhistory エントリが検索され、ユーザー アクセス トークンに追加されます。また、グループも移動可能なため、システムにより、ユーザーがメンバになっているすべてのグループの SIDhistory 属性も検索され、ユーザー アクセス トークンに追加されます。

認証チェックの間、トークンの SIDhistory エントリは、システムに対して通常のグループ メンバーシップと同じように表現されるため、Windows 2000 または Active Directory をまったく認識しない Windows 2000 以前のシステムでも、適切なアクセス権を与えることができます。図 10.8 に、SIDhistory でリソース アクセスが与えられる様子を示します。

sdgc1009

図 10.8: SIDhistory で与えられるリソース アクセス

拡大表示する

Windows NT 3.51 と SIDhistory
Windows 2000 ドメインに Windows NT 3.51 システムがある場合、グループ メンバーシップおよび使用に関する問題があります。これには、Windows NT 3.51 がドメイン コントローラからグループ メンバーシップの SID を受け取り、セキュリティ アクセス トークンを作成する方法が関係しています。ユーザーが認証されると、Windows NT 3.51 のアカウント トークンは、認証が行われたサーバーまたはクライアントのユーザー アカウント ドメインおよびローカル グループに関連する SID だけから作成されます。そのため、Windows NT 3.51 システムは、このアカウント ドメイン外のユニバーサル グループ、またはリソース ドメインのローカル グループを認識できません。

ユーザーまたはユーザーがメンバになっているユニバーサル グループの SIDhistory のエントリは、アカウント ドメイン以外のドメインのものであるため、トークンから除外されます。その結果、Windows NT 3.51 では、アクセス制御を評価するときに、ユーザーがログオンするアカウント ドメイン以外のドメインのグループ メンバーシップの SID が無視されます。多くの場合、アクセスは拒否されますが、これは望ましい結果ではありません。

ユーザーとグローバル グループを移動する
グローバル グループに保持できるのは、それ自体のドメインのメンバだけであるため、ドメイン間でユーザーを移動するときには、ユーザーがメンバになっているグローバル グループも移動しなければなりません。これは、グローバル グループを参照する ACL で保護されているリソースへのアクセスを維持するために必要です。また、グローバル グループを移動する場合には、そのメンバも移動しなければなりません。

この場合、次の状況に該当するときに、限定的なユーザーとグローバル グループが 1 セットになります。

  • 移動されるユーザーごとに、セットのすべてのグローバル グループも移動される。

  • 移動されるグループごとに、そのすべてのメンバも移動される。

ソース ドメインがネイティブ モードのドメインの場合、グローバル グループにはその他のグローバル グループも保持できます。そのため、ネストされている各グループとネストされているグループ内のメンバを保持するすべてのグローバル グループを移動しなければなりません。

プロファイルと SIDhistory を移動する
ドメインの再構成を計画するときには、移行されたユーザーが新しい SID を受け取り、これがユーザーのプロファイルの使用に影響する可能性があることを認識していなければなりません。移行後、各自のコンピュータにログオンするユーザーが、自分のログオン プロファイルにアクセスできなくなることがあります。これは、古いプロファイルがそのまま古いプライマリ SID で格納されることがある一方、ユーザーのプライマリ SID が変更されるからです。このような状況は、次のような場合に起こります。

  • ユーザーが Windows NT 4.0 ドメインから複製された。

  • ユーザーが Windows 2000 ドメインから複製された。

  • ユーザーは Windows 2000 ドメインから複製されているが、Windows NT 4.0 Workstation からログオンしようとしている。

ユーザーが自分のログオン プロファイルにアクセスできない場合、プロファイルをコピーするか共有すると、プロファイルを使用できるようになります。プロファイルをコピーする方法がより適切です。

プロファイルをコピーする
最初の方法では、ユーザーのオリジナルの SID から名前付けされたキーの下の現在の位置から、ユーザーの新しい SID から名前付けしたキーにオリジナルのプロファイルをコピーします。各アカウントは、そのプロファイルの別のコピーに関連付けられますが、一方のプロファイルを更新しても、他方のプロファイルには反映されません。

この方法を使用すると、Windows 2000 の動作を予測しやすくなります。プロファイル間でデータが共有されていないため、一方のプロファイルが、別のドメインまたはフォレストにある他方のアカウントにのみ有効なデータで、アカウントにアクセスすることがありません。

この方法には、次の欠点があります。

  • 2 つのプロファイルが格納されるため、より多くのディスク容量が消費されます。

  • 回復に予測外の結果が生じます。グループ ポリシーを使用するアプリケーションのインストールが及ぼす影響を綿密にテストし、不測の事態に備えてください。

プロファイルを共有する
この方法では、同じプロファイルをユーザーのオリジナルのアカウントと新しいアカウントで使用できるようにします。この場合、プロファイルの 1 つのコピーを両方のアカウントがアクセスし、更新します。この方法には、次の利点があります。

  • ユーザーが一方のアカウントにログオンした状態で行うプロファイルの更新 (たとえば、[My Documents] フォルダ、ショートカットなどの変更) は、次に他方のアカウントにログオンしたときにアクセスできます。

  • プロファイルのコピーが 1 つだけ格納されるため、ディスク容量が節約されます。

この方法の欠点は、プロファイルの使用に影響を与える可能性のある未知の変数があることです。たとえば、グループ ポリシーの参照を保持する Windows 2000 の新しいアカウントを作成する場合、グループ ポリシーが異なるか、グループ ポリシーが使用されていないソース アカウントに戻した場合の影響をテストする必要があります。

コンピュータを移動する
共有ローカル グループおよびドメイン ローカル グループの範囲は、このグループが作成されたドメイン内に限られるため、これらのグループを移動すると、ソース ドメインの ACL 内のグループへの参照が解決されないままになります。

この場合、次の状況に該当するときに、限定的なコンピュータおよび共有またはドメイン ローカル グループが 1 つのセットになります。

  • 移動されるコンピュータごとに、コンピュータ リソースの ACL で参照されるすべての共有またはドメイン ローカル グループも移動される。

  • 移動されるグループごとに、このグループを参照する ACL を保持するドメイン内のすべてのコンピュータも移動される。

展開されているグローバル グループおよび限定的なセットの移動に関する制約は、特に厳密です。大規模なグローバル グループを削除し、再配置する作業には、時間がかかります。また、限定的なセットは、最も小規模なものでもソース ドメイン全体にわたることもあります。この問題は、次の 3 とおりの方法で解決できます。

  1. 移動するグループごとに、ターゲット ドメインに並列グローバル グループを作成し、オリジナルのグループを参照する ACL を保持する企業内のすべてのリソースを検索し、並列グループへの参照が含まれるように再度アクセス権を与えます。

    この方法では、次の場合にグローバル グループを移動すると、作業が大がかりになることがあります。

    • 信頼する側のドメインのリソースでグループが参照される。

    • ドメイン内の任意のコンピュータでドメイン ローカル グループを使用できるネイティブ モードのソース ドメインのドメイン ローカル グループがある。

  2. ソース ドメインをネイティブ モードに切り替え、移動するグループのグループ タイプをユニバーサルに変更します。ユニバーサル グループの範囲はフォレスト全体にわたるため、グループをユニバーサル グループに変更するとグループを安全に移動できますが、リソースへのアクセスの維持は以前の状態にとどまります。

    ユニバーサル グループのメンバーシップは GC に格納され、GC の複製トラフィックに影響を与えるため、この方法を使用するときには注意してください。また、この理由から、ユーザーおよびグループを新しいドメインに移行する間の移行方針として、この方法を厳密に使用することができます。移行完了後に、グループを元のタイプに戻すことができます。

  3. SIDhistory を維持しながら、グループをソース ドメインからターゲット ドメインに複製します。この方法には制約があります。この制約については、この章の後の「セキュリティ プリンシパルを複製する」で説明します。

メンバ サーバーを移動する
前に示した例で、Bob は、コンピュータ ローカル グループ Fin_Files1\Finance Files を参照する ACL および Bob のドメイン アカウントを直接参照する ACL を通じて、メンバ サーバー Fin_Files1 の一部のリソースへのアクセスを保持しています。

共有ローカル グループおよびドメイン ローカル グループを維持する必要性など、ドメイン コントローラの移動が及ぼす影響については、この章の前に説明しました。Fin_Files やクライアントなどのメンバ サーバーを移動した場合には、これとは違った影響があります。

メンバ サーバーを、Bob の新しいアカウント ドメインに対する信頼を保持するドメインに移動する場合、SIDhistory により、Bob は Bob を直接参照する ACL によってリソースにアクセスできます。コンピュータ ローカル グループはローカル コンピュータのアカウント データベースに存在するため、移動後もこのグループを参照する ACL は機能し続けます。つまり、グループは移動の影響を受けないため、グループの SID を変更する必要はありません。

信頼関係を確立する
ドメインをアップグレードする間、ターゲット ドメインから関連するすべてのリソース ドメインへの適切な信頼関係があり、リソースへのアクセスは維持されるものと見なされます。これらの信頼関係は、ドメインにどのような再構成を行う場合も、最初に確立されていなければなりません。

Netdom は、ドメインの信頼関係の列挙、新しい信頼の確立などの作業を実行するツールです。また、コンピュータ アカウントの作成、クライアントまたはサーバーのドメイン メンバーシップの更新にも役立ちます。

セキュリティ プリンシパルを複製する
これまでに説明した再構成では、セキュリティ プリンシパルを移動しました。セキュリティ プリンシパルを移動すると、宛先ドメインに同一の新しいアカウントが作成され、ソース ドメインからこのアカウントが削除されます。このような移動操作では、移行に問題が起こった場合でも、アカウントを古い状態に戻すことができません。

パイロット プロジェクトまたは業務環境の移行で問題が起こった場合に、確実に回復できるようにするには、ソース ドメインで古いアカウントを維持しながら、ユーザーを徐々に Windows 2000 ドメインに移行することをお勧めします。このような移行は、ClonePrincipal ユーティリティを使用して複製ユーザーまたはグループを作成する複製によって実行できます。このユーティリティには、グローバル グループの複製、ユーザーの複製などの作業を実行する一連の Microsoft® Visual Basic® (VB) スクリプトが含まれています。

ドメイン再構成のシナリオ

ここで説明する 2 つのシナリオは、ドメインの再構築のほとんどの要件を満たしています。どちらのシナリオも、Windows NT のソース ドメインから Windows 2000 のターゲット ドメインにユーザーおよびコンピュータを簡単に移動できます。この例は、次のとおりです。

  • ユーザーを徐々に Windows 2000 に移行する (フォレスト間)

  • リソースを Windows 2000 の OU に移行する (フォレスト間)

シナリオ 1: ユーザーを徐々に Windows NT から Windows 2000 に移行する

このシナリオでは、Windows NT の業務環境に影響を与えずに、ユーザーを徐々に純粋な Windows 2000 環境に移行します。図 10.9 に、この例を示します。ここでは、段階的な移行に必要な手順とユーティリティについて説明します。

sdgc1010

図 10.9: 段階的なユーザーの移行

メモ 移行による変化から現在の業務環境を保護することにより、移行プロセス中も業務環境をそのまま維持できます。必要ならば、古い業務環境に戻すこともできます。

移行が完了したら、古いアカウント ドメインを廃止し、ドメイン コントローラを再割り当てすることができます。その後、次の手順に従います。

  1. 純粋な Windows 2000 フォレストを作成します。 標準的な手順で、企業のネームスペース計画で特定した要件および構造を反映させた Windows 2000 の宛先フォレストを作成します。新しいフォレストに作成するドメインは、ネイティブ モードの Windows 2000 ドメインになります。

  2. フォレストでリソース アクセスを維持するために必要な信頼をフォレストに確立します。この作業では、Netdom を使用して、リソース ドメインから Windows NT のリソース ドメインに存在している信頼関係を照会します。

    Netdom の出力と、ターゲット ドメイン内のユーザーおよびグループにリソース アクセスを許可するために必要な信頼の一覧を比較できます。次に、Netdom を使用して、存在していない信頼を確立します。

  3. ターゲット ドメイン内のソース グローバル グループをすべて複製します。多くのリソースは、通常は共有ローカル グループまたはコンピュータ ローカル グループによって間接的に、グローバル グループを参照する ACL で保護されています。信頼を確立したら、関係するグローバル グループをターゲット ドメインでも使用できるかを確認しなければなりません。

    グローバル グループの使用状況を確認するには、ClonePrincipal を使用してすべてのグローバル グループを複製するのが最も簡単です。

  4. 一連のユーザーを特定し、複製します。ソース グローバル グループをターゲット ドメインに複製したら、ユーザーの移行を開始できます。

    多くの場合、移行する一連のユーザーを特定し、ClonePrincipal を使用して宛先ドメインにソース ユーザーを複製し、一連のユーザーを移動するため、反復的な作業になります。

  5. ソース ドメインを廃止します。すべてのユーザーおよびグループを宛先フォレストに恒久的に移動したら、最後にソース ドメインを廃止します。ソース ドメインを廃止するには、ソース ドメインの BDC、ソース ドメインの PDC の順に電源を切り、取り外します。災害時の復旧用として、PDC を保存することをお勧めします。

    これらのドメイン コントローラを新しいフォレスト内で再割り当てする場合、これを Windows 2000 にアップグレードして、ドメイン コントローラに昇格することも、そのままメンバ サーバーとして使用することもできます。

特に、ユーザーを移行するフェーズで、移行するごとに特定のユーザーのログオンをテストすることをお勧めします。ソース ドメインの廃止前の段階でエラーが発生した場合、プロセスを中断して、ソース業務ドメインで作業を続けることができます。

シナリオ 2: リソース ドメインを OU に集約する
この例では、リソース ドメインをネイティブ モードの Windows 2000 ドメインの OU に集約します。リソースを集約すると、複雑な信頼の管理コストを節約できます。図 10.10 に、この例を示します。ここでは、段階的な移行に必要な手順と基本ユーティリティについて説明します。

sdgc1011

図 10.10: リソース ドメインの Windows 2000 の OU への集約

この例では、アプリケーション サーバーがターゲット OU のメンバ サーバーになります。各ドメインのアプリケーション サーバーは、共有ローカル グループを使用しているものとします。また、ドメインには、メンバ サーバーとクライアントを保持できるものとします。

ドメインの再構成が完了したら、古いドメインを廃止できます。リソース ドメインを Windows 2000 の OU に集約する手順は、次のとおりです。

  1. ターゲット ドメインからフォレスト外のアカウント ドメインに必要な信頼を確立します。この作業では、Netdom を使用して、リソース ドメインからアカウント ドメインに存在している信頼関係を照会します。その後、Netdom の出力を、ターゲット ドメインからアカウント ドメインに存在している信頼関係と比較できます。次に、Netdom を使用して、存在していない信頼関係を確立します。

  2. すべての共有ローカル グループを複製します。共有ローカル グループの範囲は、このグループが作成されたドメイン内に限られ、このドメイン内のドメイン コントローラ間でのみ共有されます。すぐに、すべてのドメイン コントローラをターゲット ドメインに移動する必要はありません。ドメイン コントローラとリソースがソース ドメインとターゲット ドメインに分割されている間、リソース アクセスを確保するには、ClonePrincipal を使用して、共有ローカル グループをターゲット ドメインに複製する必要があります。

  3. アプリケーション サーバーをメンバ サーバーに降格します。すべての共有ローカル グループを複製すると、アプリケーション サーバーをターゲット OU のメンバ サーバーに変換し始めることができます。

    リソース ドメインの PDC を Windows 2000 にアップグレードし、移行中、このドメインを混在モードで実行します。次に、降格する BDC をアップグレードできます。BDC のアップグレード中に Active Directory インストール ウィザードを実行して、この BDC をメンバ サーバーにするよう選択します。

    PDC をアップグレードできないか、アップグレードしたくない場合、アップグレードするごとに BDC をオフラインにして、PDC に昇格する必要があります。PDC に昇格した BDC は、Windows 2000 にアップグレードできるため、オフラインのドメイン コントローラを効果的に "複製された" Windows 2000 の混在モードのドメイン内の PDC にできます。オフラインの状態で PDC をアップグレードすると、Active Directory インストール ウィザードを実行して、PDC をメンバ サーバーに降格できます。次に、このメンバ サーバーをターゲット ドメインに追加します。

  4. メンバ サーバー (以前の BDC を含む) とクライアントを移動します。この作業では、Netdom を使用して、移動するメンバ サーバーまたはクライアントのコンピュータ アカウントを宛先ドメイン OU に作成できます。コンピュータを宛先ドメインに追加します。

  5. ソース ドメインを廃止します。すべてのグループとコンピュータを恒久的に宛先フォレストに移動したら、最後にソース ドメインを廃止します。ソース ドメインを廃止するには、ソース ドメインの BDC、ソース ドメインの PDC の順に電源を切り、取り外します。

    ソース ドメイン コントローラを新しいフォレスト内で再割り当てする場合には、これを Windows 2000 にアップグレードして、Windows 2000 のドメイン コントローラに昇格することも、そのままメンバ サーバーとして使用することもできます。

    メモ このシナリオでは、BDC をメンバ サーバーに降格するときに、できる限り早急にこれをターゲット ドメインに移動する必要があります。ドメインがネイティブ モードで、共有ローカル グループがドメイン ローカル グループに変換されないと、メンバ サーバーは、これらのグループを通じてアクセス可能なリソースを使用できません。

ドメイン移行ツール

ここでは、この章で使用するドメイン移行基本ユーティリティおよび Windows 2000 Server リソースキット ツールについて説明します。機能および使用方法の詳細については、それぞれのツールを参照してください。

ClonePrincipal

ClonePrincipal は、次の COM オブジェクトとサンプル スクリプトで構成されるユーティリティです。このスクリプトは、Visual Basic を使用してカスタマイズできます。

  • DSUtils.ClonePrincipal 次の 3 つのメソッドをサポートする COM オブジェクト

    • AddSidHistory — ソース プリンシパルの SID を既存の宛先プリンシパルの SIDhistory にコピーします。

    • CopyDownlevelUserProperties — ソース プリンシパルの Windows NT プロパティを宛先プリンシパルにコピーします。

    • Connect — ソースおよび宛先ドメイン コントローラへの認証済み接続を確立します。

ClonePrincipal では、既存の Windows NT の業務環境に影響を与えずに、ユーザーを段階的に Windows 2000 環境に移行できます。この移行は、Windows 2000 環境に Windows NT ユーザーおよびグループを複製して行われます。ClonePrincipal を使用してこの方法で移行すると、次のような利点が得られます。

  • ユーザーは、宛先アカウント (複製) にログインでき、試用期間中の緊急時にはソース アカウントに戻すことができます。

  • 同時に複数のユーザーを宛先 Windows 2000 環境に移動できます。

  • ユーザーを宛先 Windows 2000 環境に移行している間は、ソース業務環境がそのまま維持されます。

  • ACL を更新しなくても、宛先アカウントのグループ メンバーシップおよびネットワーク アクセスが維持されます。

  • 名前または目的が同じでソース ドメインが異なる複数のグループを、同じ宛先オブジェクトに "結合" できます。

このほか、ClonePrincipal でローカル グループを複製すれば、多数の小規模なリソース ドメインを Windows 2000 の OU に集約できます。

AddSidHistory メソッドは、セキュリティに依存する操作で、次の制約があります。

  • AddSidHistory には、ソース ドメインおよび宛先ドメインのドメイン管理者の資格情報が必要です。ソース ドメインおよび宛先ドメインは、同じフォレスト内に存在できません。ソース ドメインと宛先ドメイン間に外部への信頼があってもかまいませんが、この機能にはこのような信頼は必要ありません。

  • AddSidHistory イベントは監査が可能なため、ソースおよび宛先ドメインの管理者は、いつこの機能が実行されたかを検出できます。AddSidHistory を正常に機能させるには、ソース ドメインで監査することをお勧めしますが、必ずしも必要ではありません。また、宛先ドメインでは監査を有効にしなければなりません。

  • ClonePrincipal のサンプル スクリプトは、基礎となる AddSidHistory メソッドを呼び出すため、その他の ClonePrincipal ユーティリティのセキュリティ感度と制約は、AddSidHistory と同じになります。

Netdom

Netdom は、コマンド ラインから Windows 2000 ドメインおよび信頼関係を管理するツールです。

次の操作を行うには、Netdom を使用します。

  • Windows 2000 コンピュータを Windows NT または Windows 2000 ドメインに追加し、次の操作を行います。

    • コンピュータ アカウントの OU を指定するオプションを提供します。

    • 最初に参加したときに、ランダムなコンピュータ パスワードを生成します。

  • ドメインのメンバ クライアントおよびメンバ サーバーのコンピュータ アカウントを管理し、次の操作を行います。

    • 追加、削除、照会を行います。

    • コンピュータ アカウントの OU を指定するオプションを提供します。メンバ クライアントの既存のコンピュータ アカウントをドメイン間で移動し、移動したコンピュータ アカウントのセキュリティ記述子を維持するオプションを提供します。

  • 次のタイプのドメイン間に信頼関係 (一方向または双方向) を確立します。

    • Windows NT ドメイン

    • ドメイン ツリー内の Windows 2000 の親ドメインと子ドメイン

    • Kerberos 領域への信頼リンクの Windows 2000 部分

  • 次の設定のセキュリティで保護されたチャネルを検証およびリセットします。

    • メンバ クライアントとサーバー

    • Windows NT ドメインの BDC

    • 特定の Windows 2000 レプリカ

  • ドメイン間の信頼関係を管理します。

    • すべての信頼関係を表示します。

    • 直接的な信頼関係を列挙します。

    • すべての (直接および間接) 信頼関係を列挙します。

移行計画の作業リスト

表 10.7 に、移行計画で行う作業をまとめます。

表 10.7 移行計画作業のまとめ

作業

この章の参照場所

移行ロードマップを決定する。

「移行計画プロセスを開始する」

サポートされているアップグレード パスを判断する。

「ドメイン アップグレードを計画する」

既存のドメイン構造を検証する。

「ドメイン アップグレードを計画する」

回復計画を開発する。

「ドメイン アップグレードを計画する」

ドメイン コントローラのアップグレード方針を決定する。

「ドメイン アップグレードを計画する」

ドメインのアップグレード順序を決定する。

「ドメイン アップグレードを計画する」

ネイティブ モードに移行するタイミングを決定する。

「ドメイン アップグレードを計画する」

ドメインを再構成する理由を判断する。

「ドメインの再構成を計画する」

ドメインを再構成するタイミングを決定する。

「ドメインの再構成を計画する」

ユーザーとグループを移動する。

「ドメインの再構成を計画する」

コンピュータを移動する。

「ドメインの再構成を計画する」

メンバ サーバーを移動する。

「ドメインの再構成を計画する」

信頼を確立する。

「ドメインの再構成を計画する」

セキュリティ プリンシパルを複製する。

「ドメインの再構成を計画する」

ネイティブ モードに切り替える。

「ドメイン アップグレードを計画する」
「ドメインの再構成を計画する」