Windows NT から Windows 2000 への移行計画

  • [アーティクル]

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

概要
この文書は、Microsoft® Windows NT® (以下 Windows NT) ドメインから Microsoft Windows® 2000 (以下 Windows 2000) への移行を行う際の計画作業と検討事項の概要について説明したものです。Windows 2000 で提供されている新しいユーティリティ、ツール、およびテクノロジを利用することで、リソースへのアクセスを維持したままユーザーとコンピュータの移行作業を容易に進めることができます。

トピック

はじめに はじめに
移行の全般的な流れの決定 移行の全般的な流れの決定
移行目的 移行目的
移行の概念 移行の概念
ドメインのアップグレード ドメインのアップグレード
ドメインの再構築 ドメインの再構築
決定事項のチェックリスト 決定事項のチェックリスト
アップグレードに関する決定事項 アップグレードに関する決定事項
再構築に関する決定事項 再構築に関する決定事項
まとめ まとめ
詳細情報 詳細情報

はじめに

このホワイト ペーパーは、企業環境における Windows NT 3.51 または Windows NT 4.0 から Windows 2000 への移行計画概要を示すことを目的としています。

このホワイト ペーパーでは、Windows NT ドメインのアップグレードによる Active Directory 名前空間の実装計画について主に解説しています。以降、Active Directory 名前空間のほとんどは既に存在するものとして説明します。

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

移行の全般的な流れの決定

どのような計画作業においても重要な意味を持つ選択がありますが、移行計画においては、オペレーティング システムの機能の中で特定の望ましい機能を利用できるようにするかどうか、という選択があります。

この節では、作業の優先順位を決める際に検討すべき次の事柄について説明します。

  • 想定される移行目的。

  • 移行の基準となる概念。この概念をもとに、移行の全般的な流れを具体化するための選択肢と、それらの選択肢が移行目的に与える影響を理解できます。

この節を通じて、移行の全般的な流れを遂行するために必要な情報と、計画進行に支障を来すいくつかの危険について認識してください。

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

移行目的

移行目的としては、業務関連の目的、あるいは移行そのものに関連する目的が考えられます。

業務関連の目的の場合は、そのほとんどが初めての移行作業の実施を伴います。この種の目的には実装内容の選択が含まれ、可能性のあるトレードオフの評価に使用できます。通常は何らかの準拠表を準備しておき、後の段階でそれを使用して最終的なプラットフォームに実装するテクノロジや製品機能を特定します。

移行関連の目的の場合は、移行の結果そのものが目的となります。これらは生産システムの中断、最終的なシステムのパフォーマンス、および平均故障間隔などの不測の事態によって影響を受けることがあります。これらの目的によって、テスト計画とその許容条件をどのように具体化するのかを決定できます。

移行計画においては、"Windows 2000 のテクノロジの利点を最大限に生かすことができるように、できるだけ速やかにWindows 2000 のネイティブ モードに移行すること" が主たる目的となるようにしてください。

表 1 業務関連目的の典型的な例

目的

機能

利点

管理能力の強化

Kerberos 推移的な信頼

推移的または暗黙の信頼により、複雑で明示的な信頼の必要性が減ります。

管理能力の強化

Active Directory によるリソースのロケーションと管理

Active Directory により、一貫した 1 つのインターフェイス セットが提供され、共通の管理タスクの実行や人およびリソースの検索が企業全体にわたって行えます。

管理能力の強化

Active Directory 組織単位 (OU)

管理権限を OU のレベルで委任できます。

管理能力の強化

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

Windows 2000 では、従来よりも広い範囲で非常に多くの種類のグループが提供されます。

スケーラビリティの強化

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

Windows 2000 Server では 64 ビット プロセッサ上で最大 32 GB のメモリ アクセスが可能です。

スケーラビリティの強化

Active Directory のスケーラビリティ

Active Directory により、無数のオブジェクトを格納できる能力を持つ、従来よりも多様なレベルのスケーラビリティが提供されます。

スケーラビリティの強化

Kerberos 認証

これにより接続セットアップ時のサーバー負荷が軽減され、パフォーマンスが向上します。

スケーラビリティの強化

Microsoft 管理コンソール (MMC)

MMC により、企業の管理ツール セットのデザインや機能が標準化されます。

セキュリティの強化

グループ ポリシー

グループ ポリシーにより、管理者はユーザーが持つ特定のワークステーションやデータ、アプリケーションなどへのアクセス権をきめ細かく制御できます。

セキュリティの強化

セキュリティ構成ツール セット (SCTS)

SCTS は MMC スナップインのセットです。これにより、レジストリ ハイブやファイル システムなどのオブジェクト ツリーを、パスワード ポリシーなどのセキュリティ ポリシーとともに、セキュリティ構成テンプレート内に定義できるようになります。

セキュリティの強化

セットアップ

Windows 2000 は、従来よりも強力な既定のセキュリティ設定が適用されてインストールされます。

セキュリティの強化

Active Directory マルチマスタ複製

この機能により、ドメイン コントローラに障害が起きてもシステムの可用性が

 

メモ 上の表 1 に列挙されている目的を可能にするためには、どの場合でも Windows 2000 Server によるサポートが必要です。

表 2 移行関連目的の典型的な例

目的

移行作業に伴う影響

生産環境の中断の最小化
  • 移行中および移行後も、ユーザーによるデータおよびリソースへのアクセスを維持する必要があります。
  • 移行中および移行後も、ユーザーによるアプリケーションへのアクセスを維持する必要があります。
  • ユーザーの使い慣れた環境を、移行中および移行後も維持する必要があります。

管理上のオーバーヘッドの最小化
  • ユーザー アカウントをシームレスに移行する必要があります。
  • ユーザーのパスワードを維持する必要があります。
  • 管理者によるワークステーションへのアクセスを最小限に抑える必要があります。
  • リソースへの新しい権限をセットアップする必要が生じないようにします。

" 先手必勝 " の最大化

企業が新しいプラットフォームの主要な機能をいち早く利用できるようにする必要があります。

システム セキュリティ

セキュリティ ポリシーについて機能の向上以外の影響を与えないようにします。

 

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

移行の概念

望ましいインフラを実現するには次の 2 つの手段が考えられます。

  • ドメインのアップグレード ("インプレース アップグレード" とも呼ばれます)。

  • ドメインの再構築 ("ドメインの統合" または "ドメインコラプス (collapse)" とも呼ばれます)。

アップグレードと再構築を両方同時に行うことはできません。個々の組織に応じて、先にアップグレードを行ってから再構築を行うか、または再構築を先に行ってからアップグレードを行います。

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

ドメインのアップグレード

Windows 2000 Server へのアップグレードは、最も簡単で危険の少ない移行手段です。

ドメインのアップグレードとは、ドメインのプライマリ ドメイン コントローラ (PDC) 上のソフトウェアをアップグレードする作業と、バックアップ ドメイン コントローラ (BDC) の一部または全部を Windows NT 4.0 から Windows 2000 Server にアップグレードする作業として定義することにします。

Windows 2000 は、Windows 95 および Windows 98、Windows NT 4.0、および Windows 2000 で構成される混在ネットワークについても完全な相互運用性が確保されるように設計されています。したがって、ドメイン内のすべてのシステムをアップグレードしなくても Windows 2000 の機能を利用できます。ただし、PDC のアップグレードは必ずアップグレードの最初の段階で実行する必要があります。これは、その後にバックアップ ドメイン コントローラ (BDC) を、さらにメンバ サーバーを順にアップグレードすることで、機能が段階的に利用できるようになるためです。

この作業は、オペレーティング システムの新規インストールではなくアップグレードであるため、既存のドメイン構造やユーザー、グループなどはそのまま維持され、なおかつアップグレードの処理中も Windows 2000 の新機能を使用できます。実際、アップグレードと統合の最大の違いは、アップグレードでは既存のドメイン構造が維持されることです。

アップグレードが完了して Windows 2000 の高度な管理ツールや機能が利用できるようになると、ドメインの再構築が望ましいと考えるかもしれません。しかし、再構築の作業は決して簡単なものではなく、この文書の「ドメインの再構築」の節で説明しているように、そのための計画や実装の作業がさらに必要になります。

移行目的の 1 つとして構造上の変更を計画している場合は、移行の際に再構築を行うための方法も検討します。

ドメインのアップグレードに伴う影響
アップグレードでは、システム設定や詳細設定、インストールされているプログラムなどのほとんどがそのまま保持されます。このため最も簡単で危険の少ない移行手段といえます。この節では、アップグレードが実際に DC およびセキュリティ プリンシパルに与える影響について考察し、計画を立てる際のこれらの重要性について説明します。

Active Directory のインストール ウィザード (DCPromo.exe)
ドメイン内のすべての BDC を強制的に同期化させた後、PDC のアップグレードによってアカウントのドメインのアップグレードを開始し、PDC に加えられた最新の変更内容を反映するように BDC を完全に更新することができます。

中心となるオペレーティング システムを PDC 上にインストールした後、セットアップ プログラムは DC がアップグレード中であることを検出し、自動的に DCPROMO プログラムを実行することによって、Active Directory をサーバー上にインストールするように管理者に促します。

DCPROMO では、管理者は "新しいフォレスト内に 1 番目のツリーを作成する"、"既存のフォレスト内に新しいツリーを作成する"、"既存のドメインの複製を作成する"、または "子ドメインをインストールする" のいずれかを選択できます。どれを選択するかは名前空間の計画過程で得られる結果によって決まります。

メモ ここでは手順の詳しい説明は省きます。このほか、万一深刻な問題が発生して元に戻す必要が生じた場合に備えて、ドメインのバックアップなどの作業を検討することも必要です。同期化とアップグレードを行う前にあらかじめドメインに BDC を別途追加してから、アップグレードの間その BDC をオフラインにする方法もあります。詳細については『Windows 2000 システム展開ガイド』を参照してください。

Windows NT PDC
Active Directory のインストール処理では、Windows NT のアカウント データベースとセキュリティ アカウント マネージャ (SAM) が Active Directory にコピーされます。これらのオブジェクトはセキュリティ プリンシパル (ユーザー アカウント、ローカル グループ、グローバル グループ、およびコンピュータ アカウント) です。

PDC のアップグレードと Active Directory のインストールが完了すると、直ちにドメインが Windows 2000 の "混在モード" で稼働します。混在モードとネイティブ モードの詳細については、後述の「混在モードとネイティブ モード」を参照してください。

これ以後、Windows 2000 Server PDC は、Active Directory を使用してオブジェクトを格納します。PDC は複製の中で、データをフラット ストアとして Windows NT BDC に公開します。このため、Windows 2000 Server PDC には完全な下位互換性があります。このことは次に示すいくつかの現象からもわかります。

  • この PDC は、ほかの Windows 2000 コンピュータからは Windows 2000 DC のように見え、まだアップグレードされていないコンピュータからは Windows NT PDC のように見えます。

  • 引き続き、この PDC を使用して新しいセキュリティ プリンシパルを作成し、これらの変更を Windows NT Server BDC に複製できます。

  • Windows NT および Windows 95 および Windows 98 の各ワークステーションは、この PDC をログオン可能なサーバーとして使用できます。

  • Windows 2000 Server PDC がオフラインになったり、または利用できなくなったりしたとき、ドメイン内にほかの Windows 2000 DC が存在しない場合は、Windows NT BDC を PDC に昇格できます。

アップグレードがアクセス制御に与える影響
PDC のアップグレード処理ではセキュリティ プリンシパルが Active Directory に移動されますが、このことはリソースへのアクセスに影響を与え、重要な問題の 1 つになります。

セキュリティ ID (SID)
Windows NT のセキュリティ モデルでは、ユーザー、グループ、コンピュータ、ドメイン信頼などのアカウント オブジェクトが SID によって識別されます。SID はドメイン内で一意な値であり、ユーザーやグループが作成されるとき、またはコンピュータや信頼がドメインに登録されるときに生成されます。

SID は階層的な構造を成しています。1 個の SID は、リビジョン番号を識別する部分と、SID を発行した機関 (ドメインなど)、および可変個の 2 次機関または相対識別子 (RID) で構成されています。RID は、発行元の認証元に関連するセキュリティ プリンシパルを一意に識別するものです。

SID には、すべてのシステムで有効な汎用のグループやユーザーを識別する既知の SID がありますが、ここで問題となるセキュリティ プリンシパルの大部分は、ドメインのコンテキストの中で識別されます。したがって、それらの SID を変更しないでドメイン間で移動することはできません。

認証とアクセス トークン
Windows NT セキュリティ モデルで欠かすことのできない構成要素として、認証があります。通常、認証はユーザー名とパスワードの形式をとり、資格情報の提示によってユーザーがドメインに識別されます。これらの資格情報が適正なものとみなされると、システムは、ユーザーのためのアクセス トークンを作成します。アクセス トークンには、ユーザーの SID (プライマリ SID) と、そのユーザーがメンバとなっているすべてのドメイン グループの SID が含まれています。ユーザーがアプリケーションを実行するなどして作成したプロセスには、すべてユーザーのアクセス トークンが含まれています。

システムはこのアクセス トークンを使用して、システム リソースへのアクセス権をユーザーに許可すべきかどうかを判断します。

