システムエンジニアXの「プログラミング以外」の話 50代会社員SEのお仕事・副業・システム運用の経験談
Windows

【AD複製】サイト内レプリケーション間隔が「15秒」の理由と緊急複製

公開:

※本記事には広告を含みます。

はじめに

Active Directory（AD）の運用において、「ユーザー属性を変更したのに別のドメインコントローラー（DC）へ反映されるまで少しラグがある」「同一サイト内のDC間レプリケーション間隔は何秒なのか？」と疑問に思ったことはないでしょうか。

私も過去に、バッチ処理で1号機のDCにユーザーを作成した直後（1秒後）に、別システムが2号機のDCへLDAP照会を行って「ユーザーが存在しない」というエラーになり、AD複製のタイムラグを考慮した設計の重要性を痛感したことがあります。

Active Directoryのレプリケーション（複製）は、同じ拠点内（サイト内）と別拠点間（サイト間）でまったく異なるアルゴリズムで動いています。さらに、パスワード変更やアカウントロックアウトのときだけ通常の待機時間を無視して即座に同期する特別な仕組みも備わっています。

この記事では、同一サイト内のレプリケーション間隔が「15秒（＋後続3秒）」に設計されている理由と、緊急複製（Urgent Replication）の動作条件、および設定値の確認・変更手順を解説します。

読み終えるころには、ADの変更反映タイミングを秒単位で正確に把握し、トラブル切り分けやシステム連携設計に活かせるようになります。

この記事の要点

  • 同一サイト内のDC間複製は定期スケジュールではなく 「変更通知（Change Notification）ベース」 で動作し、変更発生から 既定15秒後 に最初のパートナーDCへ通知される
  • 複数の複製パートナーがいる場合は、ネットワーク輻輳を防ぐため2台目以降へ 3秒ずつずらして（スタッガード通知） 順番に通知を送る
  • アカウントロックアウトやオブジェクトの削除時などは、15秒の待機をスキップして即座に通知する 「緊急複製（Urgent Replication）」 が発動する
項目 動作確認・検証環境
検証年月 2026年9月
対象OS Windows Server 2022 / Windows Server 2025
関連コンポーネント KCC（知識整合性チェッカー）/ NTDS Settings
確認ツール repadmin コマンド / Active Directory サイトとサービス / PowerShell

結論：サイト内複製は「15秒待機＋3秒間隔」の変更通知で動く

結論からお伝えすると、同一サイト（Intra-site）内のドメインコントローラー間では、「ディレクトリに変更が発生してから15秒間待機し、その後パートナーDCへ変更通知を送ってプル型で複製させる」 という仕組みになっています。

さらに、同じサイト内に複数のパートナーDCが存在する場合は、1台目に通知してから 3秒間隔 で次のDCへ順次通知します。

1. サイト内複製（Intra-site）とサイト間複製（Inter-site）の決定的な違い

まず前提として、高速なLANで結ばれた「サイト内複製」と、WAN回線を経由する「サイト間複製」の違いを整理します。

比較項目 サイト内複製（Intra-site） サイト間複製（Inter-site）
複製のトリガー 変更通知ベース（変更があった時だけ通知） スケジュールによる定期ポーリング（変更通知も有効化可）
既定の反映間隔 変更発生から15秒後（後続DCへは＋3秒ずつ） 既定180分（3時間）ごと ※最小15分まで短縮可
データの圧縮 非圧縮（CPU負荷軽減を優先し、高速LAN帯域を使う） 圧縮あり（約10〜15%に圧縮してWAN帯域を節約）
複製トポロジ KCCが自動生成する双方向リング構造（最大3ホップ以内） サイトリンクブリッジヘッドDC間のスパニングツリー

※なお、サイト内であっても万が一変更通知がロストした場合のセーフティネットとして、1時間に1回（60分周期）の定期ポーリングもバックグラウンドで動いています。

2. なぜ「0秒（即時）」ではなく「15秒」待つのか？

高速なLAN内なのになぜ即座（0秒）に通知せず、あえて15秒間も待機するのでしょうか。

その理由は 「連続する変更を1回のレプリケーションにまとめて（バッチ化して）効率化するため」 です。
例えば、管理者がActive Directoryユーザーとコンピューター（ADUC）で1人のユーザーの「部署」「役職」「電話番号」を書き換えて[OK]を押したり、スクリプトで複数属性を一括更新したりする場合、数秒の間に何十回もの書き込みトランザクションが発生します。

