Windows の管理

Active Directory レプリケーション ガイド

Laura E. Hunter

概要:

• Active Directory に移行する
• 整合性を維持する
• 競合の解決に対処する
• Windows Server 2008 での変更点

Windows 2000 Server と Active Directory が導入されるまで、多くの企業環境では、サーバー インフラストラクチャに Windows NT を使用して、ID やアクセスを管理していました。

Windows NT® 4.0 がリリースされる頃には、Windows NT は安定したネットワーク オペレーティング システム (NOS) になっていましたが、大規模な企業で展開することを考えた場合、多くの欠点がありました。

まず、Windows NT は、フラットな名前空間を使用してネットワーク リソースを格納していました。つまり、リソースを複数の小さなサブセットに分割したり、きめ細かな管理を構成したりすることはできませんでした。たとえば、マーケティング部門のリソースを格納する部門用のコンテナを構成したり、部門内のユーザーのパスワードのみを再設定できる権限を持つローカル管理者を構成したりすることはできませんでした。このため、Windows NT のセキュリティは、ほぼ "全か無" でした。管理タスクをデスクトップ サポート エンジニアに委任する必要がある場合、自分がそのタスクを実行する場合よりもはるかに強力な権限を与えなければならないことがほとんどでした。

また、Windows NT は、サイズが 40 MB を超えることが想定されていない、セキュリティ アカウント マネージャ (SAM) データベースにすべての情報を格納していました。使用中の SAM データベースがこの推奨最大サイズを超えた場合 (構成にもよりますが 25,000 ～ 40,000 個のオブジェクトを格納した時点でこのサイズに達します)、環境を複数のドメインに分割する必要があったため、ネットワークを管理する作業や、ユーザーにリソースへのアクセスを提供する作業が複雑になりました。各 NT ドメインには 1 台のプライマリ ドメイン コントローラ (PDC) が存在し、このコンピュータに SAM データベースの唯一の読み取りおよび書き込み可能なコピーが格納されていました。1 台以上のバックアップ ドメイン コントローラ (BDC) を展開してフォールト トレランスを確保することもできましたが、これらの BDC は読み取り専用であったため、書き込み操作を必要とする、ユーザーのパスワードの変更などの更新操作を実行することはできませんでした。

さらに、Windows NT は NetBIOS 名前解決を使用していました。これはブロードキャストに基づいた解決方法であるため、ユーザーがネットワーク リソースを (特に低速または使用率が高い WAN リンクを経由して) 参照すると、多くの場合、膨大な量のトラフィックが生成されました。

新しいモデルの登場

2000 年にリリースされた Windows® 2000 では、それまで提供されていた NOS 製品が一新されました。新しい NOS サービスである Active Directory® は、想像どおり Windows NT とは異なるものでした。Active Directory は、X.500 標準に基づいて構築されたため、フラットな名前空間が使用されなくなり、階層的な組織構造が提供されました。これにより、リソースを 1 つのドメイン内にある複数の組織単位に分類し、各 OU の管理をタスク レベルで委任できるようになりました。

Windows NT からのもう 1 つの大きな変更点は、マルチマスタ レプリケーションのモデルが新しくなったことです。Windows NT では 1 台の書き込み可能な PDC と、それに関連付けられた BDC が使用されていましたが、Active Directory では、各ドメイン コントローラが Active Directory データベースへの書き込みを実行できるようになりました。

しかし、大規模な環境や分散環境をサポートできる柔軟性が提供された一方で、Active Directory の整合性の維持という新たな課題も生まれました。John Smith と Jane Dow が、国内の離れた位置にあるそれぞれのオフィスで同じオブジェクトに変更を加えたときに、それらの変更が競合したらどうなるでしょうか。Active Directory のレプリケーション モデルでは、更新を環境内のすべてのドメイン コントローラに伝達する方法だけでなく、実質上どの場所からでも変更を加えることができるマルチマスタ レプリケーションで発生した競合に対処する方法も定義されています。

Active Directory レプリケーションのしくみ