認証とセキュリティ記述子
ユーザーのアクセス トークンに相当するのは、ファイルやプリンタなどのリソースに付随しているセキュリティ記述子です。セキュリティ記述子にはアクセス制御リスト (ACL) が含まれ、ACL はアクセス制御エントリ (ACE) のリストを構成します。各 ACE には、それぞれ SID とインジケータが含まれています。このインジケータは、SID によって識別されるセキュリティ プリンシパルに対して、リソースへの何らかのアクセスが許可されているかまたは拒否されているかを示すものです。

以上の説明から、アップグレードが SID に与える影響がきわめて重要なことがわかります。いかなる理由であれアップグレード中に SID が変更された場合は、当然リソース アクセスが影響を受けることになります。

アップグレードの間、セキュリティ プリンシパルは作成元の同じドメイン内に残され、したがってそれらを識別する SID も変更されずに残ります。その結果、アップグレードによってリソース アクセスが影響を受けることはありません。

アップグレードが信頼に与える影響

mignt01

図 1: HAYBUV.TLD ドメインの例

DCPROMO は Kerberos ソフトウェアのインストールも行います。インストールが完了すると、認証サービスとチケット保証サービスが開始します。管理者が既存のツリーへの連結を選択した場合は、双方向の推移的な Kerberos 信頼関係が親ドメインに確立されます。PDC のアップグレード前に作成された信頼関係もすべて残されていますが、それらは明示的な一方向の Windows NT スタイルの信頼の形式をとります。

最終的には、親ドメインの DC が自分のすべてのスキーマ情報と設定情報を新しい子ドメインにコピーします。これらの情報が複製されれば、アップグレードされたドメインは Active Directory ドメイン ツリーのメンバとして完全な機能を持つようになります。ただし、管理者が Windows 2000 ネイティブ モードへの切り替えを決定するまでドメインは混在モードのままです。

この時点で、Windows 2000 Professional または Active Directory クライアント ソフトウェアが動作している Windows 95 および Windows 98 など、Active Directory に対応しているクライアントは、グローバル カタログを照会してリソースや人物を検索するなどの動作を実行するのに、Active Directory を利用できるようになります。またクライアントでは、フォレスト内に存在する推移的な信頼関係を使用してフォレスト全体のリソースにアクセスできるようになります。これらの動作を可能にするための処理手順は、クライアントで Windows 2000 が動作しているか、または Windows NT や Windows 95 および Windows 98 など Windows 2000 以前のオペレーティング システムが動作しているかによって異なり、対象となるドメインのアップグレード状態によっても異なります。

次の場所に常駐しているフォレスト全体のリソースに、推移的な信頼を通じてアクセスできるようになります。

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

  • すべての DC のアップグレードが完了している混在モードのドメイン

  • Kerberos または NTLM の認証要求を処理する DC のアップグレードが完了している混在モードのドメイン

上記以外の場合には、クライアントからは既存の Windows NT スタイルの明示的な一方向の信頼を通じて利用できるリソースにしかアクセスできません。これらのリソースは、アップグレード後も変更されずにそのままにされています。

ここで話を具体的にするために、NTLM 認証および Kerberos 認証がどのように行われるかを示すいくつかの例を紹介します。前出の図 1 にこのシナリオを示します。

NTLM 認証の使用
ここでは、ユーザーが haybuv-acct.haybuv.tld というドメインにログオンすることを考えます。このドメインは混在モード ドメインで、ユーザーは同じドメイン内の ntws という Windows NT Workstation からログオンします。次に、ユーザーは nts という Windows NT Server コンピュータへのネットワーク接続を試みます。このコンピュータは、ネイティブ モードの Windows 2000 ドメインである haybuv-other.haybuv.tld というドメイン内にあります。ntws は Windows NT クライアントなので、NTLM プロトコルを使用します。

nts は、資格情報で指定されて渡されたドメイン名が haybuv-acct.haybuv.tld であると判断し、自分自身のアカウント データベースを参照しません。このため、nts は自分自身のドメイン内の DC にログオン要求を送って認証を行います。DC はドメイン名を調べますが、DC 自身のドメイン名と一致しないため、ドメインが信頼されるドメインかどうかを確かめます。haybuv-acct.haybuv.tld および haybuv-other.haybuv.tld はどちらも同じ haybuv.tld というルートの子ドメインなので、両方のドメインの間に推移的な信頼が存在します。したがって、DC は信頼されるドメイン内の DC にログオン要求を渡します。ログオン要求が渡された DC は、ユーザー名とパスワードが自分のドメイン アカウント データベースにあることを認証します。両方のドメインの資格情報が互いに一致すれば、アカウント ID 情報が問い合わせ元の DC に返され、DC からさらにサーバーに返されます。

次に、サーバーはユーザーの偽装トークンを作成します。このトークンにはユーザーの SID と、ユーザーがメンバとなっているすべてのドメイン グループの SID が含まれています。さらにサーバーはユーザーのセキュリティ コンテキスト内に偽装スレッドを作成し、偽装トークンを送信して、ユーザーの代わりにリソースへのアクセスを試みます。

以上の説明から、対象となるドメイン内の DC で Windows 2000 が動作していれば推移的な信頼が認識されることがわかります。したがって、混在モード ドメイン内の下位レベル クライアントから NTLM を使用してツリー内の別のドメイン内の下位レベル サーバーにアクセスできます。同じフォレスト内のツリーはすべて推移的な信頼で連結されているため、2 つのドメインが異なるツリー内にあっても同じようにアクセスできます。

さらに、混在モードのドメイン haybuv-res1.haybuv-other.haybuv.tld 内にある Windows NT Server コンピュータ nts 上のリソースにアクセスしようとした場合には、サーバーからログオン要求が渡された DC で Windows 2000 が動作している限り、フォレスト全体で推移的な信頼を使用してリソースにアクセスできます。

Kerberos 認証の使用
ここでも、先の例と同じくユーザーが haybuv-acct.haybuv.tld というドメインにログオンしますが、今度は同じドメイン内にあり Windows 2000 が動作している w2kpro というコンピュータからログオンすることを考えます。ユーザーは、haybuv-other.haybuv.tld ドメイン内にある w2ksrv という Windows 2000 Server コンピュータにネットワーク接続しようとしています。w2kpro は Windows 2000 クライアントなので Kerberos プロトコルの使用を試みます。

Kerberos はチケットをベースとしたプロトコルです。ユーザーが初めてドメインにログオンすると、Windows 2000 DC 上で動作しているキー配布センター (KDC) 上のチケット保証サービスから、チケット保証チケット (TGT) と呼ばれるものがユーザーに発行されます。TGT にはユーザーの認証情報がドメインのマスタ キーによって暗号化されて収められています。この情報はドメイン内のほかのサーバーに接続する際に、さらにセッション チケットを要求するための情報の一部として、再び DC に送り返すことができます。ユーザーに TGT が許可されると、DC の確認処理は TGT の復号化とユーザーの資格情報の確認だけになるため、それ以降の処理は高速で効率良く行われます。セッション チケットは TGT に似たものですが、サーバーと DC 間で共有しているキーを使用して暗号化されています。

Kerberos プロトコルも、NTLM と同様にドメイン境界を超えた操作が可能です。あるドメイン内のクライアントと別のドメイン内のサーバーとの間で、これら 2 つのドメイン間で信頼関係が確立されていれば、クライアントをサーバーに認証させることができます。ドメイン間で信頼が確立されると、両者の間でインタードメイン キーが交換されます。一方のドメインの認証サービスはこのインタードメイン キーを使用してチケットを暗号化し、もう一方のドメインのチケット保証サービスに送ります。

クライアントからリモート ドメイン内のサーバーにアクセスしようとするとき、クライアントは自身のドメイン内の DC に対して参照チケットを要求します。このチケットは、リモート ドメインの DC で動作しているチケット保証サービスに対してクライアントから提示できる TGT です。この要求に対して、ローカルの DC はリモートの DC のインタードメイン キーで暗号化された TGT をクライアントに送ることで応答します。

クライアントは、リモート DC のチケット保証サービスにこの紹介 TGT を提示し、リモート DC のドメイン内にあるサーバーへのチケットを要求します。リモート DC はクライアントの TGT を自身のインタードメイン キーを使用して復号化します。復号化に成功すれば、リモート DC はこの TGT が信頼される機関から発行されたものであると判断し、要求されたサーバーへのチケットをクライアントに許可します。

図 1 では、haybuv-acct.haybuv.tld と haybuv-other.haybuv.tld はどちらも同じルートの子ドメインであるため、2 つのドメイン間には推移的な信頼が存在し、ドメイン間で信頼パスを構築できます。紹介 TGT を受け取ると、送り先のドメイン内の DC は、ただちにその TGT が問題のサーバーの共有キーを持っているかどうかを確かめ、持っている場合はセッション チケットをクライアントに発行します。w2ksrv は Windows 2000 コンピュータなので共有キーが存在し、チケットを w2kpro に発行できます。

以上の説明から、Kerberos チケット保証サービスが動作している DC が対象ドメイン内に存在すること、そして、DC とサーバーとの間で共有キーが存在することが、この場合の重要な要素になることがわかります。Windows 2000 DC には、Active Directory のインストール処理の中で Kerberos サービスがインストールされます。そして、メンバ サーバーを Windows 2000 ドメインに追加することで必ず共有キーが作成されます。したがって、セッション チケットの発行が利用できる Windows 2000 DC が存在する限り、w2kpro から Kerberos を使用して w2ksrv.haybuv-res1.haybuv-other.haybuv.tld にアクセスできることになります。

w2kpro から nts.haybuv-res1.haybuv-other.haybuv.tld などの Windows NT コンピュータ上のリソースにアクセスしようとした場合には Kerberos 認証は失敗し、クライアントはフォールバックの後、前述の NTLM 認証を試みます。

アップグレードとリソース ドメイン
リソース ドメインは、サーバーやワークステーションなどのリソースのアカウントを保持するように作成された特殊なドメインです。従来、リソース ドメインは Windows NT において、次に示す 2 つの状況に対処するために作成されていました。

  • SAM のサイズ制限 Windows NT では、SAM アカウント データベースの推奨最大サイズが 40 MB に制限されています。ワークステーションやサーバーを多数展開し、多数のセキュリティ グループを実装している組織では、この制限のためにアカウントの数がしばしば想定されている 40,000 個よりもずっと少ない数しか確保できないことがあります。この数を超える組織の場合には、ユーザー アカウントとコンピュータ アカウントとを別々のドメインに分けて格納することをお勧めします。前者のドメインは "アカウントドメイン" または "マスタドメイン" と呼ばれ、後者は "リソースドメイン" と呼ばれます。

    通常、作成されたリソース ドメインは第二層のドメインとみなされます。このドメインは一方向の信頼 (信頼関係) を持ち、単一のアカウント ドメインへの信頼か、または複数のアカウント ドメインへの信頼のどちらかを持ちます。前者は "マスタドメインモデル"、後者は "マルチマスタドメインモデル" と呼ばれます。

  • ローカルな管理能力の提供 施設が地理的に点在している分散型の組織では、当該地域の担当者にリソースの管理権限を与えて管理を委任したほうが望ましいことがあります。Windows NT でこのような責任の分担を実現するには、組織独自の管理構造を持ったリソース ドメインを作成することをお勧めします。前述の例と同じように、この場合も組織内にあるアカウント ドメインへの一方向の信頼を持つ、マスタ ドメイン構造またはマルチマスタ ドメイン構造となります。

    これらの信頼はその性質上一方向であるため、既定では、リソース ドメインの管理者はリソース ドメイン上の管理スコープだけを持つことが保証されます。

アップグレードがリソース ドメインに与える影響について検討するときに考慮しなければならないことは、上の 2 つの状況のうち、設計者がドメイン構造を決める際にどちらを主として念頭においたのか、ということです。後者の状況に対処するためにドメインが作成されている場合は、リソース ドメインが管理モデル上で暗黙裡にアップグレードされることも検討できます。これは、リソース ドメインをアップグレードしてフォレストに連結するだけで、子のリソース ドメインと親ドメインとの間で双方向の推移的な信頼が作成されるためです。

当該地域の管理者がまだ技術的に不慣れな場合、あるいは Windows 2000 フォレスト内の管理権限を管理者に許可する予定がない場合には、次に示す選択肢を検討することになります。

  • Windows 2000 委任機能を使用したフォレスト内部でのドメインのアップグレード リソース ドメイン内の管理グループを調べ、マスタ ドメインの管理者でない人を削除します。当該地域のリソース ドメイン管理者しかいない場合は、1 人または複数のマスタ ドメイン管理者を追加します。マスタ ドメイン管理者は、ドメインのアップグレード中もドメインを管理できます。さらに注意すべき点として、リソース ドメインの管理者がローカル コンピュータのアカウントを通じて DC に管理アクセスすることのないようにします。

    PDC のアップグレードが完了したら、リソース管理者を保持するための新しいドメイン ローカル グループを作成し、管理グループから削除したユーザーをそこに追加します。管理グループを変更したユーザーも同様に追加します。
    PDC のアップグレードが完了したら、Windows 2000 の委任管理機能を使用して、新しく作成したリソース管理者のグループに適切な認可を与えます。

  • 新しいフォレスト内でのドメインのアップグレード リソース ドメインを新しいフォレスト内の新しいツリーとしてアップグレードし、アカウント ドメインへの明示的な信頼 (既に存在する) を経由してアカウント ドメインへのリンクを維持することもできます。この信頼は、Windows NT の明示的な信頼と同じように一方向の信頼であり、推移的な信頼ではありません。これによりアップグレード前の構造が効果的にミラー化されます。

  • OU への再構築 さらに別の手段として、ドメイン構造を再検討し、後でリソース ドメインをアップグレードしたマスタ ドメインに OU として併合する方法もあります。この方法を選択する場合は、ドメインのアップグレードの順序を考える上で明らかに影響を受けることになります。