もし0秒で通知してしまうと、1属性書き換わるごとに全パートナーDCへRPC通信が走り、DCのCPUとネットワークがパンクしてしまいます。15秒間の「溜め（バッチウィンドウ）」を設けることで、一連の変更を1回の差分転送でスマートに同期できるのです。

また、2台目以降のパートナーDCに 3秒ずつディレイ（遅延） を入れるのは、通知を受け取った複数台のDCが一斉に複製元DCへ「差分データをください（Pullリクエスト）」と殺到するのを防ぐためです。

15秒を待たずに即時同期する「緊急複製（Urgent Replication）」と「即時連携」

「15秒待つ仕様なら、悪意ある攻撃者が15秒以内に別々のDCへ高速にパスワード総当たり攻撃を仕掛けたら、アカウントロックアウトをすり抜けられるのではないか？」と疑問に思う方もいるでしょう。

それを防ぐためにActive Directoryに組み込まれているのが 「緊急複製（Urgent Replication）」 と 「PDCエミュレーターへの即時転送」 です。

1. 緊急複製（Urgent Replication）が発動する4つのイベント

以下の重大なセキュリティイベントが発生したとき、DCは15秒の通知待機タイマーを強制キャンセルし、0秒（即時）で複製パートナーへ変更通知を送信 します。

  1. アカウントロックアウトの発生（lockoutTime 属性の更新）
  2. アカウントの無効化・ロック解除（userAccountControl 属性の変更）
  3. ドメインのロックアウトポリシー・パスワードポリシーの変更
  4. オブジェクトの削除（Tombstone / ごみ箱への移動）
  5. LSAシークレット（信頼関係パスワード等）の変更

2. パスワード変更とロックアウト時の「PDCエミュレーター」特別ルート

さらに、パスワード変更や認証失敗時には、通常のサイト内・サイト間複製とは別に、ドメイン内に1台存在するFSMOロール 「PDCエミュレーター」 を介した特別な即時通信が行われます。

  • パスワード変更時: いずれかのDCでパスワードが変更されると、そのDCはサイト内外を問わず即座に PDCエミュレーターへ新しいパスワードを直接プッシュ通知 します。直後に別のDCで新パスワードを使ってログオンした場合、そのDCはローカルで認証失敗した瞬間にPDCエミュレーターへ問い合わせに行くため、レプリケーション完了前でも新パスワードでログオンできます。
  • アカウントロックアウト時: 認証失敗によりアカウントがロックされると、PDCエミュレーターへ即時通知され、そこから緊急複製によってサイト内の各DCへ数秒以内にロック状態が伝播します。

レプリケーション間隔（15秒／3秒）の確認・変更と診断コマンド

サイト内の複製遅延設定（15秒／3秒）は、Active Directoryの構成パーティション内の属性として保持されており、PowerShellや repadmin で確認できます。

1. 現在の複製通知タイミングと複製状態を調べるPowerShell

管理者権限のPowerShellで以下のスクリプトを実行すると、現在のサイトの通知遅延設定と、直近のDC間レプリケーション成功状況を一覧表示できます。

Import-Module ActiveDirectory

# 1. 構成パーティションから各サイトの「DS-UI-Settings」および複製遅延設定を確認
$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$SiteSettings = Get-ADObject -SearchBase "CN=Sites,$ConfigNC" -Filter "objectClass -eq 'nTDSSiteSettings'" -Properties *

foreach ($Setting in $SiteSettings) {
    Write-Host "サイト設定パス: $($Setting.DistinguishedName)" -ForegroundColor Cyan
}

# 2. ドメイン内の全DC間のレプリケーション状態・遅延エラーを診断
Write-Host "`n--- DC間レプリケーションサマリー ---" -ForegroundColor Green
repadmin /replsummary

repadmin /replsummary を実行すると、各DCの「最大のデルタ（最後の複製からの経過時間）」や「失敗数」が一目でわかります。エラーが 0 であれば、変更通知ベースの複製が正常に機能しています。

2. レジストリによる15秒・3秒タイマーのカスタマイズ場所（原則変更不要）

各ドメインコントローラーの以下のレジストリキーで、15秒と3秒の既定値をチューニングすることも可能です（値を設けない場合はOS既定の15秒・3秒で動作します）。

キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  • Replicator notify pause after modify (secs)（REG_DWORD）
  • 既定値：15（変更検知から最初のパートナーへ通知するまでの秒数）
  • Replicator notify pause between DSAs (secs)（REG_DWORD）
  • 既定値：3（2台目以降のパートナーへ通知する際の間隔秒数）

※Microsoft公式でも既定値（15秒／3秒）が最適バランスとされており、特殊な検証環境以外でこれを極端に短く（1秒などに）設定すると、DC間のRPCトラフィックが急増するため本番環境では既定のまま運用してください。

3. 手動で今すぐ全DCへ変更を即時同期させるコマンド

メンテナンス時やGPO・ユーザー作成直後に、15秒すら待たずに今すぐ全DCへ強制レプリケーションさせたい場合は、以下のコマンドを実行します。

# 現在のDCからすべての複製パートナーへ即時プッシュ同期を実行（全パーティション対象）
repadmin /syncall /AdeP
  • /A: すべてのディレクトリパーティションを対象にする
  • /d: メッセージ内でDCをGUIDではなくDNSホスト名で表示する
  • /e: サイト内だけでなくサイト間（エンタープライズ全体）のDCも対象にする
  • /P: プルではなく、実行元DCから変更を外へプッシュ（Push）する

よくある質問（FAQ）

Q: サイト内にDCが5台ある場合、すべてのDCに反映されるまで最大何秒かかりますか？

A: KCC（知識整合性チェッカー）はサイト内のDC数がいくつであっても 「最大3ホップ以内」 で全DCに到達するように複製リングを自動構築します。1ホップあたり「15秒＋パートナー順番待ち（3秒×N）」がかかるため、通常の変更であっても約30秒〜1分以内にはサイト内の全DCへ同期が完了します。

Q: サイト間（別拠点間）のレプリケーションでも、サイト内のような「変更通知（15秒）」を使えますか？

A: はい、可能です。既定ではサイト間複製は変更通知がオフ（180分ごとのスケジュール複製）になっていますが、「Active Directory サイトとサービス」で対象のサイトリンクのプロパティを開き、属性エディターで options 属性に 1（USE_NOTIFY フラグ） を設定することで、WAN越しのサイト間でも15秒の変更通知ベースで即時複製させることができます。拠点間が十分な帯域の専用線やVPNで常時接続されている環境ではよく採用される手法です。

Q: SYSVOL（GPOのファイル実体）も同じ15秒間隔で複製されますか？

A: SYSVOLはADデータベース（NTDS.dit）の複製ではなく、DFSR（DFSレプリケーション） という別エンジンで同期されています。ただし、DFSRも変更通知ベースで動作するため、GPOを編集・保存すると同一サイト内であれば数秒〜十数秒程度で他DCのSYSVOLへ同期されます。

まとめ

Active Directoryのサイト内レプリケーションの仕組みとポイントは以下の通りです。

  • サイト内DC間の複製は定期ポーリングではなく 「変更通知ベース」 で動く
  • 連続する変更をバッチ化して負荷を抑えるため、変更から 「15秒後」 に最初のDCへ通知し、後続DCへは 「3秒間隔」 で順次通知する
  • アカウントロックアウトやオブジェクト削除時は、15秒の待機をスキップして 「緊急複製（Urgent Replication）」 が即座に走る
  • パスワード変更時は PDCエミュレーター へ即時プッシュされるため、レプリケーション遅延によるログオン失敗を防ぐ仕組みになっている

この「15秒の法則」を知っておくことで、スクリプトでAD操作を行う際の適切なウェイト設計や、認証トラブル時の正確な切り分けが可能になります。

関連記事

免責規定

この記事で提供される情報は、一般的なガイダンスを目的としており、すべての環境やシステムでの動作を保証するものではありません。

OSのバージョンやリリースによっては、記載されている事が実行できない、または異なる結果をもたらす可能性があります。 また、会社所有のパソコン、スマホ、タブレットなどでは、ポリシーや権限によって実行できない場合があります。

この記事の情報を使用することによって生じる問題や結果について、筆者およびサイト管理者は責任を負いません。 すべての操作は自己責任で行ってください。

最後までお読みいただきありがとうございました。
またお会いしましょう！
← 記事一覧に戻る