Domain Controller の運用設計

このページで扱うこと

Active Directory Domain Services（AD DS）の Domain Controller（DC）をどう配置し、守り、復旧するかを整理します。Microsoft の公式資料を参照しながら、通常の複数 DC 構成と RODC の違いを確認します。

特に次の四点を扱います。

同一ドメインの複数 DC は「親子」ではなく、原則として対等な writable DC である。
ただし、multi-master replication (マルチマスター複製) では扱いにくい一部処理を担う Operations Master / FSMO ロールは存在する。
物理的に守りにくい拠点で「資格情報の露出を抑えながらローカル認証を提供する」仕組みとして Read-Only Domain Controller (RODC) がある。
DC 障害からの復旧と、DC 侵害からの復旧は別物である。

参照した公式情報は末尾の「公式参照」にまとめる。内容は 2026-07-12 時点の Microsoft Learn / Microsoft 公式ドキュメントを前提にしている。

押さえておきたい点

Active Directory 環境では、通常「親となる DC01 がいて、配下の DC02 / DC03 が従う」という構造ではない。

同一ドメインの writable DC は、原則として対等な multi-master 構成であり、それぞれが Kerberos Key Distribution Center (KDC)、LDAP、Netlogon、AD DS database の複製先として動作する。Microsoft の AD DS 概要でも、ドメイン内の全 DC はドメインの directory information の完全コピーを持ち、directory data への変更はドメイン内 DC へ複製されると説明されている。

一方で、すべてが完全に同格ではない。Schema Master、Domain Naming Master、RID Master、PDC Emulator、Infrastructure Master という Operations Master / FSMO ロールが存在し、競合しやすい限定処理を単一ロール所有者に集約する。

また、複数の writable DC を置くことは可用性を高めるが、セキュリティ境界を細分化しない。Microsoft は、DC への privileged access が奪われると AD DS database を変更、破壊、破損でき、AD で管理される全システムとアカウントが脅かされると説明している。Writable DC はすべて Tier 0 として扱うべきである。

「侵害された拠点 DC から全ドメインを守りつつ、ローカル認証を継続する」という要件に最も近い仕組みは RODC である。RODC は read-only AD DS database、unidirectional replication、credential caching、Password Replication Policy (PRP)、RODC 専用 krbtgt account を使って、拠点侵害時の影響範囲を小さくする。

複数 writable DC
  = 可用性、保守性、地理的分散を改善
  != ドメイン内の権限分離

RODC
  = 書き込みと資格情報キャッシュを制限
  = 物理的に弱い拠点の露出を縮小

別 forest
  = より強い管理・セキュリティ境界
  = DNS、trust、証明書、運用負荷が大きく増える

通常の複数 DC 構成

同じ domain (ドメイン) に複数の writable DC があるとする。

Domain: corp.example.com

DC01  Writable DC / KDC / LDAP / Netlogon / DNS
DC02  Writable DC / KDC / LDAP / Netlogon / DNS
DC03  Writable DC / KDC / LDAP / Netlogon / DNS

この場合、DC01 が AD 構造上の親で、DC02 / DC03 が従属しているわけではない。Windows NT の Primary Domain Controller (PDC) / Backup Domain Controller (BDC) モデルとは違い、AD DS では writable DC が同じ domain partition (ドメインパーティション) の変更を受け付け、ほかの DC へ複製する。

DC は一般に次の役割を持つ。

AD DS database の保持と directory service の提供。
Kerberos KDC としての TGT / TGS 発行。
LDAP による directory query / modify。
Netlogon による DC Locator と secure channel 関連処理。
AD-integrated DNS (AD 統合 DNS)。
SYSVOL / Group Policy Object (GPO) 配布。
Global Catalog (GC) server。全 DC が GC とは限らないが、近年の単一 forest / 単一 domain では全 DC を GC にする構成も多い。

Kerberos KDC は DC 上の Windows Server security service と統合され、domain の AD DS database を security account database として使う。つまり、Kerberos 認証の発行元は「DC 上の KDC」であり、DC は単なる LDAP サーバーではない。

[Client]
   |  AS-REQ / TGS-REQ
   v
[DC/KDC] -- AD DS database を参照 --> [User / Computer / Service Account]
   |
   +-- TGT / Service Ticket を発行

DC の発見：DNS と DC Locator