この記事の例では、サイト内レプリケーションについてのみ説明します。基本的に、サイト内レプリケーションは変更をすばやく同じサイト内の DC にレプリケートすることを目的としており、変更通知を使用して実行されます。サイト内レプリケーションでは、DC1 でレプリケーションが必要な変更が発生したことを DC1 が DC2 に通知した後、DC2 がその変更を DC1 からプルします。同様に、DC2 で変更が発生したことを DC2 が DC1 に通知した場合、DC1 はその変更を DC2 からプルします。おわかりのように、Active Directory のすべてのレプリケーションは、プッシュ操作ではなくプル操作によって実行されます。

Active Directory には数十万または数百万個のオブジェクトが格納される可能性があるため、Active Directory データベースを名前付けコンテキストと呼ばれるセクションに分割する必要があります。各ドメイン コントローラにある Active Directory データベースのローカル コピーには、3 個以上の NC が格納されます。

スキーマ NC この NC は、フォレスト内の他のすべてのドメイン コントローラにレプリケートされます。この NC には、Active Directory 内のさまざまなオブジェクトのクラスと属性を定義する Active Directory スキーマに関する情報が格納されます。

構成 NC この NC も、フォレスト内の他のすべての DC にレプリケートされます。この NC には、Active Directory の物理的なレイアウトに関係するフォレスト全体の構成情報、および表示指定子とフォレスト全体の Active Directory クォータに関する情報が格納されます。

ドメイン NC この NC は、1 つの Active Directory ドメイン内の他のすべての DC にレプリケートされます。この NC には、特定の Active Directory ドメイン内に存在する実際のユーザー、グループ、コンピュータ、その他のオブジェクトなど、最もアクセス頻度の高い Active Directory データが格納されます。

各名前付けコンテキストは別々にレプリケートされるため、レプリケーション トラフィックが最適化されます。つまり、変更頻度が少ない NC (スキーマ NC など) がレプリケートされることによって、変更頻度が多い NC (ドメイン NC など) のレプリケーションに使用されるネットワーク帯域幅が狭くなることはありません。

ディレクトリの変更は、どの Active Directory DC からでも実行される可能性があるため、Active Directory レプリケーションは 2 種類の書き込み操作を追跡する必要があります。1 つは、特定の DC に直接変更が加えられたときに発生する、変更元の書き込みです。たとえば、DC1 に接続してユーザーのパスワードを変更した場合、DC1 ではその変更が変更元の書き込みと見なされます。Active Directory が追跡するもう 1 つの書き込み操作は、レプリケーション書き込みです。ご想像どおり、これは別のドメイン コントローラから変更がレプリケートされたときに発生します。DC1 で変更元の書き込みと見なされた変更は、DC2、DC3、およびドメイン内の他の DC にレプリケートされるときにはレプリケーション書き込みと見なされます。

Active Directory のドメイン コントローラでは、レプリケーション メタデータを使用して、ディレクトリに加えられた変更の転送が管理されます。つまり、Active Directory は、変更された実際のデータ ("人事部長" に変更された John Smith の説明など) をある DC から別の DC に転送するだけでなく、変更が発生した DC、変更が発生した時間、その他の重要な情報など、発生した変更に関する追加情報も転送します。DC は、これらの情報を使用して、レプリケーションを最も効率的な方法で管理できます。

まず、更新シーケンス番号 (USN) というレプリケーション メタデータについて説明します。各ドメイン コントローラは、そのドメイン コントローラに固有の USN を保持しています。その DC から Active Directory に変更が加えられると、DC の USN は 1 増加します。つまり、ある DC が午前 11 時に 1000 という USN を保持していて、午前 11 時 30 分にその USN が 1005 に変更されていた場合、その DC から Active Directory データベースに 5 回変更が加えられたことになります。USN にとって、変更の内容は重要ではありません。DC の USN は、5 個の異なるオブジェクトが変更、作成、または削除された場合でも、これらの操作のいくつかが数回ずつ実行されて合計 5 回になった場合でも、5 増加します。また、USN は、特定のドメイン コントローラの内部のみで使用されるデータであり、他の DC の USN と関連し合うことはありません。ドメイン内のある DC で午前 11 時 30 分に変更が発生し、このドメインに USN 1051 が割り当てられたとします。また、同じドメインの 2 番目の DC で、まったく同じ時刻に変更が発生し、このドメインに USN 5084 が割り当てられたとします。これら 2 つの DC は、ほぼ同じ時刻に発生した変更に対してまったく異なる USN を割り当てられていますが、このことは、これらの変更のレプリケーション方法とは無関係です。つまり、ある DC の更新シーケンス番号を他の DC と比較することによって、両者で発生した変更を比較することはできません。