アップグレードと管理
PDC を Windows 2000 Server にアップグレードして Active Directory をインストールすると、管理者は Windows 2000 Server に付属の新しいツールを使用して、Active Directory にしかない組織単位 (OU) などの新しいオブジェクトを作成できるようになります。

OU を作成すると、その中にオブジェクトを配置してドメインを組織化できるようになります。この構造は、Active Directory クライアント ソフトウェアを持つコンピュータだけに表示されます。Active Directory クライアント ソフトウェアのないコンピュータでは OU は表示されず、ドメインはそのままの状態です。PDC は従来と同じようにオブジェクトをフラット ストアとして下位レベルのクライアントに公開します。

Active Directory のないクライアントで作業する管理者は、従来の古い管理ツールしか使用できません。

混在モードとネイティブ モード

mignt02

図 2: アップグレードの各段階

混在モード
PDC をアップグレードした瞬間から管理者がドメインの Windows 2000 ネイティブ モードへの切り替えを決定するまで、ドメインは混在モードにおかれます。混在モードでは、以前のバージョンのオペレーティング システムとの下位互換性が最大限に保たれます。混在モードはドメインの認証インフラ、つまりドメイン コントローラにのみ関連するモードであることに注意する必要があります。ドメイン内に Windows 2000 DC しかなく、ドメインがネイティブ モードに切り替わったとしても、以前のバージョンの Windows NT が動作するクライアントとサーバー、および Windows 95 および Windows 98 が動作するクライアントはそのドメイン内で動作できます。このような環境のことを "混在環境" と呼びます。

混在モードのドメインは、ドメイン内で PDC だけでなくすべての BDC のアップグレードを完了した後であっても、そのまま永続的に運用できます。

この後の表 3 では、混在モードで利用できる Windows 2000 の機能と、ネイティブ モードへの切り替え後にだけ利用できる Windows 2000 の機能をまとめて説明しています。ネイティブ モードへの切り替えの判断がつかない場合は、混在モードのままで妥協すべきかどうか、および、トレードオフを受け入れられるかどうかについて、移行目的をもとに判断してください。

一般には、次のような理由がある場合に限り、混在モードのままにします。

  • BDC をアップグレードできない。 このシナリオでは、何らかの理由でアップグレード、またはメンバ サーバーに降格できない BDC が存在します。BDC 上で実行しなければならないアプリケーションがあり、何らかの理由でそのアプリケーションが Windows 2000 上で実行されない場合もこれに当てはまります。

  • BDC の物理的なセキュリティが不適切である。 どのようなドメイン計画を立てる場合でも、セキュリティは重要な検討事項です。セキュリティの基本的な要素として、コンピュータ自身の物理的なセキュリティがあります。物理的なアクセスが簡単にできるコンピュータは攻撃に対し無防備です。このシナリオでは、PDC 単体で SAM のシングルマスタ アップグレードを行うか、あるいはすべての DC でアカウント データベースの Active Directory マルチマスタ アップグレードを行うかについて、その違いを検討することができます。

    Windows NT のディレクトリ更新はその性質上シングルマスタであるため、BDC に対しては比較的緩やかなセキュリティを持たせたほうが好都合なこともあります。このような場合には BDC を Windows 2000 DC にアップグレードするときに再考が必要です。BDC のセキュリティを適切にアップグレードできない場合は、アップグレード時に BDC をメンバ サーバーに降格して新しい Windows 2000 DC を別の場所に追加することが考えられます。あるいは、対象となるドメイン構造を再構築する方法も可能です。

  • Windows NT へのフォールバックが依然として必要である。 既に触れたように、混在モードの機能の 1 つに下位互換性があります。混在モードには、問題が発生した場合に新しい Windows NT BDC をドメインに追加できるという利点があります。このような状況では、BDC をドメインに連結すれば、アカウント データベースを強制的に再同期化させることができます。その後、ドメイン内に Windows 2000 DC が存在しない限り、BDC を PDC に昇格できます。フォールバックや回復に備えた計画も必要ですが、場合によっては新しい環境に完全に切り替えなければならないこともあります。

ネイティブ モード
すべての DC のアップグレードが完了すると、ドメインを混在モードからネイティブ モードに切り替えることができます。切り替え中は次の動作が実行されます。

  • ドメインは DC 間で Active Directory マルチマスタ複製しか使用しません。したがって、Netlogon 複製のサポートは終了します。

  • Netlogon 複製はオフにされるため、新しい Windows NT BDC をドメインに追加することはできなくなります。

  • マルチマスタ複製が有効になるため、以前の PDC はドメインのマスタではなくなり、すべての DC がディレクトリ更新を実行できるようになります。PDC エミュレータとしての役割は引き続き存在しますが、このことはしばしば混乱の原因となります。Active Directory はその性質上マルチマスタですが、Windows 2000 はフレキシブル シングルマスタ オペレーション (FSMO) として指定された多数の役割を持ち、PDC エミュレータも FSMO 役割の 1 つです。通常は、以前の PDC は PDC エミュレータ FSMO ホルダとして存続します。つまり、ネイティブ モードの環境では、パスワードの変更がほかの DC によって優先的にこのホルダに複製されることになります。

  • ユニバーサル グループやドメイン ローカル グループなどの Windows 2000 固有のグループ種別、およびグループの入れ子が可能になります。

このようなネイティブ モードへの切り替えは DCPROMO の実行によって自動的に実行されることはなく、管理者が管理インターフェイスを通じて変更の契機を与える必要があります。

アップグレードした PDC や BDC を混在モードのまま使用しても多くの利点がありますが、混在モードではユニバーサル グループやグループの入れ子など一部の便利な機能が利用できません。

ネイティブ モードへの切り替えはできるだけ速やかに行ってください。

ネイティブ モードへの切り替え
ドメイン モードを混在からネイティブに切り替えることは簡単ですが、元に戻すことは不可能です。したがって、モードの変更はこれまで説明してきた事柄について十分検討した上で行ってください。Windows NT DC を現在持っている、あるいは将来持つ予定がある場合には、ドメイン モードを変更しないでください。

ドメイン モードを切り替えるには

  1. Active Directory ドメインと信頼関係のスナップインを開き、左側のツリー ビュー ペイン内で操作対象のドメインを右クリックします。

  2. コンテキスト メニューが表示されます。[プロパティ] をクリックし、図 3 のタブ付きダイアログ ボックスを開きます。

  3. [ 全般 ] タブで [モードの変更] をクリックします。

    mignt03

    図 3: ドメイン モードの変更ダイアログ

 

表 3 混在モードで利用できる Windows 2000 の機能

目的

機能

混在モードで利用できるか

管理能力の強化

Kerberos 推移的な信頼

利用できます。ただし、前述の「アップグレードが信頼に与える影響」を参照してください。

管理能力の強化

Active Directory

利用できます。

管理能力の強化

Active Directory 組織単位 (OU)

利用できます。ただし、Windows 2000 の管理ツールでなければアクセスできません。Windows NT BDC やメンバ サーバーからは管理できません。

管理能力の強化

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

利用できません。グローバル グループとローカル グループしか利用できません。

管理能力の強化

Windows インストーラ

利用できます。

スケーラビリティの強化

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

利用できます。

スケーラビリティの強化

Active Directory のスケーラビリティ

利用できます。ただし、すべての BDC のアップグレードを完了して Active Directory を実行した後に限ります。ドメインが混在モードの間も新しい Windows NT BDC を追加できるので、この機能を利用する際は十分な注意が必要です。この機能はフォールバック計画において重要な部分を占めることがあり、特別な理由がない限り導入すべき機能です。

スケーラビリティの強化

Kerberos 認証

Windows 2000 コンピュータで利用できます。

スケーラビリティの強化

Microsoft 管理コンソール (MMC)

利用できます。

セキュリティの強化

グループ ポリシー

ドメイン内の DC またはほかの Windows 2000 コンピュータで利用できます。

セキュリティの強化

セキュリティ構成マネージャ (SCM)

利用できます。

セキュリティの強化

Active Directory マルチマスタ複製

アップグレードを完了した

 

Windows 2000 のグループ

前節では、Windows 2000 におけるセキュリティ グループの豊富な新機能について説明しました。

Windows 2000 は、次に示す 4 種類のセキュリティ グループをサポートしています。

  • ローカル

  • ドメイン ローカル

  • グローバル

  • ユニバーサル

ローカル グループ
ローカル グループは Windows NT 内に必ず存在します。メンバシップの点から見ると、フォレスト内から、または信頼されるほかのフォレスト内から、あるいは信頼される下位レベルのドメイン内から、メンバを持つことができます。ただし、リソース権限の点から見ると、ローカル グループはマシン全体のスコープしか持っていません。このため、ローカル グループのあるコンピュータに関する権限を許可するためにだけ使用できます。

ローカル グループの特殊な場合として、以前のバージョンの Windows NT の PDC 上で作成されたローカル グループがあります。このローカル グループは BDC の間でドメイン SAM が複製されるおかげで、従来は PDC と BDC の間で共有されていました。混在モードではローカル グループは Windows NT 上でも Windows 2000 上でも同じものとして扱われますが、ネイティブ モードでは DC 上のローカル グループはドメイン ローカル グループになります。ドメイン ローカル グループについては次の節で説明します。

特に、ローカル グループはローカル コンピュータ上のリソースへの一時的なアクセス権を許可するために使用します。

ドメイン ローカル グループ
ドメイン ローカル グループは Windows 2000 の新機能ですが、その概念や使用方法は上で説明したように Windows NT 4.0 ドメイン内の PDC 上で作成されたローカル グループに似ています。

ドメイン ローカル グループはネイティブ モードのドメイン内だけで利用できます。メンバシップの点から見ると、フォレスト内から、または信頼されるほかのフォレスト内から、あるいは信頼される下位レベルのドメイン内から、メンバを持つことができます。リソース権限の点から見ると、ドメイン ローカル グループはドメイン全体のスコープしか持っていません。このため、ドメイン ローカル グループのあるドメインの中で権限を許可するためにだけ使用できます。ローカル グループと異なる点は、ドメイン ローカル グループはそれを作成したドメインの内部にあるすべてのコンピュータで使用できることです。

特に、ドメイン ローカル グループは、フォレスト全体からセキュリティ プリンシパルを収集してドメイン内のリソースへのアクセスを制御するために使用します。

グローバル グループ
Windows 2000 のグローバル グループには Windows NT のグローバル グループと同じ効力があります。メンバシップの点から見ると、グローバル グループにはドメイン全体のスコープがありますが、グローバル グループには任意のドメイン内で権限を許可できます。また、信頼関係が存在する限り、ほかのフォレストや下位レベルのドメイン内でもアクセス権を認められます。

ユニバーサル グループ
ユニバーサル グループにはフォレスト全体のスコープがあります。つまり、フォレスト内の任意の Windows 2000 ドメインにあるメンバを収納できます。ユニバーサル グループには任意のドメイン内で権限を許可でき、信頼関係が存在する限りほかのフォレスト内でも権限を許可できます。

ユニバーサル グループには、同じフォレスト内にある混在モードのドメインのメンバを持たせることができますが、そのようなドメインのメンバのアクセス トークンにはユニバーサル グループは追加されません。これは、ユニバーサル グループが混在モードで利用できないためです。

ユニバーサル グループにはユーザーを追加できますが、メンバシップをグローバル グループに制限することをお勧めします。

ユニバーサル グループはネイティブ モードのドメイン内だけでしか利用できません。

ユニバーサル グループの使用
ユニバーサル グループにはいくつかの重要な用途があります。ユニバーサル グループを使用すると、企業内部で共通の機能を実行する仮想チームのようなグループを構築できます。大規模な企業では、このような仮想チームのメンバが全国規模あるいは世界規模にもなることがあり、ほとんどフォレスト全体のものになると考えられ、チームのリソースも同様の規模で分散しています。このような場合に、個々の支店や部門のグローバル グループを収納するコンテナとしてユニバーサル グループを使用でき、チームのリソースをユニバーサル グループのアクセス制御エントリ (ACE) によって保護することができます。

ユニバーサル グループを使用する上で重要なことは、グローバル グループおよびドメイン ローカル グループはグローバル カタログ (GC) に列挙されますが、それらのメンバは示されず、これに対してユニバーサル グループの場合はそのメンバもともに示されることです。このことは GC の複製トラフィックが発生することを暗に示しており、ユニバーサル グループを使用する際は注意が必要です。ネットワーク全体が高速回線で接続されていれば、すべてのグループで問題なくユニバーサル グループを使用でき、グローバル グループやドメイン ローカル グループの管理に悩まされることもなく、その恩恵を享受できます。しかし、ネットワークがワイド エリア ネットワーク (WAN) に及ぶ場合には、グローバル グループやドメイン ローカル グループを使用するなどの方法でパフォーマンスを改善できます。

