【AD DS】AD データベースの複製の詳細な仕組みについて

  • 2023年5月2日
  • 2023年5月4日
  • AD DS

Active Directory ドメイン サービスでは、組織内のユーザーやリソースなどのデータをドメイン コントローラーで管理しています。ドメインには複数のドメイン コントローラーを構築することができ、全てのドメイン コントローラーで同じデータを保持している必要があります。

そのため、ドメイン コントローラー間でAD データベース内のデータを複製し、全てのドメイン コントローラーが同じデータを保持しています。全てのドメイン コントローラーがデータの変更を受け付けることができる「マルチマスター レプリケーション」の仕組みで複製しています。

AD データベースの基本的な複製の仕組みについては、以下の記事で紹介しています。

あわせて読みたい!

Active Directory ドメイン サービスでは、組織内のユーザーやリソースなどのデータをドメイン コントローラーで管理しています。ドメインには複数のドメイン コントローラーを構築することができ、全てのドメイン コントローラーで同じ[…]

今回は、AD データベースの複製における、内部の詳細な仕組みについて紹介します。

 

AD データベースの複製

AD データベースの複製とは?

ドメイン コントローラーでは、ユーザーやグループ、コンピューター アカウントなど、ドメインの管理に必要な各種オブジェクトの情報を AD データベースで管理しています。ドメイン内では複数のドメイン コントローラーを構築することができ、ドメイン コントローラー間でデータを複製して、全てのドメイン コントローラーの AD データベースで同じデータを保持しています。

ドメイン コントローラーでは AD データベースの複製に「マルチマスター レプリケーション」で行われます。マルチマスター レプリケーションとは、どのドメイン コントローラーでもデータを更新できる仕組みのことです。

全てのドメイン コントローラーにて、AD データベースのデータを更新することができ、ドメイン コントローラー動詞で更新された複製しあっています。複数のドメイン コントローラーで各自にデータを更新しても、不整合が生じないようにデータを複製する仕組みが用意されています。今回は、AD データベースでのデータが更新された時に、ドメイン コントローラー間でのデータの複製の仕組みについて紹介します。

 

AD データベースの複製に関連用語

AD データベースの仕組みを紹介するために、AD データベースのデータの管理や複製に関連する用語について紹介します。

Naming Context
Naming Context (名前付きコンテキスト) とは、AD データベースのパーティションのことを意味しています。

AD データベースは「パーティション」と呼ばれる単位で、データの格納領域が区切られています。既定では、「ドメイン パーティション」、「構成パーティション」、「スキーマ パーティション」などのパーティションが存在します。パーティションごとに複製範囲となるドメイン コントローラーが異なるため、各ドメイン コントローラーが複製される対象の Naming Context を把握しておく必要があります。

 

USN (Update Sequence Number)
USN (Update Sequence Number) とは、ドメイン コントローラーの AD データベースの更新状態を管理する番号のことです。USN は各ドメイン コントローラーごとに保持しており、64 bit の数字となっています。USN は、AD データベースで管理しているデータが更新されると、数字が繰り上がります。データの更新とは、ドメイン コントローラー独自での更新、また複製による更新のいずれも USN の数字の繰上りの対象となります。

 

High watermark
各ドメイン コントローラー上に保持されるテーブルで、複製対象のパーティションごとに High Watermark のテーブルを保持しています。High Watermark のテーブルには、全ての複製パートナーの一覧と、自身が認識している複製パートナーの USN の最大値を管理しています。USN は、独自の複製、更新に関わらず、最新の更新の USN となります。

 

Up-to-Dateness Vector
各ドメイン コントローラー上に保持されるテーブルで、複製対象のパーティションごとに Up-to-Datenaess Vector のテーブルを保持しています。Up-to-Datenaess Vector のテーブルには、Originating DC と Originating USN の最大値を管理しています。
余分な複製を抑止するために、複製データを送信する際に「どのドメイン コントローラーで更新が行われたか」をふまえて判断します。

 

DSA GUID
DSA GUID とは、各ドメイン コントローラーを識別する ID です。

 

