複数のドメインコントローラー（DC）がある環境では、片方のDCで行った変更が、もう片方のDCに反映されるまでに必ずタイムラグがあります。この仕組みを知らないと、「さっき変更したのに反映されていない」という問い合わせに正しく対応できません。
ADレプリケーションとは？
複数のDC間で、ADのデータベース（ユーザー・グループ・パスワードなどの情報）を同期し続ける仕組みです。
レプリケーション（Replication） 複数のドメインコントローラーが持つADデータベースの内容を、互いに同期して一致させる仕組み。
マルチマスター方式
ADのレプリケーションは「マルチマスター方式」を採用しています。
マルチマスターレプリケーション（Multi-Master Replication） 特定の1台だけが変更を受け付ける「マスター」ではなく、どのDCで変更を行っても、その変更が他のDCへ伝播していく仕組み。
これは大きな特徴であり、メリットでもあります。仮に1台のDCが停止していても、他のDCが変更処理を受け付け続けられるため、単一障害点（Single Point of Failure）が生まれにくいという点です。「マスターDCが落ちたら全社が変更操作を受け付けられなくなる」という事態を避けられる設計です。
サイト内とサイト間で速度が違う
一方で、変更が全DCへ届くまでの速度は一律ではありません。DCの配置（同じサイト内か、サイト間か）によって大きく変わります。
| サイト内レプリケーション | サイト間レプリケーション | |
|---|---|---|
| 対象 | 同じサイト（≒同じ拠点・LAN）にあるDC同士 | 異なるサイト（≒拠点・WAN越し）にあるDC同士 |
| 同期方式 | 変更通知ベース（即時性が高い） | スケジュールベース |
| 標準的な反映速度 | 数秒〜数十秒程度 | 既定で180分（3時間）間隔 |
サイト（Site） ADにおける、ネットワーク的にまとまった拠点の単位。物理的な拠点（東京本社・大阪支店、等）に対応させて設計するのが一般的。
東京本社と大阪支店にそれぞれDCがある環境で、大阪側のDCで行った変更が東京側のDCに反映されるまで、既定では最大3時間かかることがある、ということです。
パスワードだけは特別扱い
このタイムラグの仕組みには、1つ例外があります。パスワード変更です。
PDCエミュレータ（PDC Emulator） FSMOロールの1つ。パスワード変更処理は、通常のレプリケーションを待たず、PDCエミュレータの役割を持つDCへ優先的に即時転送される。認証に失敗した場合、そのDCがPDCエミュレータに問い合わせて再確認する仕組みもある。
パスワードだけは「即時反映」を目指した特別なルートが用意されているわけです。とはいえ万能ではなく、ネットワーク分断時やPDCエミュレータ自体に到達できない場合はこの仕組みも機能しません。
反映タイムラグと整合性のズレ
ここがADレプリケーションの一番の「クセ」です。パスワード以外の変更（グループメンバーシップの追加、OUの移動など）は、通常のレプリケーション間隔に従うため、サイト間では最大180分ズレたままの状態が発生し得ます。
「パスワード変更したのにログインできない」という現象も、多くはこの仕組みが原因です。大阪のDCでパスワードを変更した直後、東京のDCにまだ変更が伝わっていない状態で東京のDCに対して認証を試みると、古い情報のまま判定されて失敗する、というケースです。障害ではなく、レプリケーションの仕組み上正常に起こり得る現象です。
レプリケーション権限は攻撃にも使われる
レプリケーションの仕組みは、便利さの裏で攻撃にも悪用される対象になっています。守る側として、ここは知っておく必要があります。
DCが他のDCからデータを複製できるのは、「Replicating Directory Changes」「Replicating Directory Changes All」という拡張権限を持っているためです。この権限は本来DCだけが持つべきものですが、もしDC以外のアカウントにこの権限が付与されていた場合、そのアカウントは正規のDCになりすまして、ADのデータ（パスワードハッシュを含む）を丸ごと引き出せてしまいます。 これが「DCSync」と呼ばれる攻撃手法です。
DCSync レプリケーション権限を悪用し、正規のDCになりすましてAD内の認証情報を取得する攻撃手法。ドメインコントローラーそのものを乗っ取らなくても、この権限さえ持つアカウントを奪取できれば成立してしまう。
さらに一歩進んだ手法として、攻撃者が偽のDCオブジェクトを登録し、通常の監査ログに残りにくい形で不正な変更をAD内に注入するという手口も知られています。レプリケーションという「信頼された経路」を悪用する点が厄介なところです。
守る側でできること
- 「Replicating Directory Changes」「Replicating Directory Changes All」権限を持つアカウントを定期的に棚卸しする。 正規のDC以外にこの権限が付与されていないか確認します。
- イベントID 4662（ディレクトリサービスのアクセス）を監視する。 DCSyncの痕跡はこのイベントIDに残ります。具体的な検知パターンについては「Kerberoasting・DCSyncの仕組みと防御策」で詳しく解説しています。
- 想定外のレプリケーションパートナーが増えていないか確認する。
repadmin /replsummaryは、平時の運用確認だけでなく、この異常検知の観点でも定期的に見る価値があります。
「レプリケーションは便利な仕組みであると同時に、悪用されると強力な攻撃経路にもなる」という二面性を理解しておくと、日々の運用確認にも自然とセキュリティの視点が入るようになります。
状態を確認する方法
repadminコマンドを使います。
repadmin /showrepl特定のDCのレプリケーション状態（最終同期時刻・エラーの有無）を表示します。
repadmin /replsummaryフォレスト内の全DCのレプリケーション状況を、サマリーで一覧表示します。エラーが出ているDCを素早く見つけたいときに便利です。
今すぐ同期させる方法
緊急時には手動で強制同期をかけられます。
repadmin /syncall /AdeP指定したDCを起点に、フォレスト内のレプリケーションパートナーへ即座に同期を強制します。「さっきの変更を今すぐ全DCに反映させたい」という場面で使います。
現場で確認しておくべきこと
自分の環境が複数サイト構成の場合、サイト間レプリケーションの間隔が何分に設定されているか確認してください。
既定の180分のままで運用しているのか、それとも短縮設定にしているのかによって、「反映されるまでどれくらい待てばいいか」の目安が変わります。この数字を把握しておくだけで、「反映されていない」という問い合わせへの初動対応がかなり楽になります。
あわせて、「Replicating Directory Changes」系の権限を持つアカウントが、正規のDC以外に存在していないかも一度確認しておくと安心です。運用面とセキュリティ面、両方の意味でレプリケーションの状態を把握しておくことが、この仕組みと付き合う上での基本になります。
ADのDNS設計については「ADのDNS設計と運用ガイド」もあわせてどうぞ。
コメント