グローバル グループやドメイン ローカル グループを使用する場合は、それらをユニバーサル グループとして変更することのほとんどない、広範囲に使用するグループとして指定することもできます。

ユニバーサル グループとアクセス トークン
ユニバーサル グループのメンバシップの説明でも触れましたが、ユニバーサル グループには混在モードのドメインのメンバを収納できますが、そのようなメンバのアクセス トークンにはユニバーサル グループの SID がありません。これは、Windows 2000 におけるアクセス トークンの生成方法によるものです。

ユーザーが Windows 2000 のネイティブ モードのドメインにログオンしてその認証が完了すると、ユーザーを認証した DC 上のローカル セキュリティ機関 (LSA) は、そのユーザーのグローバル グループのメンバシップを受け取ります。LSA は受け取った情報をさらに下位のワークステーションに渡し、ワークステーションではこれを使用してユーザーのアクセス トークンを作成します。同時に、LSA は GC に対してユーザーのユニバーサル グループのメンバシップを問い合わせ、それもワークステーションに渡します。

ユーザーがユニバーサル グループのメンバであれば、そのグループの SID がワークステーション上のアクセス トークンに含まれ、KDC から発行された TGT 内の認証データに追加されます。

これ以外のいかなる場合、たとえば偽装トークンがメンバ サーバーで作成されるときなどに、ユニバーサル グループがアクセス トークンに追加されることはありません。その結果、たとえばユーザーが混在モードのドメインにログオンした場合など、ユーザーのログオン時にユニバーサル グループの SID が利用できない場合には、それ以降も追加されることはありません。

グループの入れ子
5,000 を超えるメンバを持つグループの作成は避けてください。この理由は、Active Directory ストアへの更新を 1 つのトランザクションの中で実行できるようにする必要があり、その保証値を 5,000 と定めているためです。グループ メンバシップは多数の値を持つ 1 個の属性に格納されるため、メンバシップが変わると属性全体に影響を及ぼすことになります。つまり、メンバシップ リスト全体を 1 つのトランザクションの中で更新しなければなりません。Microsoft では最大 5,000 のメンバのグループ メンバシップについて試験を行っており、その動作を保証しています。

グループを入れ子にしてメンバの実効数を増やせば、この制限を回避できるだけでなく、グループ メンバシップの変更に伴う複製によって発生する複製トラフィックを軽減することにもなります。

入れ子にするかどうかは、ドメインがネイティブ モードか混在モードかによって決まります。次の一覧は、ネイティブ モードのドメイン内にあるグループに何を収納できるのかについて示したものです。これらの規則はグループのスコープによって決まります。

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

  • グローバルグループには、同じドメインからのユーザー アカウントと、同じドメインからのほかのグローバルグループを収納できます。

  • ドメイン ローカル グループには、ユーザー アカウント、ユニバーサル グループ、および任意ドメインからのグローバル グループを収納できます。同じドメイン内部からのほかのドメイン ローカル グループも収納できます。

混在モードのドメイン内のセキュリティ グループには次のものだけを収納できます。

  • ローカル グループには、信頼されるドメインからのグローバル グループとユーザー アカウントを収納できます。

  • グローバル グループにはユーザー アカウントだけを収納できます。

アップグレードがグループに与える影響
PDC を Windows 2000 にアップグレードしてもその影響が直ちにグループに及ぶことはありません。Windows NT ローカル グループは Windows 2000 ローカル グループになり、Windows NT グローバル グループは Windows 2000 グローバル グループになります。実際の変更はドメインがネイティブ モードに切り替わったときに起こり、その時点で PDC 上のローカル グループはドメイン ローカル グループになります。

先に説明したように、ユーザーの認証が完了するとユーザーのアクセス トークンが作成されます。アクセス トークンには、ユーザーのプライマリ SID と、ユーザーが属するすべてのグループの SID が含まれています。PDC 上のローカル グループは Windows NT における特殊な場合であることは既に触れましたが、この事実は、このようなグループのメンバであるユーザーのアクセス トークンがどのように作成されるのかに影響を与えます。対話型ログオンの後でユーザーのワークステーション上に作成される場合、PDC のローカル グループはドメインの PDC や BDC を超えるスコープを持っていないため、ワークステーション上のユーザーのアクセス トークンにはそのグループの SID は含まれません。しかし、リソースへのアクセス権を許可するためにユーザーを偽装する目的で DC に作成される場合には、ユーザーが DC 上のリソースにアクセスしようとするときにそのユーザー用の偽装トークンが DC で作成され、それにはユーザーがメンバとなっているすべての PDC ローカル グループの SID が含まれます。

ドメインがネイティブ モードに切り替わると、ドメイン ローカル グループはドメイン全体のスコープを持ちます。このため、ユーザーがワークステーションで対話型ログオンをしようとする場合でも、ユーザーがメンバとなっている任意のドメイン ローカル グループの SID が、ユーザーのアクセス トークンに追加されます。

表 4 グループとドメイン モード

グループ種別

メンバシップ

スコープ

混在モードで利用できるか

ローカル
  • 同じフォレストからのメンバ
  • ほかの信頼されるフォレストからのメンバ
  • 信頼される下位レベルのドメインからのメンバ

マシン全体

利用できます。

グローバル

ローカル ドメインからのメンバ

任意の信頼されるドメイン

利用できます。

ドメイン ローカル
  • 同じフォレストからのメンバ
  • ほかの信頼されるフォレストからのメンバ
  • 信頼される下位レベルのドメインからのメンバ

ローカルドメイン

利用できません。

ユニバーサル

同じフォレストからのメンバ

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

利用できません。

 

Windows 2000 における NetBIOS と WINS (Windows Int ernet Name Service)
NetBIOS は、1980 年代後半以降 Microsoft のネットワーク コンポーネントとして使用されている、高度なネットワーク プログラミング インターフェイスです。ネットワーク リソースは、一意な NetBIOS 名によって NetBIOS ネームスペースの中で識別されます。WINS は Windows NT Server の一部として提供されているサービスで、NetBIOS 名から IP アドレスへの動的マッピングの登録機能をサポートしており、NetBIOS の名前解決機能を提供します。

Windows 2000 のリリースにより、ネットワーク作業を行うコンピュータで NetBIOS ネーミング インターフェイスをサポートする必要はなくなりました。また、これに関連して、Active Directory と DNS (ドメイン ネーム システム) との密接な連携によって、NetBIOS は次第に使用されなくなる傾向にあります。その一方で、ドメインを Windows 2000 にアップグレードする際は、ネットワーク上で NetBIOS をサポートしなくてもよいというわけではなく、現在のサポート状況にも影響を与えます。

次の条件を満たす場合には、アップグレード後に NetBIOS と WINS の使用の取り止めを検討できます。

  • Windows for Workgroups、Windows 95 および Windows 98、または Windows NT 4.0 などのクライアントがなく、NetBIOS を使用する Windows NT 4.0 サーバーもないこと。以前のバージョンの Windows オペレーティング システムが動作しているクライアント コンピュータでは、基本的なファイルおよび印刷サービスを提供するため、および従来から使用している多数のアプリケーションをサポートするために、ネットワーク上に引き続き NetBIOS 名が必要な場合があります。

    従来のアプリケーションやサービスに与える影響について確認する作業を、テスト計画の中に盛り込むようにします。

  • Windows 2000 だけの純粋なネットワークを構築し、DNS などのほかのネーミング サービスがネットワーク上のすべてのコンピュータやアプリケーションで確実に機能できること。NetBIOS 名を必要としない場合であっても、ネットワーク全体でコンピュータやリソースの場所を特定するためにネットワーク ネーミング サービスは非常に重要です。

Windows 2000 の WINS クライアントは、解決された名前をローカルにキャッシュし、DNS にクエリを送信する前に、キャッシング リゾルバと呼ばれるコンポーネントを使用してこのキャッシュを参照します。ホスト ファイルはクライアントの起動と同時にキャッシュされ、ホスト ファイルへの変更内容はただちにキャッシュに反映されます。名前は次の順序で解決されます。

  1. クライアント キャッシュからの名前の解決を試みます。

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

  3. DNS による名前の解決に失敗した場合、クライアントは WINS による名前の解決を試みます。

したがって、アップグレードの完了によって新しいクライアントに対する十分な制御変更を実行し、従来の環境に依存する条件をすべて取り除けば、NetBIOS から WINS への切り替えが問題なく円滑に行われます。

LAN Manager Replication (LMRepl) サービスの可用性
Windows NT Server では、LAN Manager Replication (LMRepl) と呼ばれる複製機能が提供されていました。LMRepl は、ドメイン内のエクスポート中の DC からインポート中の複数の DC にログオン スクリプトを複製する際にしばしば使用します。Windows 2000 Server ではこのサービスに代わって、ファイル複製サービス (FRS) が提供されています。

Windows 2000 Server は、混在モードやネイティブ モードで LMRepl をサポートしていません。このため、以前に LMRepl を使用したことがある場合には、FRS を使用して同じ機能を提供するための方針をアップグレード計画の中に盛り込む必要があります。

LMRepl の処理
LMRepl は、インポート ディレクトリとエクスポート ディレクトリの概念を使用しています。管理者は、エクスポート ディレクトリのホストとなる 1 つのサーバーとインポート ディレクトリのホストとなる複数のサーバーを選択することで、LMRepl を設定できます。ディレクトリのホストとなるサーバーは必ずしも DC である必要はなく、通常のメンバ サーバーもホストにできます。

mignt04

図 4: LMRepl の処理

FRS の処理
Windows 2000 Server の FRS (ファイル複製サービス) は、複製されたシステム ボリューム (SYSVOL) をすべてのドメイン コントローラが持つように、自動的に設定されます。あるドメイン コントローラの SYSVOL に格納されているログオン スクリプトを変更すると、その変更内容はマルチマスタの方式でほかのドメイン コントローラにも複製されます。LMRepl におけるインポートまたはエクスポートの各ディレクトリのホストとは異なり、FRS ではドメイン コントローラだけが SYSVOL のホストとなることができます。

mignt05

図 5: FRS の処理

混在環境での LMRepl サービスの維持
先に説明したように、アップグレードの間、Windows NT 4.0 BDC と Windows 2000 ドメイン コントローラが稼働しているサーバーとが混在する環境になることがあります。Windows 2000 Server は LMRepl をサポートしていないため、混在環境で LMRepl サービスを維持することが問題となる場合があります。このサービスを提供するためには、LMRepl と FRS 間でブリッジを作成し、両方のサービスとも利用できるようにする必要があります。これには、Windows 2000 DC のうち、その SYSVOL を使用して LMRepl のホストである Windows NT BDC のエクスポート ディレクトリを設定しようとする Windows 2000 DC を選択します。必要なファイルのコピーを定期的に実行するようにスケジューリングできるサンプル スクリプトが Microsoft から利用できます。

LMRepl とアップグレード
アップグレード中も LMRepl の可用性を維持するためには、必ずインポート ディレクトリのホストとなっている複数のサーバーのアップグレードがすべて完了してから、エクスポート ディレクトリのホストとなっているサーバーをアップグレードしてください。エクスポート ディレクトリのホストとなっているサーバーが PDC の場合は、新しいエクスポート サーバーを選択して LMRepl を再設定してください。

混在環境でのリモート アクセス サービス (RAS) の使用
RAS を利用して企業ネットワークへのリモート アクセスをユーザーに提供している場合は、あらかじめメンバ サーバーのアップグレードの過程で RAS のアップグレードを検討することもできます。この理由は、Windows NT が RAS アクセスの可用性やユーザーのダイヤルバックなどの RAS プロパティを確認するためです。

RAS は Windows NT の "サービス" の一例です。サービスはバックグラウンド プロセスの一種で、ユーザー インターフェイスを持っておらず、連続して実行するように設計されています。通常、サービスは Web サーバーや FTP サーバーなどのサーバー機能の一部を実行します。サービスはシステムに誰もログオンしていないときでも実行する必要があるため、通常はシステム アカウントという特殊なサービス アカウントのセキュリティ コンテキスト内で実行されます。システム アカウントは "LocalSystem" とも呼ばれます。

システム アカウントはローカル コンピュータにしか分からない特殊なアカウントであり、オペレーティング システムに関して利用できるすべての権限が許可されています。サービスは、LocalSystem としてログオンするときに NULL の資格情報でログオンし、ユーザー名やパスワードは提示しません。したがって、リモート コンピュータで NULL の資格情報によるアクセス (NULL セッションとも呼ばれます) を許可している場合を除いて、NTLM 認証に依存しているネットワーク リソースに対してこのアカウントを使用してアクセスすることはできません。Windows NT では、RAS がこの LocalSystem アカウントを使用しています。