DC の USN が 1 増加するのは、その DC で変更が発生したときだけではありません。Active Directory データベースへの変更は、変更元の書き込みまたはレプリケーション書き込みから構成されるということを思い出してください。ドメイン コントローラの更新シーケンス番号は、どちらの種類の書き込み操作が発生しても増加します。つまり、別の DC から変更がレプリケートされたときにも増加するということです。このため、各 DC には、どの変更が既にレプリケートされたかを追跡する方法が必要です。追跡する方法がなければ、レプリケーションが発生するたびに Active Directory データベース全体をネットワーク経由で送信することになります。このような状況を回避するために、各 Active Directory ドメイン コントローラは、レプリケーション パートナーである他のドメイン コントローラの警告を発生させるベクタ (HWMV : High Watermark Vector) の値を保持しています。各 DC は、リモート DC の名前が変更されたときや、リモート DC がディレクトリから削除されたときに問題が発生しないように、この HWMV をリモート DC のグローバル一意識別子 (GUID) と関連付けています。

まずは簡単な例で説明しましょう。contoso.com ドメインで 2 台のドメイン コントローラ dc1.contoso.com と dc2.contoso.com が構成されていたとします。contoso.com ドメインの DC は 2 台のみであるため、DC1 と DC2 の間でのみレプリケーションが発生します (この簡単な例で Active Directory レプリケーションのすべてのシナリオを説明することはできません。後ほどこの例を複雑にして、さらに詳しい説明を行います。)

この例では、DC1 の USN が 3000、DC2 の USN が 4500、およびこれら 2 つの DC が相互に最新の状態になっているとします。

段階 1: DC1 と DC2 の状態は相互に最新になっています。DC1 が保持している DC2 の HWMV は 4500、DC2 が保持している DC1 の HWMV は 3000 です (図 1 を参照)。

図 1** 2 台の DC の現在の状態 **

段階 2: 管理者が DC1 に新しいオブジェクトを作成し、これによって DC1 の USN が 3001 に増加します (図 2 を参照)。DC2 が保持している DC1 の HWMV が変更されていないことに注目してください。これは、DC1 が変更を保持していることをまだ DC2 に通知していないためです。

図 2** 新しいオブジェクトの追加 **

段階 3: DC1 が、変更を保持していることを DC2 に通知します。その後、DC2 が DC1 との間でレプリケーションを開始し、その変更を要求します。DC2 は、この要求の一部として、自身に格納されている DC1 の HWMV を DC1 に送信します (図 3 を参照)。

図 3** 変更の通知 **(画像を拡大するには、ここをクリックします)

段階 4: DC1 が、USN 3001 に対応する変更、つまり段階 2. で DC1 に作成されたオブジェクトを DC2 に送信します。DC2 は自身の USN を 4501、自身が保持している DC1 の HWMV を 3001 にそれぞれ更新します (図 4 を参照)。

図 4** 変更と更新 **(画像を拡大するには、ここをクリックします)

ここまでは順調ですね。しかし、ここで 1 つ問題があります。それは、DC2 で発生した変更を DC1 にレプリケートする必要があるということです。この変更が USN と HWMV のみであった場合、ここで DC2 は DC1 にアクセスし、DC1 が DC2 にレプリケートしたものと同じ変更を DC1 にレプリケートします。この結果、無限にレプリケーションが発生し続け、徐々に使用可能な帯域幅が狭くなります。この問題を解決するには、さらに何個かパズルのピースが必要です。その 1 つ目は、最新ベクタ (UTD ベクタまたは UTDV) です。

UTDV は、伝達をダンプするために使用されるレプリケーション メタデータです。つまり、同じ変更をネットワーク経由で何回もレプリケートすることによって帯域幅が無駄に使用されることを防ぐために、このデータが使用されます。各 DC は、特定の名前付けコンテキストの複製が格納された他のすべての DC の UTDV が記録されたテーブルを保持しています。ドメイン NC の場合、ドメイン内の各 DC は、ドメイン内のすべての DC の UTDV を保持します。構成 NC とスキーマ NC の場合、各 DC はフォレスト内のすべての DC の UTDV を保持します。UTDV テーブルは、各 DC がそれぞれのレプリケーション パートナーから受信した USN の最高値だけでなく、特定の NC をレプリケートしているすべての DC から受信した USN の最高値も追跡します。レプリケートされる各変更には、この追跡を実現する次の情報が含まれています。