クライアントは通常、ロードバランサーの Virtual IP (VIP) に Kerberos を投げるのではなく、DNS と DC Locator によって DC を見つける。

Microsoft の Active Directory Structure and Storage Technologies では、Active Directory が DNS を domain controller location mechanism として使い、domain joined computer が authentication、updating、searching などの操作で DNS により DC を見つけると説明されている。また、Locator は Net Logon service に実装され、クライアントが DC を探すための仕組みである。

概念的には次の流れになる。

Client
  |
  | DNS / DC Locator
  v
_ldap._tcp.dc._msdcs.corp.example.com
_kerberos._tcp.dc._msdcs.corp.example.com
  |
  v
DC01 / DC02 / DC03

実務では、AD Sites and Services に subnet (サブネット) と site (サイト) を定義し、クライアントが近い DC を選べるようにする。

Tokyo Site
  Subnet: 10.10.0.0/16
  DCs   : DC-TKY01, DC-TKY02

Factory Site
  Subnet: 10.40.0.0/16
  DCs   : RODC-FAC01

Microsoft の replication concepts では、subnet は物理的近接性を識別するために使われ、site は高速で信頼できる TCP/IP subnet の集合として扱われる。これにより、replication と directory access のネットワーク利用を最適化する。

確認コマンド例。

# 現在利用しているログオン DC
$env:LOGONSERVER

# DC Locator による DC 検出
nltest /dsgetdc:corp.example.com

# ドメイン内 DC 一覧
nltest /dclist:corp.example.com

# AD PowerShell が使える場合
Get-ADDomainController -Filter * |
    Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles

レプリケーションと収束

AD DS は multi-master replication を採用する。多くの directory data は、どの writable DC で変更しても、ほかの DC へ複製される。

DC01 で user 属性を変更
  |
  v
DC02 / DC03 へ replication

Microsoft は、AD DS が directory data の multimaster replication をサポートし、任意の DC が directory changes を受け付け、ほかの DC へ replicate できると説明している。ただし、site 間の network latency、replication schedule、障害、KCC topology により、変更は全 DC に瞬時には行き渡らない。

Knowledge Consistency Checker (KCC) は全 DC 上で動作し、forest の replication topology を生成する。intrasite replication (サイト内複製) と intersite replication (サイト間複製) は別々の topology として扱われ、writable DC 間のサイト内接続は bidirectional ring と shortcut connection で latency を下げる。

このため、運用では「最終的に収束するが、一時的な差異があり得る」と考える。

1. DC01 で group membership を追加
2. 直後に DC02 へ LDAP query
3. DC02 にはまだ反映されていない
4. replication 後に DC02 でも見える

HTB や検証環境でよくある切り分け。

bloodyAD -> DC01 で group add
NetExec  -> DC02 へ LDAP query
結果     -> まだ member ではないように見える

調査時は「どの DC に対して変更したか」「どの DC に問い合わせたか」を明示する。

# 複製概要
repadmin /replsummary

# DC ごとの複製状態
repadmin /showrepl

# 強制同期の例。実運用では影響と権限を確認してから行う
repadmin /syncall /AdeP

Operations Master と FSMO

AD DS は multi-master だが、すべての処理を multi-master にすると競合や一貫性問題が起きる。そのため、特定処理は Operations Master / Flexible Single Master Operations (FSMO) として、単一ロール所有者に集約される。

Microsoft の Operations Master Role Placement では、schema modifications のような一部変更は multimaster で行うのが現実的ではないため、specific changes の request を受け付ける operations master が存在すると説明されている。

範囲	Operations Master / FSMO	主な役割
Forest	Schema Master	schema changes を管理する
Forest	Domain Naming Master	domain や directory partition の追加・削除を管理する
Domain	RID Master	domain の global RID pool を管理し、DC へ local RID pool を割り当てる
Domain	PDC Emulator	password updates、パスワード不一致時の再確認、時刻同期設計などで重要
Domain	Infrastructure Master	他 domain の security principal 参照を整合させる

重要なのは、FSMO は「親 DC」ではないという点である。通常の認証、LDAP query、多くの directory update は FSMO 所有 DC でなくても処理できる。FSMO は「特定の競合しやすい処理を引き受けるロール」であり、transfer (移動) や障害時の seize (奪取) が可能である。