Invocation ID
Invocation ID とは、各ドメイン コントローラーの AD データベースに割り当てられている ID です。Invocation ID は DSA 起動 ID や Database GUID とも呼ばれます。Windows Server バックアップなど、Active Directory をサポートしているバックアップ ツールでドメイン コントローラーをリストアした後には、 AD データベースの Invocation ID の値は変更され、他のドメイン コントローラーに通知されます。

 

Tombstone
Tombstone とは、AD データベースにて廃棄されたデータのことです。AD データベースでは、オブジェクトが削除されると、すぐにオブジェクトのデータが AD データベースから削除されるのではなく、オブジェクトの isDeleted 属性の値が True となって隠しコンテナに移動されます。AD には Tombstone Lifetime という廃棄されたデータの保存期間が設定されており、Tombstone Lifetime が過ぎたら完全にデータが削除されます。

 

 

AD データベースの複製の特徴

ドメイン コントローラー間での AD データベースの複製における特性は以下の通りです。

  • マルチマスター レプリケーション
    全てのドメイン コントローラーにてオブジェクトの更新ができます(RODC を除く)
    スキーマの情報の更新については、スキーマ マスターの役割をもつドメイン コントローラーのみが更新できます

  • プル複製
    ドメイン コントローラーにてオブジェクトの更新が発生すると、レプリケーション パートナーのドメイン コントローラーに通知し、通知を受けたドメイン コントローラーが Pull してデータを複製します

  • Strore-and-forward レプリケーション
    レプリケーション パートナーからの変更を保存し、その変更を別のドメイン コントローラーに送信します。そのため、データの変更が発生したドメイン コントローラーが全てのドメイン コントローラーとデータの複製をする必要はありません。

  • State-based レプリケーション
    AD データベースの現在の状態と、複製元の変更部分との差分の複製を行います。

 

AD データベースの複製の流れ

AD データベースでの複製では、(1) 全てのドメイン コントローラーにてデータを更新することができる、(2) 複製の処理においては、現在のデータの状態から差分複製を行う、という特徴があります。全てのドメイン コントローラーでもデータを更新することができつつ、相互に複製を行った後に、各ドメイン コントローラーにてデータの整合性を保てるように、データの更新状態の管理には USN を利用しています。USN は AD データベースの更新状態のバージョンを示すものですが、AD オブジェクトやオブジェクトの各属性でも USN に関する情報を管理しています。

 

AD オブジェクトの USN 情報

usnCreated 属性 オブジェクトが作成された時の USN
usnChanged 属性

オブジェクトが変更された時の USN

 

AD オブジェクトの属性の USN 情報

Local USN ローカルの USN 
Version 属性のバージョン
Originating Time オブジェクトの作成もしくは変更を行った DC での作成/変更の日時
Originating DC オブジェクトの作成もしくは変更を行った DC
Originating USN オブジェクトの作成もしくは変更を行った DC の USN

 

AD データベースでの複製の処理の流れは以下の通りです。

  1. AD オブジェクトの作成/更新
  2. レプリケーション パートナーに変更を通知
  3. Pull 複製
  4. USN の更新

AD データベースでの複製の動作について、2 台のドメイン コントローラー間で、AD オブジェクトの新規作成、また属性の変更した場合を例にして紹介します。

① DC01 にて AD オブジェクトを新規作成

AD データベースの複製の処理は、ドメイン コントローラーにて、AD オブジェクトの新規作成や更新など、AD オブジェクトの更新が行われたタイミングにて開始されます。

DC01 にて、nekomaru というユーザー オブジェクトを新規作成したとします。ユーザー オブジェクトを新規作成すると、AD データベース内のデータが変更されたこととなるため、AD データベースの USN は 1 インクリメントします。新規作成されたユーザー オブジェクトの usnCreated 属性と usnChanged 属性には、インクリメントされた USN がセットされます。

また、新規作成したユーザー アカウントの各属性には、USN や作成時間に関する複製に必要なメタデータを保持します。Local USN と originating USN には、AD データベースの USN がセットされます。

 

② DC01 はレプリケーション パートナーの DC02 に変更を通知し、Pull 複製

DC01 にて AD データベースにてデータが変更されたため、レプリケーション パートナーの DC02 に対してデータの変更があったことを通知します。DC02 はデータの通知を受け取ったら、DC01 から更新情報を受け取り(= Pull 複製)、DC02 にも新しく作成したユーザー アカウントをコピーします。変更通知を受け取った後にデータ複製をすると、AD データベース内のデータが変更されたことになるため、AD データベースの USN は 1インクリメントします。コピーされたユーザー オブジェクトの usnCreated 属性と usnChanged 属性には、インクリメントされた USN がセットされます。

 