• 変更をレプリケートしている DC の GUID。この変更は、変更元の書き込みまたはレプリケーション書き込みとしてレプリケートされています。
• 変更をレプリケートしている DC の USN。この変更は、変更元の書き込みまたはレプリケーション書き込みとしてレプリケートされています。
• 変更が発生した DC の GUID。この GUID が変更をレプリケートしている DC の GUID と一致する場合、この変更は変更元の書き込みとしてレプリケートされています。GUID が一致しない場合は、UTDV テーブルが使用されます。
• 変更が発生した DC の USN。この USN が変更をレプリケートしている DC の USN と一致する場合、この変更は変更元の書き込みとしてレプリケートされています。USN が一致しない場合は、UTDV テーブルが使用されます。

この処理をわかりやすく説明するために、上記の例の構成を複雑にし、3 番目のドメイン コントローラである DC3 を追加します。この場合、DC1、DC2、および DC3 は、すべてが相互にレプリケーション パートナーの関係にあります。つまり、DC1 の変更は DC2 と DC3、DC2 の変更は DC1 と DC3、DC3 の変更は DC1 と DC2 にそれぞれレプリケートされます。

段階 1: DC1、DC2、および DC3 は、すべて相互に最新の状態になっています。

段階 2: DC3 が変更元の書き込みを 1 回実行します。内容は、ユーザー アカウント jsmith のパスワードの再設定です。DC3 は、変更を保持していることを DC1 と DC2 に通知します。DC1 と DC2 は、変更元の書き込みを DC3 からプルした後、各自の HWMV テーブルと UTDV テーブルに格納されている DC3 の値を更新します (図 5 を参照)。

図 5** HWMV テーブルと UTDV テーブルの更新 **(画像を拡大するには、ここをクリックします)

段階 3: ここで、最新ベクタが使用されます。DC2 は、変更を保持していることを DC1 に通知します。次に DC1 は、DC2 に次の情報を送信することによって新しい変更を要求します。

• DC1 に格納されている DC2 の HWMV の値 (この場合は 4501)。
• DC1 の UTDV テーブル (図 6 を参照)。このテーブルには、DC1 が DC3 を含むすべての DC から受信した、変更元の USN の最高値が格納されています。

Figure 6 UTDV テーブル

DC2 は、4501 という HWMV に基づいて、該当する変更を DC1 にレプリケートしたことがないことを認識します (図 7 を参照)。

Figure 7 レプリケートが必要な変更

しかし、DC2 は、レプリケーションの開始前に DC1 から受信した UTDV テーブルに基づいて、DC1 はその変更を既に DC3 から受信しているため、実際にはその変更を必要としていないと判断します。ここで、DC1 は自身の HWMV テーブルに格納されている DC2 の値を更新して、増加した USN を反映します (図 8 を参照)。帯域幅を節約するために、実際のデータは送信されません。

図 8** 伝達のダンプ **(画像を拡大するには、ここをクリックします)

段階 4: この伝達のダンプは、DC2 が変更を保持していることを DC3 に通知した場合や、DC1 が変更を保持していることを DC2 と DC3 に通知した場合にも発生します。3 台の DC は、それぞれの HWMV テーブルに格納されている各レプリケーション パートナーの値を更新します (図 8 を参照) が、実際のデータは既に段階 2. で各 DC に転送されているため、再度ネットワーク経由で送信されることはありません。

マルチマスタ環境での競合解決

ここまでの例では、1 人の管理者が同時に 1 台の DC に変更を加えていたため、各変更が競合することもなく、問題は発生しませんでした。しかし実際には、このようなことはめったにありません。Active Directory オブジェクトは、ドメイン内のどのドメイン コントローラからでも更新される可能性があるため、2 人の管理者が 2 台の異なるドメイン コントローラから加えた変更が競合することも考えられます。Active Directory 環境で発生する可能性がある競合は 3 種類あり、解決方法もそれぞれ異なります。