PDC Emulator が「メイン DC」と誤解されやすい理由

PDC Emulator は運用上かなり目立つ。Microsoft は、PDC Emulator が client password changes を処理し、ほかの DC で bad password による logon authentication failure が起きた場合、その DC は reject を確定する前に PDC Emulator へ authentication request を転送すると説明している。

例。

1. User が DC02 経由で password を変更
2. 直後に Client が DC03 へ logon
3. DC03 には password change がまだ複製されていない
4. DC03 は PDC Emulator に確認して、最新 password を考慮する

この挙動のため、現場では PDC Emulator を持つ DC を「メイン DC」と呼ぶことがある。ただし、AD の論理構造として DC の親子関係を意味するわけではない。

RODC は FSMO を保持できない

Operations Master role holder は AD database へ書き込める必要がある。RODC は read-only なので、FSMO ロール所有者にはなれない。

確認コマンド。

netdom query fsmo

Get-ADDomain |
    Select-Object PDCEmulator,RIDMaster,InfrastructureMaster

Get-ADForest |
    Select-Object SchemaMaster,DomainNamingMaster

書き込み可能な DC を複数置く理由

複数 DC は「セキュリティ分離」ではなく、主に availability (可用性)、locality (地理的近接性)、maintenance (保守性) のために置く。

可用性

DC01 が停止しても、DC02 / DC03 が Kerberos、LDAP、DNS、Netlogon を提供できる。

Client -> DC01 失敗
       -> DNS / DC Locator
       -> DC02 から TGT を取得

単一 DC 構成では、その 1 台の障害で domain logon、LDAP query、AD-integrated DNS、GPO 適用などがまとめて止まりやすい。検証環境では単一 DC でも成立するが、実運用では同一 domain に複数 DC を配置するのが基本である。

地理的分散

拠点ごとに DC または RODC を置くと、WAN 越しの認証や directory query を減らせる。

Headquarters Site
  DC-HQ01
  DC-HQ02

Factory Site
  RODC-FAC01

Microsoft は RODC を remote / branch office environments、つまり比較的少ない user、poor physical security、poor network bandwidth、限定的な IT 知識の拠点向けに設計されたものとして説明している。

保守性

DC を順番に再起動、更新、入れ替えできる。

DC01 更新中 -> DC02 / DC03 が認証を継続
DC01 復帰
DC02 更新中 -> DC01 / DC03 が認証を継続

ただし、FSMO、Global Catalog、DNS、DHCP option、firewall、監視 agent、バックアップ、証明書 autoenrollment などが特定 DC に偏っていると、単純な「複数 DC」だけでは期待した冗長性にならない。

書き込み可能な DC が増える場合のリスク

Writable DC を増やすと可用性は上がるが、セキュリティ境界は細分化されない。

Microsoft の DC セキュリティガイドは、Domain Controller が AD DS database の物理的な保管場所であり、enterprise が server、workstation、user、application を管理するための services と data を提供すると説明している。また、DC への privileged access が得られた場合、攻撃者は AD DS database を modify、corrupt、destroy でき、AD で管理される全 system と account に影響し得るとしている。

つまり、同一 domain の writable DC はすべて Tier 0 である。

DC01 侵害
  |
  +-- AD DS database へ書き込み
  +-- 認証情報や secret への到達
  +-- GPO / ACL / group membership 改変
  +-- 変更が replication で他 DC へ伝播
  v
Domain / Forest 全体が危険

典型的な影響。

NTDS.dit や LSASS からの credential exposure。
Directory Replication Service Remote Protocol (DRSR) 権限の悪用、いわゆる DCSync 相当の credential extraction。
krbtgt key 侵害による forged Kerberos ticket、いわゆる Golden Ticket リスク。
Domain Admins、Enterprise Admins、AdminSDHolder、GPO、logon script、startup script の改変。
AD CS (Active Directory Certificate Services)、Microsoft Entra Connect、backup system、monitoring system など Tier 0 相当資産への波及。
悪意ある directory change が replication により正規の変更として伝播する。

特に krbtgt は KDC が Kerberos ticket を発行するための service account である。Event 4768 の Microsoft 公式説明でも、domain controller には KDC service が Kerberos ticket を発行するために使う specific service account krbtgt があると説明されている。

障害復旧と侵害復旧は違う