また、コピーされたユーザー アカウントの各属性の Local USN には AD データベースの USN がセットされます。originating Time や originating USN などのその他のメタデータには、コピー元のデータがそのままセットされます。

 

③ DC02 にて AD オブジェクトの属性値を変更

次に DC02 にて先ほどのユーザー アカウントの属性値を変更した場合のシナリオを考えます。

DC02 にて、ユーザーのパスワードを変更します。オブジェクトの属性値を変更すると、AD データベース内のデータが変更されたことになるため、AD データベースの USN は 1インクリメントします。また、オブジェクトのバージョンを管理する uSNChanged 属性にもインクリメントされた USN がセットされます。

ユーザー アカウントの各属性には、USN や作成時間に関する複製に必要なメタデータを保持されています。LocalUSN と Originating USN には、インクリメントされた USN がセットされ、originating Time には、ユーザーの属性値を変更した日時がセットされます。また、originating DC には、オブジェクトの変更が行われたドメイン コントローラーのホストがセットされ、Version も 1 インクリメントされます。

 

④ USN の更新

DC02 にて AD データベースにてデータが変更されたため、レプリケーション パートナーの DC02 に対してデータの変更があったことを通知します。DC01 はデータの通知を受け取ったら、DC02 から更新情報を受け取り(= Pull 複製)、DC01 にも変更された属性値が反映されます。変更通知を受け取った後にデータ複製をすると、AD データベース内のデータが変更されたことになるため、AD データベースの USN は 1インクリメントします。コピーされたユーザー オブジェクトの usnChanged 属性には、インクリメントされた USN がセットされます。

ユーザー アカウントの各属性には、USN や作成時間に関する複製に必要なメタデータを保持されています。LocalUSN と Originating USN には、インクリメントされた USN がセットされ、originating Time には、ユーザーの属性値を変更した日時がセットされます。また、originating DC には、オブジェクトの変更が行われたドメイン コントローラーのホストがセットされ、Version も 1 インクリメントされます。

 

repadmin /showobjmeta

AD オブジェクトの各属性には、複製に必要なメタデータが管理されています。AD オブジェクトの各属性のメタデータの情報は、repadmin /showobjmeta コマンドにて確認することができます。メタデータの情報から、オブジェクトの各属性の更新元のドメイン コントローラーや USN、更新日時などに関する情報を確認することができます。

    repadmin /showobjmeta <ドメイン コントローラーの名前> <オブジェクトの DN>

C:\>repadmin /showobjmeta  localhost  CN=user01,OU=MS,DC=test01,DC=local

29 個のエントリがあります。
ローカル USN 元の DSA 元の USN 元の日時 Ver 属性
============ =============== ========= ============= === =========
23805 Default-First-Site-Name\TEST01DC01 23805 2023-03-20 17:19:46 1 objectClass
23805 Default-First-Site-Name\TEST01DC01 23805 2023-03-20 17:19:46 1 cn
80736 Default-First-Site-Name\TEST01DC02 13479 2023-04-29 03:30:55 1 title
80736 Default-First-Site-Name\TEST01DC02 13478 2023-04-29 03:30:55 1 physicalDeliveryOfficeName
23805 Default-First-Site-Name\TEST01DC01 23805 2023-03-20 17:19:46 1 instanceType
23805 Default-First-Site-Name\TEST01DC01 23805 2023-03-20 17:19:46 1 whenCreated
23805 Default-First-Site-Name\TEST01DC01 23805 2023-03-20 17:19:46 1 displayName
79088 Default-First-Site-Name\TEST01DC01 79088 2023-04-28 03:15:08 1 department
23805 Default-First-Site-Name\TEST01DC01 23805 2023-03-20 17:19:46 1 nTSecurityDescriptor
23805 Default-First-Site-Name\TEST01DC01 23805 2023-03-20 17:19:46 1 name
23810 Default-First-Site-Name\TEST01DC01 23810 2023-03-20 17:19:46 4 userAccountControl
23806 Default-First-Site-Name\TEST01DC01 23806 2023-03-20 17:19:46 1 codePage
23806 Default-First-Site-Name\TEST01DC01 23806 2023-03-20 17:19:46 1 countryCode
23807 Default-First-Site-Name\TEST01DC01 23807 2023-03-20 17:19:46 2 dBCSPwd
23806 Default-First-Site-Name\TEST01DC01 23806 2023-03-20 17:19:46 1 logonHours
23807 Default-First-Site-Name\TEST01DC01 23807 2023-03-20 17:19:46 2 unicodePwd
23807 Default-First-Site-Name\TEST01DC01 23807 2023-03-20 17:19:46 2 ntPwdHistory
23807 Default-First-Site-Name\TEST01DC01 23807 2023-03-20 17:19:46 2 pwdLastSet
23806 Default-First-Site-Name\TEST01DC01 23806 2023-03-20 17:19:46 1 primaryGroupID
23808 Default-First-Site-Name\TEST01DC01 23808 2023-03-20 17:19:46 1 supplementalCredentials
(略)

 

 