プロパティの変更の競合 この競合は、2 人の管理者が、競合する方法で同じオブジェクトを更新した場合に発生します。たとえば、1 人の管理者があるユーザーの説明を "マーケティング" に設定し、異なる DC を管理している別の管理者がそのユーザーの説明を "販売およびマーケティング" に設定した場合などがあります。

作成した新しいオブジェクトの競合 この競合は、2 人の管理者が、同時に同じ名前のオブジェクトを作成した場合に発生します。たとえば、jsmith という名前のユーザーが 2 人同時に作成された場合などがあります。

削除されたコンテナ内に移動されたオブジェクトの競合 この競合が発生することはほとんどありません。この競合は、1 人の管理者がコンテナ内のオブジェクト (OU など) を作成または移動したのと同時に、異なる DC を管理している別の管理者がそのコンテナを削除した場合に発生します。

ここで、最初の 2 つの種類の競合を解決するために、主に競合の解決に使用される 2 つのレプリケーション メタデータを紹介します。バージョン ID の値は、オブジェクトの個々の属性に割り当てられています。初期値として、そのオブジェクトの作成時に 1 が割り当てられます。バージョン ID は、いずれかの DC が個々の属性に変更を加えると 1 増加します。このため、特定のユーザーの説明属性が既定値 (空または <not set> (未設定)) から "マーケティング部門" に変更された場合、説明属性のバージョン ID は 2 になります。その後説明が "販売およびマーケティング部門" に変更された場合、バージョン ID は 3 になります。バージョン ID は、これまでに紹介した他のメタデータと共に、すべてのレプリケーション エントリに格納されています。

バージョン ID は、レプリケーション トラフィックの削減にも使用できます。たとえば、DC2 の管理者が (入力ミスなどにより) 1 つの属性に複数回変更を加え、その結果 DC2 でバージョン ID 2、3、4、および 5 に対応する変更元の書き込みが発生した場合、最新のバージョン ID である 5 に対応する書き込みのみがレプリケートされます。どのような場合でも古い変更はすべて上書きされるため、この属性を使用することにより、複雑な作業を行うことなく、無駄に帯域幅を使用するトラフィックを削減できます。

Active Directory に加える変更には、競合の解決に使用されるもう 1 つのレプリケーション メタデータであるタイムスタンプが含まれています。このデータは、変更が加えられた日時を示しています。

タイムスタンプ属性は、Active Directory レプリケーションの状態を事前に確認する方法としても使用されます。ある DC が特定の DC から最近のタイムスタンプの変更を受け取っていない場合、その DC で問題が発生している可能性があることを示すエラー メッセージが生成されます。

では、これら 2 つの属性はどのようにして競合の解決に使用されるのでしょうか。競合の種類ごとに見ていきましょう。

プロパティの変更の競合を解決する

contoso.com ドメインのユーザー オブジェクト jsmith の例で考えてみましょう。まず、DC1 の管理者が jsmith の説明を "マーケティング" に変更します。ほぼ同時に、DC3 の管理者がこのユーザーの説明を "販売およびマーケティング" に変更します。ここで、jsmith の説明に関する DC1 と DC3 の情報が比較されます (図 9 を参照)。

Figure 9 ほぼ同時に発生した変更

DC2 は、両方の変更を同時に受信した場合、どちらが "優先度の高い" 変更であるかを特定する必要があります。以下に、競合の解決に使用される条件を、適用される順序に従って示します。

1. バージョン ID が大きい方の変更が "優先度の高い" 変更として反映され、"優先度の低い" 変更は上書きされます。この場合、どちらのレコードのバージョン ID も 2 であるため、2 番目の条件で比較する必要があります。
2. レコードのバージョン ID が等しい場合、タイムスタンプの時刻が遅い方の変更が優先度の高い変更として反映され、優先度の低い変更は上書きされます。この場合、DC3 で発生した変更元の書き込みのタイムスタンプの時刻の方が遅いため、jsmith の説明は "販売およびマーケティング" に設定されます。このようなことはめったにありませんが、バージョン ID とタイムスタンプが両方とも等しい場合、確実に優先度を決定できる 3 番目の条件が必要です。
3. バージョン ID とタイムスタンプが両方とも等しい場合、DC から生成されたときに割り当てられた GUID の番号が小さい方の書き込みが優先され、GUID の番号が大きい方の書き込みは上書きされます。このため、DC1 の GUID が 1234567890、DC3 の GUID が 2345678901 である場合、DC1 で発生した変更元の書き込みが優先されます。