DC のディスク故障や OS 障害であれば、残存 DC から再昇格する、system state backup から復元する、metadata cleanup を行う、といった通常の復旧が中心になる。

しかし、DC 侵害では「壊れた DC を再構築すれば終わり」ではない。

Microsoft の forest recovery guide は、security breach が疑われる場合、administrative accounts の password reset、krbtgt account の complete password reset、必要に応じた trust password reset などを手順に含めている。また、krbtgt password history は 2 世代なので、元の password を履歴から除くために krbtgt password を 2 回 reset すると説明している。

障害:
  DC の停止、replication failure、DNS failure
  -> 可用性と整合性を戻す

侵害:
  攻撃者が AD の信頼根に到達
  -> 信頼できる backup、特権 credential reset、krbtgt reset、永続化調査が必要

DC を Tier 0 として守る

Microsoft の AD DS tier model では、Tier 0 は identity control plane であり、Domain Controller、AD CS、AD FS、Microsoft Entra Connect、Tier 0 admin account / group などを含む。Tier 0 の資産と identity は互いに実質的な支配関係を持つため、同じ厳格さで扱う。

基本方針。

DC は single-purpose server として扱い、business application、file server、web browsing、一般管理 tool を載せない。
Domain Admins などの高権限 account を日常作業に使わない。
Tier 0 admin は Tier 0 Privileged Access Workstation (PAW) または secure administrative host からだけ使う。
DC へ RDP / interactive logon できる主体を極小化する。
DC の OS は組織がサポートできる範囲で新しく保つ。
可能なら Server Core を使い、攻撃面と人為ミスを減らす。
DC の patch / configuration management を一般サーバー群と分ける。一般管理基盤の侵害が DC 侵害に直結しないようにする。
DC からの internet access と web browser 使用を制限する。
物理 DC は secure rack / cage、TPM、BitLocker を検討する。
virtual DC は、可能なら一般 workload と別の virtualization host / storage / admin boundary に置く。

特に「trusted system を less-trusted host から管理しない」という原則が重要である。Tier 0 credential を Tier 1 / Tier 2 端末に入力した時点で、Tier 0 境界は崩れる。

RODC：書き込み権限を持たない拠点 DC

RODC (Read-Only Domain Controller) は、物理的に守りにくい branch office や remote location に DC 機能を置くための仕組みである。

Headquarters
  DC-HQ01    Writable DC
  DC-HQ02    Writable DC

Factory
  RODC-FAC01 Read-Only DC

Microsoft は RODC について、read-only partitions of the AD DS database を保持し、writable DC ほどの物理セキュリティを確保できない場所に DC をより安全に配置する方法だと説明している。

主な機能。

機能	意味
Read-only AD DS database	RODC 上の AD DS database へ通常の書き込みをしない
Unidirectional replication	RODC から writable DC へ変更を複製しない
Credential caching	PRP に従い、一部 user / computer credential だけを cache する
Administrator role separation	拠点担当者へ RODC ローカル管理を委任しても domain admin 権限を与えない
Read-only DNS	DNS server を置けるが、RODC 上の DNS は read-only として動く
Dedicated RODC krbtgt	RODC ごとに異なる krbtgt account / password を使う

RODC の重要な特徴は、credential caching が既定では最小限であることだ。Microsoft は、既定では RODC は user / computer credentials を保存せず、例外は RODC の computer account と各 RODC が持つ special krbtgt account であり、それ以外の credential caching は明示的に許可する必要があると説明している。

書き込み可能な DC と RODC の侵害影響

Writable DC の場合。

DC-FAC01 侵害
  |
  +-- domain の重要 credential へ到達
  +-- krbtgt key 侵害
  +-- AD object / GPO / ACL 改変
  v
Domain 全体が危険

RODC の場合。

RODC-FAC01 侵害
  |
  +-- RODC 専用 krbtgt
  +-- cache 済み account credential
  +-- 読み取り可能な AD 情報
  v
主にその RODC と cache 対象へ影響を限定

Microsoft は、RODC が writable DC とは異なる krbtgt account と password を使って TGT request に署名または暗号化すると説明している。そのため、RODC の krbtgt が侵害されても、通常の domain krbtgt 侵害とは影響範囲が異なる。

ただし、これは「RODC なら安全」という意味ではない。RODC は影響範囲を小さくする設計であり、完全な防壁ではない。