既定では、Active Directory は NULL セッションを介したオブジェクト属性の問い合わせを受け付けません。したがって、混在環境では次の条件が満たされない限り、Windows NT RAS サーバーでユーザーの RAS プロパティを取得することはできません。

  • ドメインが混在モードであり、Windows NT RAS サーバーもまた BDC であること。この場合 RAS からは SAM にローカル アクセスできます。

  • ドメインが混在モードであり、Windows NT RAS サーバーが Windows NT BDC と連携していること。結果として現在の Windows NT とまったく同じ動作をすることになりますが、場合によっては何らかの動作上の矛盾が生じることもあります。

  • ドメインが混在モードまたはネイティブ モードであり、Active Directory のセキュリティが緩和されていて、任意のユーザー オブジェクトの任意のプロパティを読み取る組み込みの個人用 "Everyone" 権限が既に許可されていること。Active Directory のインストール ウィザード (DCPROMO) では、特定の Active Directory オブジェクトに対してユーザーが "権限を弱める" オプションを使用することで、この設定を選択できます。

最後の対処法は、必ず Active Directory のセキュリティに対する影響について十分理解した上で実行してください。セキュリティ条件にそぐわないと思われる場合は、推奨される方法を採用してください。つまり、Windows NT RAS サーバーを Windows 2000 にアップグレードし、Windows 2000 の混在ドメインまたはネイティブ ドメインのメンバにします。2 番目の条件でも説明しましたが、ドメインが混在モードの間は動作の矛盾が生じることがありますが、この方法ならばそのような矛盾も回避されます。

アップグレード計画の際は以上の条件を念頭に置き、サーバーのアップグレード過程では RAS サーバーを最初にアップグレードすることを暗黙事項として検討してください。

サポートされているアップグレード パス
Windows 2000 へのアップグレード計画で考慮すべき重要な事柄として、企業内に既に配置されているオペレーティング システムがあり、これらを直接 Windows 2000 にアップグレードできるかどうか、ということが問題になります。

次の表 5 は、Windows 2000 においてサポートされているアップグレード パスの一覧です。アップグレードが必要であるが、直接のアップグレードがサポートされていない場合は、Windows 95 および Windows 98、ワークステーション用 Windows NT 3.51/4.0、またはサーバー用 Windows NT 3.51/4.0 などのほかのオペレーティング システムを経由してアップグレードすることになり、アップグレード計画にそれを反映する必要があります。

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

プラットフォーム

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

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

Windows 3.x

不可

不可

Windows NT 3.1

不可

不可

Windows NT 3.1 Advanced Server

不可

不可

Windows NT 3.51 Workstation

可

不可

Windows NT 3.51 Server

不可

可

Windows 95 および Windows 98

可

不可

Windows NT 4.0 Workstation

可

不可

Windows NT 4.0 Server

不可

可

 

ドメインのアップグレード順序
これまでドメイン内の DC のアップグレード順序について説明してきました。必ず最初に PDC をアップグレードしてから BDC をアップグレードするという点については、ほぼ議論の余地はありません。それよりも、どのドメインを最初にアップグレードすべきか、ということのほうが問題であり、その答えは状況によって異なります。たとえば、ある特定のドメイン群を再構築してなくしてしまおうと計画している場合には、それらを最初にアップグレードしてもほとんど意味はありません。

このように状況はさまざまですが、ドメインをアップグレードする際の一般的な推奨順序として、次の順序を検討してください。

  1. アカウント ドメイン

  2. リソース ドメイン

アカウント ドメインのアップグレード
原則として、まず最初にアカウント ドメインからアップグレードを始めることで最大限の利点を享受できます。これはほとんどの場合、コンピュータの台数よりも管理すべきユーザーの数のほうが多くなるためです。アカウント ドメインを Windows 2000 にアップグレードすることで次のような利点があります。

  • Active Directory のスケーラビリティの強化 多くの組織では、既存のユーザーやグループの数が多いために SAM の推奨上限値が圧迫されています。

  • 管理の委任 管理能力を非常にきめ細かく委任できます。絶対的な権限を許可する必要がありません。

アカウント ドメインの順序

アカウント ドメインが複数ある場合は、次のガイドラインを参考にしてアップグレードの順序を決めてください。

  • 制御の維持 既にラボやパイロットなどでアップグレード方針のテストを完了しているとしても、初めて行う実際の移行作業は最も危険性が高いものです。リスクを抑えるため、DC へのアクセスが最も容易なドメインを最初にアップグレードします。

  • リスクや混乱の緩和 どのような場合においても、複数のドメインを選択する場合には、大多数のユーザーの混乱を最小限に抑えるために規模の最も小さいドメインから最初にアップグレードします。特に、移行作業の体験を目的としている場合はこのようにします。

  • ジョブの遂行 移行作業を体験し、自信をもって作業ができるようになったら、より規模の大きいアカウント ドメインのアップグレードを進めます。

  • アカウント ドメイン再構築の対象 ドメインの再構築を計画している場合は、再構築の対象候補とするものを移行作業の初期の段階で先にアップグレードします。既に存在しなくなった対象ドメインに、ほかのドメインを統合することはできません。

リソース ドメインの順序
リソース ドメインが複数ある場合は、次のガイドラインを参考にしてアップグレードの順序を決めてください。

  • アプリケーションで必要な機能の提供 最初に、Windows 2000 のインフラや機能を必要とするアプリケーションを展開しようとしているドメインをアップグレードします。たとえば、Active Directory は Microsoft Exchange Platinum (Microsoft Exchange の次期リリース版の開発コードネーム) で必要です。

  • 多数のワークステーションを持つドメイン 次に、多数のワークステーションを持つドメインをアップグレードします。これにより、IntelliMirror・などの Windows 2000 インフラを利用できるようになります。

  • リ ソース ドメイン再構築の対象 アカウント ドメインの場合とまったく同様に、ドメインの再構築を計画している場合は、再構築の対象候補とするものを初期の段階で先にアップグレードします。

ワークステーションとサーバーのアップグレード

この文書では、ドメインのアップグレードおよび統合を中心に説明していますが、Windows 2000 のワークステーションやメンバ サーバーの展開はドメイン インフラのアップグレードが完了するまで後回しにすべきである、ということではありません。既存の Windows NT 環境で Windows 2000 のワークステーションやサーバーを使用しても、数多くの利点が得られます。次の表は、ワークステーションやサーバーをアップグレードするだけで得られる利点のいくつかについて説明したものです。

表 6 ワークステーションやサーバーをアップグレードするだけで得られる利点

利点

機能

管理能力
  • プラグ アンド プレイ
  • ハードウェア ウィザードとデバイス マネージャ
  • USB (ユニバーサル シリアル バス) のサポート
  • Microsoft 管理コンソール
  • 新しいバックアップ ユーティリティ

ファイル システム サポート
  • ディスク クォータのサポート、ディレクトリ構造のデフラグ (断片化除去)、圧縮ネットワーク I/O などからなる NTFS 5.0 の拡張機能
  • FAT32

アプリケーション サービス
  • Microsoft Win32® ドライバ モデル
  • Microsoft DirectX® 5.0
  • WSH (Windows Scripting Host)

情報の共有と公開
  • Windows NT Server 対応 Microsoft 分散ファイル システム (DFS) はネットワーク サーバー コンポーネントの 1 つです。ネットワーク上のデータの検索と管理が容易になります。
  • 統合されたインターネット シェル

スケーラビリティと可用性
  • 対称型マルチプロセッサ サポートの強化

 

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

ドメインの再構築

ドメインのアップグレードは、ドメイン構造を含めた現在の環境の多くをできるだけ維持するように計画された手順です。これに対してドメインの再構築は、組織のニーズに応じてフォレストの再設計を可能とするように計画された手順です。再構築では予想と異なる結果がいくつも生じる可能性がありますが、通常は現在の構造を何らかの形で合理化し、より個数の少ない大規模なドメインへと移行することになります。

Windows NT のドメイン再構築機能を備えたサードパーティ製のディレクトリ管理ツールは従来から多数リリースされていますが、Windows 2000 では、いくつかのドメイン再構築のシナリオを実現するネイティブな機能が初めて提供されています。具体的には次の機能があります。

  • セキュリティ プリンシパルをドメイン間で移動できると同時に、移動中も移動前と同じリソースへのアクセスを維持できます。

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

Microsoft では、ドメインの再構築を容易に実行するためのグラフィカルなツールのほか、再構築作業を支援する、スクリプト作成可能ないくつかの COM コンポーネントとコマンド ライン ユーティリティを提供しています。これらは、後述するシナリオを実行する多くの顧客にとって便利なものです。さらに洗練されたグラフィカル ツールを必要とする方のために、Microsoft では ISV (独立ソフトウェア ベンダ) 各社と協力して、より完全な機能を備えたサードパーティ製ツールを市場に提供する準備を進めています。

いつ再構築を行うべきか
再構築は次の 3 つの状況において実行することが適切です。

  • アップグレード後 組織がドメインの再構築を実行する場合、Windows 2000 への移行における第 2 段階としてアップグレードの後に行うのが最も一般的な契機となります。

    アップグレードでは、たとえば本来正しい信頼構造を持っていて管理上の影響のないドメイン グループなど、"より簡単な場合" の移行については対応がなされています。
    このような状況では、複雑さを減らすために、あるいは信頼されていない管理者を持つリソース ドメインを安全な方法でフォレストに移すために、ドメイン構造のほかの部分を再び稼働する目的で再構築を行うのが普通です。

  • アップグレードの代わり 組織によっては、現在のドメイン構造が何らかの理由によって復旧が困難であると判断される場合や、移行作業の間、現在の実稼動環境の安定性を危険にさらすだけの余裕が持てない場合があります。このような状況では、現在の実稼動環境とは別に理想的な、あるいは原始的な Windows 2000 環境を設計して構築することが最も簡単な移行手段となることがあります。この場合、新しく構築した Windows 2000 環境を徐々に実稼動環境に移行することを目的とします。

    新しいフォレストの構築が完了したら、パイロット環境から再構築を始めます。数名のユーザー、グループ、およびリソースを新しい環境に移行させて先行集団として機能させ、新しい構造でも業務が通常どおり遂行できることを確認します。
    この段階が正常にクリアできたら、パイロット環境を新しい環境に段階的に移行させます。特定の時点で Windows 2000 が実稼動環境になり、古いドメイン構造の役割が解除されて、残りのリソースが再展開されます。

  • 移行後 この場合は、完全な Windows 2000 環境においてドメイン全般を再設計する際、その一環として再構築が行われます。このような作業は、移行後数年が経過して、たとえば組織上の変更や企業の買収など、何らかの理由で現在の構造が不適切になったときに行われることが考えられます。

この章では上記の 1 番目と 2 番目のケース、つまり Windows NT 4.0 から Windows 2000 に初めて移行する場合を中心に説明しています。これから説明する手段の一部は 3 番目のケースで役に立つものもありますが、このケースについては初回リリース後にさらに完全なツールや技術が開発される予定です。

mignt06

図 6: 再構築を行う契機

なぜ再構築を行うのか
ドメインの再構築を行う理由はさまざまですが、主な理由としては、Windows 2000 の機能を利用してドメイン構造を改良し、次のような組織のニーズに対応できるようにすることだと思われます。

  • スケーラビリティの強化 従来の Windows NT ドメイン構造が SAM アカウント データベースのサイズ制限を回避するように設計されている場合は、マスタ ドメイン モデル、またはマルチマスタ ドメイン モデルを実装することになります。Active Directory によるスケーラビリティの大幅な改善により、文字通り数百万ものユーザー アカウントやグループをスケーリングしながら、現在の Windows NT ドメインをより個数の少ない大規模な Windows 2000 ドメインに再構築できます。

  • 管理権限の細分化 組織によっては、現在のモデルで管理責任の委任を可能にするようにリソース ドメインを実装している場合があります。Windows 2000 の OU には任意の種類のセキュリティ プリンシパルを含めることができ、管理権限を適切に委任できます。多くの場合、リソース ドメインを OU に変換する方法のほうが、より適切に管理権限を委任できます。

  • 管理の簡素化 上記に示したような委任を可能にした結果、または一般に企業の買収の結果として、ドメイン構造の信頼関係が複雑になることがあります。このようなドメインは OU として実装したほうが管理が簡素化されて好ましい場合があります。あるいは、ドメイン ツリーを設計し直してより数の少ない双方向の推移的な信頼にし、その利点を活かすようにすることもできます。

以降で説明するシナリオでは、初めてのアップグレードが完了したことを必ずしも前提にしているわけではありません。

ドメインの再構築に伴う影響
再構築のシナリオを実現するためには、既に示したようにドメイン間でセキュリティ プリンシパルと DC を移動できる機能が前提となります。この節では、これらの機能に伴う影響と、それらが再構築の計画に与える影響について考察します。

セキュリティ プリンシパルの移動が SID に与える影響
SID のドメインに関する性質については既に説明しましたが、その結果として、ユーザーやグループなどのセキュリティ プリンシパルをドメイン間で移動すると、新しいドメインに対して必ず新しい SID が発行されます。

アップグレードの節でも触れましたが、Windows NT のセキュリティ モデルにおけるリソースへのアクセスは、オペレーティング システムがユーザーのアクセス トークンを探し出し、ユーザーのプライマリ SID とユーザーがメンバとなっているすべてのグループの SID を、リソースのセキュリティ記述子の ACL に対して評価することで実行されます。ACL は SID のリストからなり、SID によって識別されるセキュリティ プリンシパルに対してリソースへのアクセスを許可または拒否するかを示しています。したがって、SID が変更されると、きわめて大きな影響が暗黙裡に生じることになります。