タイムスタンプを 1 つ目の条件にした方が理にかなっていると思うかもしれませんが、理屈はそれほど単純ではありません。Active Directory の競合を解決するための 1 つ目の条件としてタイムスタンプを使用した場合、悪意のある管理者は、管理している DC の時刻を遅らせるだけで、タイムスタンプを比較したときにその DC の変更が常に優先されるため、自分が加えた変更を伝達することができます。

作成した新しいオブジェクトの競合を解決する

同時に 2 つのオブジェクトが作成された場合、Active Directory は、既に説明した 3 つの条件を使用して、優先度の高いオブジェクトを決定します。ただし、上記の場合とは異なり、優先度の低いオブジェクトは上書きされず、オブジェクト名が変更されます。変更後の名前には CNF (競合したオブジェクトを表します) という文字列が使用され、その後にコロンと優先度の低いオブジェクトの GUID が続きます。これにより、管理者は保持する必要があるオブジェクトと削除する必要があるオブジェクトを、さらに体系的に決定できるようになります。

削除されたコンテナ内に移動されたオブジェクトの競合を解決する

既に説明したとおり、削除されたコンテナ内に移動されたオブジェクトの競合が発生することはほとんどありません。この競合は 2 つのシナリオのいずれかでのみ発生します。1 つは、ある DC の管理者が "トレーニング" OU などの特定のコンテナ内にオブジェクトを作成し、同時に別の DC の管理者が "トレーニング" OU を削除した場合です。もう 1 つは、ある DC の管理者がコンテナ内にオブジェクトを移動したのと同時に、別の DC の管理者がそのコンテナを削除した場合です。

この場合の解決方法は非常に単純です。Active Directory は、"不明な" オブジェクトを、Active Directory 内の特殊なコンテナである LostAndFound コンテナに移動します。これは不明なオブジェクトを格納するためのコンテナであり、各 Active Directory ドメインのルートにあります。contoso.com ドメインの場合、LostAndFound コンテナは LDAP://cn=LostAndFound,dc=contoso,dc=com という LDAP パスにあります。Active Directory ユーザーとコンピュータ スナップインを起動したときに LostAndFound コンテナが表示されない場合は、[表示] メニューの [拡張機能] をクリックします。

USN のロールバックを回避する

Active Directory 環境で発生する最悪の状況の 1 つは、その原因と回避策を理解すれば最も簡単に回避できる状況でもあります。USN のロールバックは、ネットワーク上で発生しているレプリケーションが完全に停止する可能性のあるエラー状態です。この状態は、ドメイン コントローラを長時間オフラインにしてからオンラインに戻した場合や、サポートされていない方法を使用してドメイン コントローラを復元した場合などに発生します。

USN のロールバックが発生する根本的な原因は、Active Directory マルチマスタ環境でオブジェクトの削除が処理される方法と関係しています。ある DC でオブジェクトを削除したが、完全には削除していない場合、そのオブジェクトは廃棄済みオブジェクトとして他の DC にレプリケートされ、削除されたことがそれらの DC に通知されます。廃棄済みオブジェクトへの変更で最も顕著なのは、isDeleted 属性が TRUE に設定されることです。廃棄済みオブジェクトに変更された場合、サイズを減らすために、ユーザー オブジェクトの説明、個人情報、グループ メンバシップなど、そのオブジェクトに格納されているほとんどの値が削除されます。この処理の詳細については、Gil Kirkpatrick の記事「Active Directory の廃棄済みオブジェクトを復元する」(technetmagazine.com/issues/2007/09) を参照してください。