パスワード複製ポリシー（PRP）

PRP は、どの user / computer credential を RODC に replicate / cache してよいかを決める policy である。

例。

Allowed RODC Password Replication:
  - Factory-Users
  - Factory-Computers
  - Factory-Local-Support

Denied RODC Password Replication:
  - Domain Admins
  - Enterprise Admins
  - Schema Admins
  - Account Operators
  - Server Operators
  - HQ-Admins

認証の流れ。

WAN 正常時:
User -> RODC -> Writable DC へ認証を forward
                  |
                  +-- PRP で許可されれば credential を RODC へ replicate/cache

WAN 切断時:
User -> RODC の cached credential で認証

PRP の設計は trade-off である。

cache を広げると、WAN 障害時に拠点内認証を継続しやすい。
cache を広げると、RODC 侵害時に盗まれ得る credential が増える。
高権限 account は RODC に cache させない。
Domain Admin は RODC へ interactive logon しない。

RODC を採用する判断は、次のように考えるとよい。

Writable DC
  = WAN 断でも広い範囲を認証しやすい
  = 拠点侵害時は domain 全体への影響が大きい

RODC
  = WAN 断時に認証できる account は PRP / cache に依存
  = 拠点侵害時の credential exposure を絞りやすい

RODC の限界

RODC は強い選択肢だが、設計を誤ると効果が薄れる。

キャッシュされた資格情報の露出

RODC に credential を cache した account は、RODC 侵害時の影響範囲に入る。Allowed group を広くしすぎると、RODC の利点が失われる。

管理者セッションが防御を崩す

Domain Admin が RODC に対話ログオンすると、RODC が cache しないはずの高権限 credential や token がローカルに露出し得る。

Domain Admin が RODC へ RDP
  |
  +-- logon session / token / credential material が露出
  v
RODC 設計の保護が弱くなる

Microsoft の RODC documentation は、RODC の administrator role separation により domain user に RODC ローカル保守を委任でき、domain や他 DC への admin 権限を与えずに済むと説明している。つまり、拠点作業者には RODC ローカル管理だけを委任し、domain-wide admin を使わない設計が前提である。

AD 情報の列挙はできる

RODC は read-only でも、多くの AD object と attribute を保持する。User、group、computer、SPN、ACL、GPO link などは攻撃経路分析に利用され得る。

RODC 侵害
  |
  +-- LDAP read
  +-- SPN enumeration
  +-- group / ACL enumeration
  v
横展開の計画材料になる

書き込み拒否は万能ではない

RODC 上の LDAP write request は writable DC への referral になる。アプリケーションによっては RODC 互換性に問題が出る。DNS も read-only として動くため、client update の扱いを理解しておく必要がある。

フィルター対象属性も設計する

RODC filtered attribute set は、password、credential、encryption key のような credential-like data を RODC に複製させないための仕組みである。ただし、system-critical attributes は追加できない。古い DC が混在する forest では制約もあるため、forest functional level と legacy DC の有無を確認する。

ドメインとフォレストによる分離

DC を増やすことは security boundary の分割ではない。分離を考えるなら domain / forest の構造を理解する必要がある。

Forest: example.com

Root Domain:
  example.com

Child Domains:
  corp.example.com
  factory.example.com

child domain の DC は、parent domain の DC の「配下サーバー」ではない。それぞれ別 domain partition を持ち、所属 domain の KDC として動く。

DC01.example.com
  -> example.com 用 DC / KDC

DC01.factory.example.com
  -> factory.example.com 用 DC / KDC

別 domain の service へ Kerberos 認証する場合は、trust と referral ticket を使う。

ただし、domain 分割は完全な security isolation ではない。Microsoft の Active Directory Structure and Storage Technologies は、forest を logical structure の security boundary とし、domain は data and service autonomy を提供するが isolation は提供しないと説明している。また、forest は単一の self-contained directory であり、forest 内の administrator は forest 内情報と DC に対して完全な制御を持つと説明されている。

強い分離が必要なら、別 forest を検討する。

corp.example Forest
factory.example Forest
        |
        +-- 限定的な Forest Trust

ただし、別 forest は次のコストを伴う。