この暗黙裡の影響を具体的に示すために、Windows NT のセキュリティに関する知識に基づいて例を示すことにします。Bob は Hay Buv Toys 社の従業員で、Windows NT 4.0 の HAYBUV-ACCT というマスタ ドメイン内にアカウントを持っています。Bob はまた同じドメイン内にある Finance Analysts というグループのメンバでもあります。

Hay Buv Toys では Win32 対応の財務アプリケーションを使用しています。このアプリケーションは、HAYBUV-RES1 というリソース ドメイン内にある多数の Windows NT Server コンピュータ上で実行されます。PDC 上で作成されたローカル グループがドメイン内のすべての DC 間で共有されるという特長を活かすために、この財務アプリケーションを実行する各サーバーは、ドメイン内で BDC として動作しています。PDC 上には Financial Resources という共有ローカル グループが既に作成されており、アプリケーションが使用するファイルの ACL を保存するために使用されています。グローバル グループ HAYBUV-ACCT\Finance Analysts は HAYBUV-RES1\Financial Resources のメンバです。

Bob はリソース ドメイン内にある FIN_FILES1 というファイル サーバーへのアクセス権も持っています。FIN_FILES1 は単にメンバ サーバーとして動作している Windows NT Server コンピュータです。FIN_FILES1 は、Bob の所属するグループに関連するファイルの ACL を保存するために Finance Files というローカル グループを使用しています。HAYBUV-ACCT\Finance Analysts は FIN_FILES1\Finance Files のメンバです。Bob はいくつかの非公開のプロジェクトに従事しており、FIN_FILES1 というディレクトリを持っています。このディレクトリは Bob だけがディレクトリ内のファイルにアクセスできるように保護されています。このディレクトリの ACL には、Bob がディレクトリを完全に制御できるようにする 1 個のエントリが含まれています。

mignt07

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

セキュリティ プリンシパルの移動
既に説明したように、ドメイン間でセキュリティ プリンシパルを移動すると、その効果としてセキュリティ プリンシパルの SID が変更されます。

ドメインの再構築に伴う移行の中で Bob のアカウントが別のドメインに移動した場合、どのようなことが起こるでしょうか。このことを示すことで、セキュリティ プリンシパルの移動に関する暗黙裡の影響を評価できます。

例を示すために、ここでは HAYBUV-ACCT が既に Windows 2000 にアップグレードされていて、ルート ドメイン HAYBUV.TLD の子ドメインとして企業の新しい Windows 2000 フォレストに連結されていると想定します。HAYBUV-ACCT は既にネイティブ モードに切り替えられていますが、その目的は再構築であり、メンバはフォレスト内のどこかにある HAYBUV-ACCT2 という新しい Windows 2000 ドメインに移動されています。

Bob のグローバル グループ メンバシップに与える移動の影響
HAYBUV-ACCT \Bob はグローバル グループ HAYBUV-ACCT\Finance Analysts のメンバです。グローバル グループには、それ自身のドメインからのメンバしか収納できません。このため、Bob が新しいドメインに移動すると彼の新しいアカウントはこのグループのメンバとなることができず、彼はこのグループで利用していたリソースへのアクセス権を失うことになります。

仮に、新しいドメインとリソース ドメインとの間に十分な信頼があるとすれば、いくつかの方法でこの問題を解決できそうです。

  • Bob の新しい SID をリソースの ACL に追加する。 Bob がグループのメンバとして以前にアクセスできたすべてのリソースの ACL に彼の新しい SID を追加することで、引き続きリソースにアクセスできます。この方法は次のような理由から時間がかかり、あまり優れた方法とはいえません。

    • ドメイン再構築に伴う操作の多くは、一定の期間をかけて段階的に実行されます。この移行期間中、Finance Analysts グループに新しいリソースが作成されないという保証はありません。このため、移行期間中 2 つのグループが共存している間は、引き続き権限の再割り当てが必要になります。

    • Microsoft は ACL を個人ではなくグループで使用することをお勧めします。この理由は、特定のジョブ機能を実行するグループのメンバシップは時間をかけて変更される可能性があり、ユーザーを参照している無数のリソースの ACL を変更するよりも、ユーザーをグループから取り出したほうが簡単なためです。Bob の職務内容が変更されて Finance Analysts グループのメンバである必要がなくなった場合はどうなるでしょうか

  • グループを移動する。 Windows 2000 でセキュリティ プリンシパルを移動できるのとまったく同じように、グループ自身を新しいドメインに移動できます。しかし、グループを参照する ACL は自身の SID も参照するため、最初の方法と同様の手間が必要になります。つまり、新しい SID を参照するために権限の再割り当てが必要になります。

  • 対象ドメイン内に並存グループを作成する。 グループを移動する場合は、すべてのグループ メンバを 1 回のトランザクションで移動することを移行計画で配慮しておかないと問題が起こります。つまり、グループを古いドメインの中で維持する必要があり、新しいドメインの中に新しい並存グループを作成します。リソース アクセスは元のグループとそのメンバに対して維持されますが、新しいグループへのアクセスを許可するためにリソース権限を再割り当てする必要があります。結局、この場合もグループが両方のドメイン内に存在する間、引き続き権限の再割り当てが必要になります。

Bob を直接参照している ACL に与える移動の影響
Bob にはメンバ サーバー FIN_FILES 上にある、一部のリソースへのアクセスも許可されています。彼の SID はこのサーバー コンピュータの ACL に出現します。ユーザーをリソースの ACL に追加することはまったく正しいことですが、表面上は Bob の移動の影響によってそのサーバー上にあるすべてのリソースの権限を再割り当てして、彼の新しいドメイン SID を追加しなければならないように思われます。

Microsoft は、リソース ACL 内では個人ではなくグループを使用することを常にお勧めしています。しかし、この推奨措置を実施していない組織も多数見受けられ、そのような場合には組織全体にわたるリソースについて、そのすべての ACL 内にある移動されたユーザーへの参照をすべて探し出し、更新しなければならなくなります。

SIDhistory
前述の対処例の多くは、SIDhistory と呼ばれる Windows 2000 の新しいディレクトリ属性のおかげで不要になります。

SIDhistory は Active Directory のセキュリティ プリンシパルの属性の 1 つで、移動されたユーザーやセキュリティ グループなどのオブジェクトの SID を格納するために使用されます。

ユーザーまたはグループを新しい Win32 API を使用して移動したり、または Microsoft から提供されている Win32 API 上で稼働する基本ユーティリティを使用して移動すると、操作の中でそのユーザーやグループを表すオブジェクトの SIDhistory 属性が以前の SID で更新されます。その後ユーザーがシステムにログオンすると、ユーザーのグループ メンバシップと同様に、システムはユーザーの SIDhistory 内のエントリを取得してユーザーのアクセス トークンに追加します。

グループは移動できるため、システムは、ユーザーがメンバとなっているすべてのグループの SIDhistory 属性も取得し、ユーザーのアクセス トークンに追加します。

トークン内のこれらの SIDhistory は、認証確認の間、通常のグループ メンバシップのようにシステムを参照します。そのため、Windows 2000 や Active Directory をまったく認識しない下位レベルのシステムにも適切なアクセス権を許可できます。

mignt08

図 8: SIDhistory を通じて許可されたリソース アクセス

MoveTree.exe を使用した SIDhistory 更新中でのユーザーとグループの移動
MoveTree とは、Windows 2000 で利用できるドメイン移行用の基本ユーティリティの名前です。このユーティリティでは、セキュリティ プリンシパルを含むディレクトリ オブジェクトを同じフォレスト内の Windows 2000 ドメイン間で移動することが可能であり、それと同時に移動されたユーザーやグループの SIDhistory を更新します。MoveTree は、OU、グループ、ユーザー アカウント、コンピュータ アカウントなどのオブジェクトを移動します。

MoveTree を使用する際の制約条件
MoveTree ユーティリティを使用する際は、次に示すいくつかの制約条件があります。

  • 混在またはネイティブ モードの移動元ドメイン オブジェクトの移動元のドメインは必ず Windows 2000 の混在またはネイティブ モードのドメインでなければなりません。

  • ネイティブ モードの移動先ドメイン オブジェクトの移動先のドメインは必ず Windows 2000 のネイティブ モードのドメインでなければなりません。

  • 移動元および移動先のドメイン 同じフォレスト内になければなりません。

  • 空のグローバル グループ MoveTree は OU とその中身を移動し、移動元ドメインがネイティブ モードであればユニバーサル グループとその中身を移動しますが、グローバル グループは空のものだけを移動します。現バージョンの MoveTree でグローバル グループを移動する場合は、その中身を設定解除してから移動し、それから移動先で再設定する必要があります。

  • クローズド セット オブジェクトは "クローズド セット" の中に移動する必要があります。この言葉の意味は、ユーザーおよびグローバル グループの移動の場合と、コンピュータの移動の場合とで異なります。コンピュータの移動の場合、Windows NT DC においては共有ローカル グループを使用する場合があり、Windows 2000 DC においてはドメイン ローカル グループを使用する場合があります。さらに、ネイティブ モードのドメインにおいては、サーバーおよびワークステーションを使用する場合があります。

クローズド セットとユーザーおよびグローバル グループの移動
既に説明したように、グローバル グループには、それ自身のドメインからのメンバしか収納できません。グローバル グループを参照している ACL によって保護されたリソースに引き続きアクセスするためには、ユーザーがドメイン間で移動するときに、そのユーザーがメンバとなっているすべてのグローバル グループも同時に移動する必要があります。同じように、グローバル グループを移動する場合はそのメンバも同時に移動する必要があります。

ここで、ユーザーとグローバル グループのクローズド セットとは、移動しようとする各ユーザーについてそのすべてのグローバル グループも同時に移動されるようなセットであり、移動しようとする各グループについてそのすべてのメンバも同時に移動されるようなセットのことです。

移動元ドメインがネイティブ モード ドメインであれば、グローバル グループにはほかのグローバル グループも収納できます。その場合は入れ子の各グループについて、そのすべてのメンバと、それらのメンバがメンバとなっているすべてのグローバル グループを移動する必要があります。

クローズド セットとコンピュータの移動
共有ローカル グループとドメイン ローカル グループは、作成元のドメインの内部にしかスコープを持っていません。このようなグループが移動した場合、移動元のドメイン内の ACL にあるそれらのグループへの参照が、すべて解決不可能になります。

ここで、コンピュータのクローズド セット、および共有ローカル グループまたはドメイン ローカル グループのクローズド セットとは、移動しようとするこれらの各グループについて、そのグループを参照している ACL のあるドメイン内のすべてのコンピュータも同時に移動されるようなセットであり、移動しようとする各コンピュータについて、そのリソースの ACL 内で参照されている共有ローカル グループまたはドメイン ローカル グループも同時に移動されるようなセットのことです。

クローズド セットの回避方法
設定済みのグローバル グループとクローズド セットの移動に関する制約条件は特に煩雑です。大規模なグローバル グループの設定解除と再設定には非常に時間がかかり、場合によっては実現可能な最小のクローズド セットが移動元のドメイン全体にわたってしまうこともあります。

このような問題を解決する手段として次の 3 つがあります。

  • 並存グループ 移動する各グループごとに移動先ドメイン内に並存のグローバル グループを作成します。次に、元のグループを参照している ACL のある企業内のすべてのリソースの場所を特定し、並存グループへの参照を含むようにそれらの権限を再割り当てします。

    グローバル グループを移動する場合、任意の信頼されているドメイン内のリソースでグローバル グループが参照されている可能性があります。また、ネイティブ モードの移動元ドメインからドメイン ローカル グループを移動する場合には、ドメイン内の任意のコンピュータ上でドメイン ローカル グループを使用できます。このような場合には作業が大規模になる可能性が高くなります。

  • ユニバーサル グループ 移動元ドメインをネイティブ モードに切り替えた後、移動しようとするグループのグループ種別をユニバーサルに変更します。ユニバーサル グループのスコープはフォレスト全体にわたるため、グループをユニバーサル グループに変更すれば、リソースへのアクセスを維持したまま安全に移動できます。

    この方法を実行するときは多少注意が必要です。既に説明したように、ユニバーサル グループのメンバシップは GC 内に格納されますが、このことは GC の複製トラフィックの発生を暗に示しています。
    このため、この方法はユーザーとグループを新しいドメインに移行している間に暫定的な手段として実行してください。そして、移行作業が完了した時点でグループ種別を元に戻してください。

  • クローン化 移動元ドメインから移動先ドメインに対してグループのクローンを作成し、SIDhistory はそのままにしておきます。この方法には独自の制約条件がいくつかあります。詳細については、次の「セキュリティ プリンシパルのクローン化」の節で説明します。

セキュリテ ィ プリンシパルのクローン化
これまでは再構築について、セキュリティ プリンシパルの移動によって可能なこととして説明してきましたが、場合によってはセキュリティ プリンシパルの移動を破壊的な操作とみなすこともできます。これは、セキュリティ プリンシパルの移動ではフォールバックが省かれるため、移行中に万一問題が生じた場合に古いアカウントに戻すことができないためです。