USN のロールバックは、これらの廃棄済みオブジェクトが永久に存在し続けないことが原因で発生する場合があります。これらは、既定で 60 日後または 180 日後に Active Directory データベースから完全に削除されます (この期間は、最初に Active Directory 環境を作成したときに実行していた Windows Server® のバージョンによって異なります)。この 60 日または 180 日の期間を廃棄済みオブジェクトの有効期間といいます。この期間中に、すべてのドメイン コントローラを 1 回以上レプリケートする必要があります。1 回もレプリケートされなかった場合、問題はないが有用性もないドメイン コントローラと見なされ、その結果 USN のロールバックが発生する可能性があります。基本的に USN のロールバックは、ドメイン コントローラが完全に古くなり、1 つ以上の廃棄済みオブジェクトが完全に削除されたことによって、最新の完全な Active Directory データベースのローカル コピーを他の DC にコピーできなくなったときに発生します。この問題を回避するには、オフライン期間が廃棄済みオブジェクトの有効期間を過ぎたドメイン コントローラをオンラインに戻さないようにする必要があります。代わりに、マイクロソフト サポート技術情報の資料 216498 (support.microsoft.com/kb/216498) の手順に従って Active Directory から古い DC のメタデータを削除した後、ドメイン コントローラを最初から再構築してください。

USN のロールバックが発生する 2 つ目のシナリオは、サポートされていない方法でドメイン コントローラが復元された場合です。最もよくあるのは、ディスク複製ツールやディスク イメージング ツールを使用した場合です。このシナリオでロールバックが発生した場合、復元された Active Directory データベースは、自身の状態が "戻された" ことを認識しません。これは、復元方法が Active Directory に対応していなかったためです。Windows 2000 と Windows Server 2003 の最初のリリースでは USN のロールバックを検出するのは困難でしたが、Windows Server 2003 SP1 (および今後リリースされる Windows Server 2008) には、DC が適切に復元されなかったことを検出するコントロールが組み込まれています。これらの新しい OS のバージョンでは、DC がイベント ID 1115、2095、2103、および 2110 をディレクトリ サービス イベント ログに記録します。これらのイベントの内容と、Windows Server 2003 で USN のロールバックから DC を回復させる方法については、サポート技術情報の資料 875495 (support.microsoft.com/kb/875495) を参照してください。Windows 2000 で USN のロールバックに対処する方法については、サポート技術情報の資料 885875 (support.microsoft.com/kb/885875) を参照してください。

Windows Server 2008 で更新されたマルチマスタ モデル

間もなくリリースされる Windows Server 2008 では、読み取り専用ドメイン コントローラ (RODC) の導入によって、マルチマスタ モデルが若干変更されます。RODC は、主にブランチ オフィスへの展開を行う場合や、特定の場所に専任の IT スタッフを配置しておらず、特定の DC の整合性を維持するために追加の作業を行う必要があるシナリオで使用することを目的としています。RODC の技術的な詳細をすべて説明するには 1 つの記事全体が必要になるため、ここでは知っておいたほうがよい重要な点のみを概説します。

その名前が示すとおり、RODC に格納された Active Directory データベースのコピーは読み取り専用です。RODC に接続すると、必要なほとんどの情報を読み取ることができますが、RODC への書き込み操作を実行することはできません。

また、RODC は出力方向のレプリケーションを実行しません。これは、ここまで説明してきたマルチマスタ レプリケーション モデルからの抜本的な変更です。RODC は、他の書き込み可能な Windows Server 2008 DC から入力方向のレプリケーションを受信しますが、他の DC に情報をレプリケートすることはありません。これにより、悪意のあるユーザーが何らかの方法で RODC から Active Directory を変更できた場合でも、それらの変更が環境内の他の部分に伝達されないため、セキュリティが強化されます。

さらに、皆さんにとって最も興味深いことかもしれませんが、RODC は既定でユーザーのパスワードをレプリケートしません。Active Directory データベースの入力方向のレプリケーションが、書き込み可能な DC から RODC に対して実行された場合、すべてのユーザー オブジェクトのパスワードに関する情報はレプリケートされません。これにより、DC が盗まれた場合でも、DC のハード ドライブにパスワードの情報は格納されていないため、ブランチ オフィスのセキュリティが強化されます。全体として見ると、最初に考案されたマルチマスタ Active Directory レプリケーションにこのような変更が加えられた新しいモデルでは、ブランチ オフィスや他の遠隔地にあるドメイン コントローラのセキュリティが大幅に強化されました。

Laura E. Hunter は、Windows Server のネットワークの分野で、Microsoft MVP を 4 回受賞しています。彼女は IT 業界に携わって 10 年のベテランであり、『詳説 Active Directory 第 2 版』(O'Reilly、2006 年) をはじめ、個人または共同で、IT 関連の書籍、記事、ホワイト ペーパーなどを多数執筆しています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.