名前解決、DNS forwarding、conditional forwarder 設計。
forest trust と selective authentication の設計。
AD CS / PKI / certificate mapping の分離。
ID lifecycle、group、GPO、端末管理の分離。
アプリケーション互換性と運用手順の増加。
監査、SIEM、EDR、backup、DR の二重化。

したがって、「セキュリティ境界を分けたい」のか、「管理委任や replication 範囲を分けたい」のかを先に決める。

認証ポリシー・サイロと階層化

特権 account の保護は、DC 配置だけでは足りない。Microsoft は Authentication Policies and Authentication Policy Silos を、high-privilege credentials を selected users / computers / services に関係する systems へ閉じ込める方法として説明している。

Authentication policy でできることの例。

account の Kerberos TGT lifetime を短くし、non-renewable にする。
user が sign in できる device 条件を制限する。
service account credential を使える host を制限する。
service ticket issuance を access control condition に基づき制限する。

Microsoft の説明では、authentication policies は Kerberos AS exchange / TGS exchange で enforcement される。つまり、KDC が TGT / TGS を出す段階で制御が入る。

特権運用では、次の組み合わせで考える。

目的	主な仕組み
Tier 0 credential を下位端末へ出さない	Tier model / PAW / secure administrative host
高権限 account の使用場所を制限する	Authentication Policies / Silos
古い認証方式を避ける	Protected Users group / Kerberos AES
拠点に置く credential を減らす	RODC / PRP
DC 自体の攻撃面を減らす	Server Core、no web browsing、専用 patch 管理、最小ログオン

運用で見るべきログ

Kerberos 認証は DC 上の Security log に多くの痕跡を残す。

Event ID	意味	主な観点
4768	Kerberos TGT requested	AS-REQ / TGT 発行。DC 上に生成される
4769	Kerberos service ticket requested	TGS request。DC 上に生成される
4771	Kerberos pre-authentication failed	password spray、時刻ずれ、pre-auth 失敗
4776	NTLM authentication	NTLM fallback、legacy system、relay リスク

Microsoft の Event 4768 公式説明では、この event は KDC が TGT を issue するたびに生成され、domain controllers 上にのみ生成される。Event 4769 も同様に、KDC が TGS ticket request を受け取るたびに生成され、domain controllers 上にのみ生成される。

調査観点。

どの DC が TGT / TGS を発行したか。
IpAddress はどの client か。
ServiceName は krbtgt か、特定 SPN か。
TicketEncryptionType が RC4 など legacy に寄っていないか。
失敗 code が password spray、時刻ずれ、service ticket expiration、policy rejection などのどれに近いか。
Authentication Policy / Silo の failure event が出ていないか。

# Kerberos ticket cache
klist
klist tgt
klist tickets

# DC 上で Security log を見る例
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4768
} -MaxEvents 20

運用ヘルスチェック

代表的な確認コマンド。

目的	コマンド
現在の logon DC	`$env:LOGONSERVER`
DC Locator 確認	`nltest /dsgetdc:corp.example.com`
domain 内 DC 一覧	`nltest /dclist:corp.example.com`
FSMO 確認	`netdom query fsmo`
複製概要	`repadmin /replsummary`
DC 別複製	`repadmin /showrepl`
DC / DNS / Netlogon health	`dcdiag /v`
secure channel 確認	`nltest /sc_verify:corp.example.com`
Kerberos ticket 確認	`klist`
time sync 確認	`w32tm /query /status`
DNS SRV 確認	`nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com`

定期的に見るべき観点。

全 DC の replication が成功しているか。
lingering object や USN rollback 兆候がないか。
FSMO holder が期待通りで、standby plan があるか。
PDC Emulator の time source が正しいか。
Global Catalog が必要 site にあるか。
DNS SRV record が stale になっていないか。
RODC の PRP allowed / denied / cached list が過剰になっていないか。
Domain Admins などが DC / RODC に不用意に interactive logon していないか。
DC から internet access や web browser 起動が行われていないか。
DC 上に不要な agent、tool、business workload が載っていないか。

代表的な設計パターン