顧客の多くは、ユーザーを新しい Windows 2000 ドメインに段階的に移行しつつ、試験移行や一斉移行の際に万一障害が発生しても復旧できるように、ユーザーの古いアカウントを移動元のドメインに保持しておきたいと考えています。このような機能のことを、ここでは "クローン化" と呼ぶことにします。クローン化は Windows 2000 で実現された機能です。Microsoft は ClonePrincipal と呼ばれるいくつかの基本ユーティリティを提供しています。これらのユーティリティを使用すると、Windows NT 4.0 または Windows 2000 の移動元ドメインから Windows 2000 のネイティブ モード ドメインに対して、移動元のアカウントを削除せずにユーザーやグループのクローンを作成できます。同時に、元のアカウント SID を新しいアカウントの SIDhistory に追加して、リソース アクセスを維持します。

ClonePrincipal
ClonePrincipal は、セキュリティ プリンシパルのクローン化を可能にするスクリプト作成可能なコンポーネントからなり、コンポーネントにはその使用方法を具体的に示す便利なサンプル スクリプトも付いています。Microsoft Visual Basic® (VB) の知識のある管理者ならば、これらのスクリプトをカスタマイズできます。

クローン化はセキュリティに重大な影響を与える操作であるため、ClonePrincipal の使用についてはいくつかの制約条件があります。

  • 移動元および移動先のドメインが同じフォレスト内にないようにします。

  • 移動元アカウントの SID が、移動先フォレスト内にプライマリ SID として既に存在していたり、または任意のセキュリティ プリンシパルの SIDhistory 内に既に存在しないようにします。

  • ClonePrincipal を実行するために、ユーザーは移動元および移動先の両方のドメインでドメイン管理者権限を持っている必要があります。

  • 移動先ドメインで監査を有効にしておく必要があります。移動元ドメインでも監査を有効にしておくことをお勧めします。

信頼の確立
クローン化のシナリオでは移動元および移動先のドメインが別々のフォレスト内にあり、リソース アクセスを保証するために必要な信頼を確立することが最初の手順の 1 つになります。

ドメイン信頼の列挙や新しい信頼の確立などの処理を実行するツールとして、『Windows 2000 Server Resource Kit』に付属の「Netdom.exe」があります。

このツールは、コンピュータ アカウントの作成や、ワークステーションまたはサーバー コンピュータのドメイン メンバシップの更新にも使用できるので便利です。

サーバーの移動
先に紹介した Bob の例では、Bob はコンピュータ ローカル グループ FIN_FILES1\Finance Files を参照している ACL、および彼のドメイン アカウントを直接参照している ACL を介して、メンバ サーバー FIN_FILES1 上にある一部のリソースにアクセスできます。

DC の移動に伴う影響、つまり共有ローカル グループとドメイン ローカル グループの維持を確保する必要性については、既に説明しました。しかし、FIN_FILES1 などのメンバ サーバーやワークステーションを移動した場合の影響についてはどうでしょうか

仮に、Bob の新しいアカウント ドメインへの信頼を持つドメインにサーバーが移動されたとすれば、既に見てきたように、SIDhistory によって、Bob は Bob を直接参照している ACL を持つリソースにアクセスできることが保証されています。また、コンピュータ ローカル グループはローカル コンピュータのアカウント データベースに存在していることから、コンピュータ ローカル グループを参照している ACL も引き続き正常に機能します。したがってサーバーの移動による影響はなく、その SID を変更する必要もありません。

Windows NT 3.51 と SIDhistory
ドメインの再構築を計画するときは、Windows 2000 ドメインでの Windows NT 3.51 の使用に伴う既知の問題について認識しておく必要があります。

問題は認証および認可に関するもので、特に Windows NT 3.51 におけるアクセス トークンの生成方法に関係します。ユーザーが Windows NT 3.51 ワークステーションで対話形式で認証されるか、または Windows NT 3.51 サーバーでネットワーク経由で認証されると、ユーザーのアカウント ドメイン、および認証が行われたサーバーやワークステーションからのローカル グループに関する SID だけを使用して、トークンが生成されます。その結果、Windows NT 3.51 のアクセス トークンには、アカウント ドメインの外部からのユニバーサル グループや、リソース ドメインからのドメイン ローカル グループが含まれることはありません。定義上、ユーザーの SIDhistory からのエントリ、またはユーザーがメンバとなっているすべてのグループの SIDhistory からのエントリは、アカウント ドメイン以外のドメインからのものであり、これらもトークンからは除外されます。

このことは Windows NT 3.51 において、ログオンしたユーザーのアカウント ドメイン以外のドメインからの SID が、アクセス制御に対して評価されるときに無視されることを暗に示しています。

ほとんどの場合、この問題によって望ましくないアクセス拒否が生じます。

ClonePrincipal と SID の解決
ドメインの再構築計画の際に留意しておかなければならないもう 1 つの問題は、SID がユーザー名に解決される方法に関するものです。ある特定の条件のもとでは、ユーザーが Windows NT ファイル システム (NTFS) パーティション上のファイルやフォルダのセキュリティ プロパティを参照しようとするときに、既にクローン化されたユーザーとグループの SID が解決されないことがあり、その場合には Unknown User というラベルが表示されます。このような現象が起きると、管理者は正当なリソース アクセスの妨げを恐れて ACL の編集をためらうことが考えられ、管理上問題となる可能性があります。

この問題を理解するため、SID の解決に使用される API がどのようにして解決を試みるのかを調べてみます。API は次の順序で解決を試みます。

  1. 最初に、既知の SID のリストを調べて SID の名前を探します。

  2. 対象となる SID が既知の SID に対応していなければ、組み込みのローカル アカウント、および管理上定義されているローカル アカウントを調べます。

  3. 次に、プライマリ ドメインを調べます。

  4. プライマリ ドメインで認識されなかった SID は、SID プレフィックスに対応する信頼されるドメインと比較されます。

  5. 次に、Windows 2000 フォレスト内にあるすべてのドメイン内のすべてのアカウントの SID と比較されます。これには、フォレスト内のアカウントの SIDhistory フィールドにしか現れない SID も含まれます。以上の参照を実行するためには、API はフォレストの GC を照会できる必要があります。

以上の動作にはいくつかの影響が伴います。

  • GC を照会せずに名前を解決できるためには、クローン化されたアカウントが信頼されるドメイン内になければならず、引き続き存在していなければなりません。

  • 上記の手順 5 による名前の解決のためには、API が SID の確認を試みたコンピュータで Windows 2000 が動作しているか、またはコンピュータが Windows 2000 ネイティブ モード ドメイン内になければなりません。

この問題は、MoveTree を使用してユーザーを移動した場合には起こりません。MoveTree による移動は同じ Windows 2000 フォレスト内部に制限されており、この問題はユーザーを異なるフォレスト間でクローン化した場合にだけ起こります。

この問題を回避するには次の手段を検討してください。

  • ユーザーの移行後、できるだけ速やかにすべてのワークステーションを移行先のフォレストに移行させます。

  • 企業全体にわたるリソースの ACL を再割り当てし、古い SID への参照を削除します。

  • リソースの ACL の再割り当てが完了して古い SID への参照がすべて削除されるまで、古いドメイン内の移動元アカウントを維持しておきます。

プロファイルと SIDhistory
ユーザーが Windows NT ワークステーションにログオンしている間、システムはそのユーザーのプロファイルをロードします。プロファイルにはユーザー固有の設定情報が収められています。システムはユーザーの SID を取り出し、その文字列表現に関連して名付けられたキーをレジストリの HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\ProfileList というキーの下で検索して、このプロファイルを探します。

このような動作は、移行後にユーザーが自分のワークステーションにログオンしようとしても、ユーザーのログオン プロファイルが失われてしまう恐れがあることを暗に示しています。これは、ユーザーのプライマリ SID が変更され、古いプロファイルが古いプライマリ SID の下に格納されてしまうためです。

MoveTree などのツールを使用して同じフォレスト内の Windows 2000 ドメイン間でユーザーを移動した場合は、MoveTree がユーザーの GUID を保存しているのでこのような問題は起こりません。Windows 2000 クライアントの新しいプロファイル処理コード機能ではこのような GUID の不変性を利用しており、ProfileList キー内でユーザーの SID を見つけられなかった場合でも、システムはユーザーの GUID を取得し、レジストリの次のキーの下で、ユーザーの GUID の文字列表現に関連して名付けられたキーを検索します。

HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\ProfileGuid

該当するキーが見つかると、SidString というキーの値をそのキー内で検索します。SidString は、ユーザーの GUID からユーザーの SID へのフォールバック マッピングを提供するものです。この後、システムは ProfileList キーの下で SidString を含む SID を検索でき、そのような SID が見つかると、そのキーの名前をユーザーの新しい SID の文字列表現に変更します。この場合、システムは SidString の値も変更します。

以上の説明から、次のような条件が満たされる場合に、プロファイルの消失に関する問題が起きる恐れのあることがわかります。

  • Windows NT 4.0 ドメインからユーザーがクローン化された。

  • Windows 2000 からユーザーがクローン化された。

  • Windows 2000 ドメインからユーザーがクローン化されたが、そのユーザーが Windows NT 4.0 ワークステーションでログオンしようとしている。

次の節では、これらの条件において問題を回避するためのいくつかの選択肢について説明します。

プロファイルの移行
移行したユーザーがプロファイルを利用できるようにし、同時にフォールバックの実行を可能にするための基本的な方法として、次の 2 つがあります。

  • 共有プロファイル ユーザーの元のアカウントと新しいアカウントの両方で同じプロファイルを利用できるようにします。プロファイルの 1 つのコピーに対して、両方のアカウントからアクセスと更新が行われます。

  • コピーされたプロファイル 元のプロファイルを、ユーザーの元の SID に関連して名付けられたキーの下にある現在の場所から、ユーザーの新しい SID に関連して名付けられたキーにコピーします。各アカウントにはそれぞれプロファイルの別個のコピーが独自に関連付けられます。一方が更新されても他方には反映されません。

どちらの方法にもそれぞれ長所と欠点があります。

共有プロファイル

表 7 共有プロファイルの長所と欠点

長所

欠点

一方のアカウントでログオンした後に他方のアカウントでログオンしても、アクセスが可能であり、プロファイルが更新されます (たとえば、[マイ ドキュメント] やショートカットなどが変更されます)。

古いアカウントと新しいアカウントとを切り替えたときの結果は現時点では予測できません。例として、Windows 2000 の新しいアカウント プロファイルがあります。これにはグループ ポリシー参照が含まれていると考えられますが、異なるグループ ポリシーが展開されている (またはグループ ポリシーがまったく展開されていない) 移動元のアカウントにフォールバックするときに、このアカウント プロファイルが使用されます。

プロファイルの 1 つのコピーしか格納しないのでディスク領域が節約されます。

プロファイルの共有を可能にするユーティリティが利用できます。

 

コピーされたプロファイルの移行

表 8 コピーされたプロファイルの長所と欠点

長所

欠点

動作の予測がいっそう容易になります。プロファイル間でデータが共有されないため、異なるドメイン内およびフォレスト内で、一方のアカウントのプロファイルが他方のアカウントだけで有効なデータによって "汚染" されることがありません。

展開方針に則って新しいドメインに展開されたアプリケーションで、その "フォールバック" の結果が予測できないことがあります。たとえば、ある特定の条件下において、古いアカウント プロファイルが移行先のアカウント活動によって変更されていなくても、移行先のドメイン グループ ポリシーによってデスクトップ上に展開されたアプリケーションが自分自身のインストールを解除しようとするなど、予測不可能な動作を起こすことがあります。
2 つのプロファイルを格納するため、ディスク領域を余分に消費します。

 

Microsoft では現在この問題について対応中であり、移行ツールの中でマッピング オプションを提供する予定です。

Microsoft のドメイン移行ツール
Microsoft では、Web から自由にダウンロードできる移行ツールを現在開発中です。このツールは、これまで説明した操作をグラフィカルに実行する機能と、次に説明する移行のシナリオを実行する機能を提供する予定です。

ツールの詳細については、近日中にリリースされる予定です。

ドメイン移行基本ユーティリティとドメイン移行シナリオ
ドメイン移行基本ユーティリティについては既にいくつか言及してきました。これらの基本ユーティリティは、COM オブジェクトのセットとサンプル スクリプトからなります。サンプル スクリプトは、管理ユーティリティの基本として顧客による改良が可能なように設計されたもので、Microsoft で文書化とテストが完了している、いくつかのドメイン移行シナリオを支援するように作られています。ドメイン移行シナリオは、顧客から寄せられた移行のニーズに関するフィードバックをもとに開発されたものです。Microsoft で既に文書化されているシナリオは Windows 2000 への初めての移行を容易にすることを主な目的としています。

Microsoft では現在 ISV (独立ソフトウェア ベンダ) に対して、ISV 各社のツールがこれらのシナリオのサポートを保証するように働きかけています。ただし、ISV のツールにはシナリオ以外の手法が可能なものや、さらに洗練された機能を備えたものもあります。

基本ユーティリティとシナリオ文書は各種の情報源から利用できる予定です。Microsoft では、Windows 2000 のリリース後もこれらの拡張や追加を進めていく計画です。