差分複製の仕組み

ドメイン コントローラーでは、変更通知を受け取った後に通知元から Pull 複製しますが、その際のデータは差分複製(変更部分のみのデータを受領して複製)します。Pull 複製において、差分複製を行うための仕組みについても紹介します。

ドメイン コントローラーが 5 台ある環境(DC01 ~ DC05)で、DC02 で発生した変更を DC01 が複製する動作について説明します。

① 変更通知の送信

DC02 にて AD データベースにてデータが変更されたため、レプリケーション パートナーの DC01 に対してデータの変更があったことを通知します。

② 複製要求の送信

DC01 は変更通知を受け取ったら、複製する対象のデータを DC02 へ要求します。

データを要求する際に、複製する対象のパーティション、受取可能なデータ数に関する情報、また要求元の DC01 が保持する各ドメイン コントローラーの USN 情報(Highwater mark、Up-to-dateness vector)を送信します。

 

Highwater mark は、各パーティションの最新更新の USN となります。また、Up-to-dateness vector は各ドメイン コントローラーの最新の独自更新の USN となります。

 

③ 複製対象のデータを確認

DC02 は DC01 から複製するデータの要求を受け取ったら、要求に含まれる各情報を確認して、DC01 の AD データベースの最新の更新状態を確認します。自身の AD データベースと比較して、差分のデータが何かを確認します。

ドメイン コントローラーでは、AD データベースの各 USN ごとでの更新内容を保持しています。各 USN の更新内容ごとで、独自更新が発生したドメイン コントローラー名(Originating DC)、また、その USN(Originating USN) が保持されています。DC01 から送信されてきた、DC の AD データベースの更新情報を確認して、各ドメイン コントローラーの Up-to-dateness vector を確認して、どの更新情報を保持しているかを確認します。

 

上図の例の場合、DC02 の Highwater Mark は 2108 であるため、DC01 は DC02 の LocalUSN の 2108 までの更新は反映されていることとなります。そのため、DC02 の AD データベースの LocalUSN の 2109 以降の更新の内容を確認します。DC02 の USN 2109 ~ 2111 までは Originating USN より Up-to-dateness vector の方が数字が小さいため、DC01 の AD データベースはその情報を保持していないことになります。しかしながら、DC02 の USN 2112 については、Originating USN より Up-to-dateness vector の方が数字が大きいため、DC01 の AD データベースはその情報を保持していることになります。

 

④ 複製対象のデータを送信

DC02 にて、DC01 の更新要求に含まれる各情報を確認した結果、DC01 が保持していない USN の更新内容を送信します。

 

DC02 では確認の結果、LocalUSN の 2112 の情報は DC01 も保持しているため、複製のために USN 2109、2110、2111 の更新情報を送信します。DC01 は DC02 から更新情報を受け取ったら、AD データベースに更新情報を反映させます。また、更新情報を管理するメタデータも最新の状態に変更します。今回の複製により、DC02 の USN の 2112 までを更新したことになるため、DC02 の Highwatermark、Up-to-Dateness Vector は 2112 に更新します。また、今回の更新に DC05 で更新された情報も含まれているため、DC05 の Up-to-Dateness Vector も 395 に更新します。