目的	構成	注意点
同一拠点の障害対策	writable DC を 2 台以上	DNS / GC / FSMO / backup も冗長化する
遠隔拠点の認証高速化	拠点 DC または RODC	physical security と WAN 条件で選ぶ
物理的に守れない拠点	RODC + 厳格な PRP	高権限 account を cache しない、admin logon を避ける
WAN 断でも広範囲を認証	writable DC	拠点侵害時は domain 全体リスクが大きい
拠点侵害時の credential exposure を抑制	RODC	cache 対象を小さくするほど安全だが、WAN 断時の認証対象は減る
管理境界を強く分ける	別 forest + trust	運用負荷、アプリ互換性、証明書、監査設計が増える
特権 account 保護	Tier model / PAW / Authentication Policy / Protected Users	DC 配置だけでは保護にならない
DC 侵害からの復旧	Forest recovery plan / trusted backup / krbtgt reset twice	通常障害復旧とは手順が異なる

HTB と実環境の違い

HTB では DC が 1 台だけの lab が多い。これは主に環境単純化とリソース節約のためである。実環境では、BloodHound や LDAP enumeration で複数 DC が見えることがある。

DC01.CORP.LOCAL
DC02.CORP.LOCAL
RODC01.BRANCH.CORP.LOCAL

このとき重要なのは、「どの DC に接続できるか」だけではない。

自分の端末がどの AD Site に属するか。
LDAP query はどの DC へ行っているか。
変更した object はどの DC で更新されたか。
その変更は target DC に複製済みか。
Kerberos TGT / TGS をどの KDC が発行したか。
target DC は writable DC か RODC か。
FSMO ロールはどこにあるか。
Global Catalog が必要な query か。
DNS SRV record が stale になっていないか。

攻撃・検証時の例。

1. DC01 に対して group membership を変更
2. DC02 に対して LDAP query
3. DC02 ではまだ反映されていない
4. DC01 を明示して query すると見える
5. replication 後に DC02 でも見える

防御側の例。

1. Event 4768 で TGT 発行 DC と client IP を見る
2. Event 4769 で requested service / SPN を見る
3. repadmin で replication delay を確認する
4. nltest で client が選んだ DC を確認する

設計チェックリスト

新しい DC / RODC を置く前に確認する。

その拠点は writable DC が必要か、RODC でよいか。
物理的な鍵、rack、TPM、BitLocker、host isolation は足りているか。
拠点 WAN 断時に、誰が認証できる必要があるか。
RODC の PRP allowed / denied group は最小化されているか。
Domain Admins / Enterprise Admins が RODC に logon しない運用になっているか。
DC は Tier 0 として、PAW / secure admin host からだけ管理されているか。
DC に一般業務 workload や web browsing が存在しないか。
DC 用 backup と forest recovery 手順はテスト済みか。
FSMO holder と standby holder は決まっているか。
PDC Emulator の time source は設計済みか。
Global Catalog / DNS / DHCP / firewall / monitoring が特定 DC に依存しすぎていないか。
Event 4768 / 4769 / 4771 / 4776 を SIEM へ集約しているか。
DC 侵害時の krbtgt reset twice、admin password reset、metadata cleanup、trust password reset の判断基準があるか。

公式資料

Active Directory Domain Services overview: AD DS database、security integration、replication service の概要。
Active Directory Structure and Storage Technologies: forest / domain、DNS support、DC Locator、forest security boundary の整理。
Active Directory Replication Concepts: KCC、site、subnet、replication topology、failover。
Planning Domain Controller Placement: DC placement と RODC の配置背景。
Planning Operations Master Role Placement: FSMO / Operations Master、PDC Emulator、RID Master、RODC が FSMO を保持できない点。
AD DS: Read-Only Domain Controllers: RODC の read-only database、unidirectional replication、credential caching、RODC krbtgt、PRP。
Best practices for securing Active Directory: AD attack surface、privileged account、DC security。
Securing domain controllers against attack: DC 侵害の影響、物理セキュリティ、Server Core、internet access 制限。
Tier model for Active Directory Domain Services: Tier 0 / Tier 1 / Tier 2、PAW、credential isolation。
Kerberos authentication overview in Windows Server: KDC と AD DS database、Kerberos の基本。
4768: A Kerberos authentication ticket (TGT) was requested: TGT request event。
4769: A Kerberos service ticket was requested: TGS request event。
Authentication Policies and Authentication Policy Silos: 高権限 credential の使用範囲制限、TGT lifetime、Kerberos AS / TGS enforcement。
Active Directory Forest Recovery - Perform the initial recovery: breach 時の admin password reset、krbtgt reset twice、metadata cleanup、replication health verification。