ドメイン移行シナリオ
Microsoft では Windows 2000 の 2 つの移行シナリオを既に文書化しています。これらのシナリオは顧客の再構築のニーズのほとんどに対応しており、Windows NT 移行元ドメインから Windows 2000 移行先ドメインへのユーザーとコンピュータの移動を容易にすることを目的としています。

  • ユーザーの Windows NT から Windows 2000 への段階的な移行

  • リソース ドメインの Windows 2000 OU への統合

ユーザーの Windows NT から Windows 2000 への段階的な移行
このシナリオの目的は、組織において Windows NT の実稼動環境に影響を与えることなく、組織のユーザーを原始的な Windows 2000 環境に段階的に移行させるために必要な手順と基本ユーティリティを示すことです。

現在の実稼動環境に影響を与えないということは、移行中も実稼動環境に手が加わることがないことを暗に示してします。このため、顧客は移行中に万一障害が発生しても、いつでも以前の実稼動のドメインにフォールバックできます。

移行が完了すれば、古いアカウント ドメインの役割が解除されて DC が再割り当てされたものと判断されます。

シナリオの手順
シナリオの手順は次のとおりです。

  1. 原始的な Windows 2000 フォレストを作成する。 この活動では、単に標準的な手順を使用して、顧客の名前空間の計画活動において識別される必要条件と構造を反映するように、移行先となる新しい Windows 2000 フォレストを作成します。新しいフォレスト内に作成されるドメインはネイティブ モードの Windows 2000 ドメインになります。

  2. リソース アクセスを維持するためにフォレストに必要な信頼を確立する。 この活動では、任意のリソース ドメインから移行元の Windows NT ドメインに対して現時点でどの信頼が存在しているかを、NETDOM を使用して照会します。

    NETDOM で得られた出力は信頼のリストと比較できます。このリストには、移行先ドメイン内のユーザーとグループからリソースにアクセスするために必要であると NETDOM が判断した信頼が列挙されています。まだ存在していない信頼があれば NETDOM を使用して確立できます。

  3. 移行先ドメイン内のすべての移行元グローバル グループのクローンを作成する。 既に説明したように、ほとんどのリソースはグローバル グループを参照する ACL を使用して保護され、通常は、共有ローカル グループまたはコンピュータ ローカル グループを間接的に経由して保護されます。信頼の確立が完了したら、次の作業として、関連するグローバル グループが移行先ドメイン内で確実に利用できるようにします。

    これには、ClonePrincipal を使用してすべてのグローバル グループのクローンを作成するのが最も簡単です。

  4. ユーザー セットを特定してクローンを作成する。 移行先ドメインに移行元のグローバル グループのクローンをすべて作成したら、ユーザーの移行作業を開始できます。

    ほとんどの場合、顧客はユーザー セットの段階的な移行を望んでいるため、この作業は反復的な作業になります。移行するユーザー セットを特定した後、ClonePrincipal を使用して移行元のユーザーのクローンを移行先ドメインに作成します。
    この作業では、移行される個々のユーザーを、移行元ドメイン内でメンバシップを持っていたすべてのグローバル グループの移行先クローンに追加する必要があります。

  5. 移行元ドメインの役割を解除する。 すべてのユーザーとグループを移行先フォレストに永続的に移動したら、最後の作業として移行元ドメインの役割を解除します。これには、移行元ドメインの BDC の電源をオフにしてシステムから除外し、最後に移行元ドメインの PDCの電源をオフにしてシステムから除外します。

    これらの DC を新しいフォレストに再割り当てしようとしている場合は、それらを Windows 2000 にアップグレードした後、DC に昇格するか、または既に説明したようにメンバ サーバーとしてそのままにしておくことができます。

このシナリオは個々の手順についてテストを行ってください。特にユーザーの移行段階では念入りに行ってください。移行ごとに特定のユーザーについてログオンをテストするのが賢明です。役割解除前の段階でエラーが生じた場合は、移行作業を中断して、移行元の実稼動のドメインで作業を続けることができます。

mignt09

図 9: ユーザーの Windows NT から Windows 2000 への段階的な移行

リソース ドメインの Windows 2000 OU への統合
このシナリオの目的は、組織において複数のリソース ドメインをネイティブ モードの Windows 2000 の OU に統合するために必要な手順と基本ユーティリティを示すことです。通常は、このシナリオによって複雑な信頼の管理コストの軽減も図られます。

このシナリオでは、アプリケーション サーバーは対象となる OU 内のメンバ サーバーになります。各ドメイン内のアプリケーション サーバーは共有ローカル グループを利用しているものとみなされ、ドメインにはいくつかのメンバ サーバーとワークステーションがあるとみなされます。

再構築が達成されれば、組織は古いドメインの役割を解除できます。

シナリオの手順
シナリオの手順は次のとおりです。

  1. 移行先ドメインからフォレスト外部のアカウント ドメインに対して必要な信頼をすべて確立する。 このシナリオは前述のシナリオと異なり、リソース ドメインを移行先のフォレストにしようとするものであり、少なくともしばらくの間アカウント ドメインはフォレストの外部に留まります。ただし原則的な手順は同じであるため、リソース アクセスを維持するために移行先ドメインからアカウント ドメインに対して信頼を確立する必要があります。

  2. この活動では、リソース ドメインからアカウント ドメインに対して現時点でどの信頼が存在しているかを、NETDOM を使用して照会します。

    NETDOM で得られた出力は、移行先ドメインからアカウント ドメインに対して既に存在している信頼と比較できます。まだ存在していない信頼があれば NETDOM を使用して確立できます。

    すべての共有ローカル グループのクローンを作成する。 既に説明したように、共有ローカル グループのスコープは作成元のドメインの内部だけであり、そのドメイン内の DC 間だけで共有されます。このシナリオでは、すべての DC を直ちに移行先ドメインに移動する必要はありません。このため、DC とリソースが移行元と移行先の各ドメイン間で分離されている間もリソース アクセスを維持できるように、ClonePrincipal を使用して共有ローカル グループのクローンを移行先ドメインに作成することが必要になります。

    アプリケーション サーバーをメンバ サーバーに降格する。 すべての共有ローカル グループのクローンを作成したら、移行先の OU 内でアプリケーション サーバーをメンバ サーバーに変換する作業を開始できます。

    • BDC のアップグレード方法には現在いくつかの制限事項があります。その 1 つとして、PDC をあらかじめアップグレードしておかない限り、BDC をアップグレードしてメンバ サーバーに降格することはできません。この問題は現在 Windows 2000 RTM に向けて調査中です。一方、BDC のアップグレードと降格には次の 2 つの方法があります。

      可能であれば、リソース ドメインの PDC を Windows 2000 にアップグレードし、移行期間中はドメインを混在モードで稼働することをお勧めします。この状態ならば、降格を目的として個々の BDC をアップグレードできます。

    • BDC のアップグレードでは、アップグレードのたびに DCPROMO が起動され、BDC を Windows 2000 ドメイン内で複製にするか、またはドメイン内でメンバ サーバーにするかのどちらかを選択します。後者を選択した場合は、コンピュータがリソース ドメイン内でメンバ サーバーになります。

      PDC のアップグレードが不可能または困難な場合は、アップグレードのたびに BDC をオフラインにしてそれを PDC に昇格する必要があります。BDC を PDC に昇格すると Windows 2000 へのアップグレードが可能になり、クローンの Windows 2000 混在モード ドメイン内でオフラインの DC、つまり PDC を効果的に作成できます。PDC のアップグレードが完了してオフラインにしたら、DCPROMO を実行して PDC をメンバ サーバーに降格し、移行先ドメインに連結できます。

  3. メンバ サーバー ( 以前に BDC だったものも含む ) とワークステーションを移動する。 この手順では、移動しようとするメンバ サーバーまたはワークステーションの移行先ドメイン OU 内におけるコンピュータ アカウントを、NETDOM を使用して作成し、コンピュータを移行先ドメインに連結できます。

  4. 移行元ドメインの役割を解除する。 すべてのユーザーとコンピュータを移行先フォレストに永続的に移動したら、最後の作業として移行元ドメインの役割を解除します。これには、移行元ドメインの BDC の電源をオフにしてシステムから除外し、最後に移行元ドメインの PDCの電源をオフにしてシステムから除外します。

これらの DC を新しいフォレストに再割り当てしようとしている場合は、それらを Windows 2000 にアップグレードした後、DC に昇格するか、または既に説明したようにメンバ サーバーとしてそのままにしておくことができます。

このシナリオでは、BDC をメンバ サーバーに降格した時点で、できるだけ速やかに移行先ドメインに移動してください。ドメインをネイティブ モードにして共有ローカル グループをドメイン ローカル グループに変換するまで、これらのグループを通じてアクセスできるリソースは、メンバ サーバー上では利用できなくなります。

mignt10

図 10: リソース ドメインの Windows 2000 OU への統合

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

決定事項のチェックリスト

この節では、移行の主要な概念を既に理解しているものとして、移行の全般的な流れを決定する際の決定事項について説明します。

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

アップグレードに関する決定事項

  1. アップグレードが組織にとって適切か。

    次の条件の一部または全てが当てはまれば、適切であるといえます。

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

    • 現在のドメイン構造にほぼ満足しており、2 段階の移行を実行できる。つまり、Windows 2000 へのアップグレードが可能であり、それから再構築を実行して問題を解決できる。

    • 実稼動環境に影響を与えることなく移行を管理できると感じている。

  2. どのような順序でアップグレードを行うべきか。

    DC のアップグレードか、またはドメインのアップグレードかによって順序は異なります。

  3. どのような順序で DC をアップグレードすべきか

    ドメイン内部でのアップグレードの順序が明らかであれば、最初に PDC をアップグレードする必要があります。しかし、たとえばドメインのアップグレードのために LMRepl を使用して PDC をエクスポート ディレクトリのホストとするなど、影響の可能性についても留意しておいてください。このような場合はエクスポート ディレクトリのホストを再設定してから PDC をアップグレードすることが必要です。

  4. どのような順序でドメインをアップグレードすべきか。

    一般にはアカウント ドメインを最初にアップグレードするほうが、管理の容易さや委任機能などをすばやく実現 ("先手必勝") できるという点で多くの利点があります。
    次に、リソース ドメインをアップグレードします。

  5. どのような順序でサーバーとワークステーションをアップグレードすべきか。

    サーバーとワークステーションは、Windows 2000 インフラの有無に関係なくいつでもアップグレードできます。
    メンバ サーバーについては、Windows NT RAS サーバーを使用できるように Active Directory のセキュリティ機能を緩めるとセキュリティ ポリシーが損なわれると判断される場合は、先にアップグレードしてください。
    LMRepl を使用してドメイン内部でスクリプトを複製しようとする場合は、エクスポート ディレクトリのホストとなっているサーバーを最後にアップグレードしてください。

  6. いつネイティブ モードに切り替えるべきか

    ディレクトリのスケーラビリティの向上、ユニバーサル グループやドメイン ローカル グループ、グループの入れ子など、Windows 2000 の機能をフルに活用できるように、できるだけ速やかにネイティブ モードへの切り替えを行ってください。
    ネイティブ モードへの切り替えは、ドメイン内のすべての DC のアップグレードが完了しない限り実行できません。

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

再構築に関する決定事項

  1. 再構築の必要があるか。

    次の条件の一部またはすべてが当てはまれば、必要といえます。

    • 現在のドメイン構造にほぼ満足しており、2 段階の移行を実行できる。つまり、Windows 2000 へのアップグレードが可能であり、それから再構築を実行して問題を解決できる。

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

    • 実稼動環境に影響を与えることなく移行を管理することができないと感じている。

  2. いつ再構築すべきか

この答えは、再構築の理由 (上のどの条件に当てはまるか) によってかなり異なります。

2 段階の移行によって移行の必要条件を解決できる場合は、アップグレード後に再構築してください。

現在のドメイン構造が何らかの理由で修復困難であるか、または実稼動環境への影響を回避できない場合は、始めから再構築を行ってください。

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

まとめ

Windows NT 4.0 から Windows 2000 Active Directory への移行は、アップグレード、または再構築によって達成できます。

Microsoft では、危険性の少ない移行方法をドメインのアップグレードという形式で提供しています。これらの方法は顧客が望んでいる移行の必要条件のすべてに対応していると思われます。Microsoft では顧客からのフィードバックに応えるため、移行の初期段階でも実行でき、買収や吸収合併などの企業活動にも対応できるよう移行後に実行することも可能な、ドメイン再構築用の優れたツールの提供に力を注いでいます。その最初のステップとなるのが、Microsoft 移行ツールと基本ユーティリティです。

Microsoft が提供するツールやユーティリティは、全体の中のほんの一部にすぎません。この分野では、多くの顧客が ISV のツール ベンダと緊密に協力することが予想され、使い慣れているツールをそのまま使用したいという要望が強いと思われます。Microsoft は ISV 各社と協力して、彼らのドメイン再構築用ツールでも SIDhistory やクローン化操作などの機能を利用できるように働きかけています。

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

詳細情報

Windows NT Server の最新情報については、Microsoft TechNet、または (https://www.microsoft.com/japan/products/ntserver/) などのWeb サイトを参照してください。

© 1999 Microsoft Corporation. All right reserved.

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

本書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

Microsoft、Active Desktop、BackOffice、BackOffice ロゴ、MSN、Windows、および Windows NT は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名および製品名は、各社の商標および登録商標です。

Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399 USA

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