はじめに
ドメインコントローラー（DC）は、Active Directory 環境における「信頼の基点（Root of Trust）」です。Linuxエンジニアの感覚で言えば、「LDAP サーバー + Kerberos KDC + DNS サーバー + 構成管理マネージャー」が1台に統合された、最高特権サーバーです。
DC を突破されることはドメイン全体の陥落を意味します。本記事では「とりあえず立てる」ではなく、「セキュアに立てる」ための設計思想と実践を解説します。
1. Server Core を選択する：GUI は攻撃面である
Linuxエンジニアが Windows Server を敬遠する理由のひとつが「GUI の重さ」ですが、現代の DC 構築では Server Core（GUI なしインストール） を選ぶのが鉄則です。
| 比較項目 | デスクトップエクスペリエンス（GUI あり） | Server Core（GUI なし） |
|---|---|---|
| 攻撃面 | ブラウザ・エクスプローラー等が存在 | 最小限（DC 機能のみ） |
| パッチ頻度 | GUI コンポーネントのパッチも必要 | 少ない |
| リソース消費 | 大きい | 小さい（Linux ヘッドレスに近い） |
| 管理方法 | ローカル GUI 操作が可能 | PowerShell / リモート管理のみ |
Server Core は Linux のヘッドレスサーバーと同様に、最小限のコンポーネントしか持ちません。「GUI がないと管理できない」という懸念は、後述の PowerShell リモート管理 や Windows Admin Center（WAC）で解消できます。
補足： Windows Admin Center は GUI 管理が必要な場合のための Web ベース管理ツールです。DC 本体には GUI を持たせず、管理端末から WAC 経由で操作するのが推奨されるアーキテクチャです。
2. DC には DC 以外の役割を持たせない
Linux では1台のサーバーに複数サービスを同居させることもありますが、DC では 「DC 以外の役割を絶対に持たせない」 ことが必須です。
【NG 構成の例】
DC ─┬─ AD DS（ドメインコントローラー）
├─ ファイルサーバー（SMB 共有） ← NG
├─ プリントサーバー ← NG
└─ IIS（Web 管理画面） ← NG
【推奨構成】
DC ─── AD DS のみ
FS ─── ファイルサーバーのみ
WEB ─── Web サーバーのみ
なぜ危険か： 他サービスに脆弱性が存在した場合、そのプロセス権限を奪われると、同じマシン上で動く AD DS への横移動（Lateral Movement）が容易になります。ファイルサーバーのゼロデイ1件で Domain Admins を奪取されるリスクを作るべきではありません。
3. ネットワーク設計：最小公開の原則
DC は「どこからでもアクセスできる」必要はありません。通信を必要最小限に絞ります。
静的 IP の設定
DC の IP が変わるとドメイン全体の DNS 解決が崩壊します。必ず静的 IP を割り当てます。
# 静的 IP の設定例
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.1.10 -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1
ファイアウォール：AD に必要なポートのみ許可
AD 通信に必要な主なポート（参考）
TCP/UDP 88 : Kerberos 認証
TCP/UDP 389 : LDAP
TCP 636 : LDAPS（LDAP over TLS）← 必ず有効化
TCP/UDP 445 : SMB（SYSVOL/NETLOGON 共有）
TCP 3268 : グローバルカタログ（LDAP）
TCP 3269 : グローバルカタログ（LDAPS）
TCP 135 : RPC エンドポイントマッパー
TCP 49152+ : RPC 動的ポート（制限可能）
LDAP（389）は平文通信です。LDAPS（636）または LDAP Channel Binding を必ず有効化し、平文 LDAP を無効化することを検討してください。
DNS のリッスン制限
AD は DNS に強く依存しますが、不必要なインターフェース（DMZ セグメント等）で DNS リクエストを受け付けないよう設定します。
# DNS サーバーが特定の IP のみでリッスンするよう設定する
Set-DnsServerSetting -ListenAddresses "192.168.1.10"
4. RODC（読み取り専用 DC）：物理セキュリティが確保できない拠点に
物理セキュリティが十分でないブランチオフィスなどに DC を設置する必要がある場合は、RODC（Read-Only Domain Controller） を検討します。
| 特性 | 通常の DC | RODC |
|---|---|---|
| パスワードハッシュ | 全ユーザー分を保持 | デフォルトは保持しない（PRP で制御） |
| レプリケーション方向 | 双方向 | 本部 DC → RODC の一方向のみ |
| 物理盗難時のリスク | 全ユーザーハッシュ漏洩 | 最小限（PRP で許可したアカウントのみ） |
| 書き込み操作 | 可能 | 不可（本部 DC に転送） |
PRP（Password Replication Policy） で「この RODC にキャッシュを許可するアカウント」を明示的に指定します。デフォルトでは Domain Admins や Enterprise Admins のハッシュは RODC にキャッシュされません。
5. 実践：PowerShell による DC 昇格の自動化
GUI（サーバーマネージャー）での手動構築は卒業し、Infrastructure as Code の考え方で構築します。
ステップ 1：AD DS 役割のインストール
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
ステップ 2：新規フォレストの作成（DC 昇格）
Install-ADDSForest `
-DomainName "corp.example.com" `
-DomainNetbiosName "CORP" `
-DomainMode "WinThreshold" `
-ForestMode "WinThreshold" `
-DatabasePath "C:\Windows\NTDS" `
-LogPath "C:\Windows\NTDS" `
-SysvolPath "C:\Windows\SYSVOL" `
-InstallDns:$true `
-CreateDnsDelegation:$false `
-NoRebootOnCompletion:$false `
-Force:$true
ステップ 3：既存ドメインへの追加 DC 参加（冗長化）
本番環境では DC は必ず2台以上構成します。1台は単一障害点になります。
Install-ADDSDomainController `
-DomainName "corp.example.com" `
-InstallDns:$true `
-Credential (Get-Credential "CORP\Administrator") `
-NoRebootOnCompletion:$false `
-Force:$true
DSRM パスワードについて：
昇格時に設定する「ディレクトリサービス復元モード（DSRM）」のパスワードは、AD が停止した障害時の唯一の復旧手段です。Linux の root パスワードと同等の重要度で管理し、PAM（特権アクセス管理）ツールや金庫に保管してください。DC ごとに異なるパスワードを設定することを推奨します。
6. バックアップ：System State を含めることが必須
Linux の /home や /etc だけバックアップするのと同じ感覚では DC のバックアップは不完全です。
DC のバックアップには System State（AD データベース NTDS.dit、SYSVOL、レジストリ、ブートファイルを含む）を必ず含める必要があります。
# Windows Server バックアップで System State をバックアップ
wbadmin start systemstatebackup -backuptarget:\\backup-server\DCBackup -quiet
| バックアップ対象 | Linux の対応 | 重要度 |
|---|---|---|
NTDS.dit（AD データベース） |
/var/lib/ldap |
最高 |
SYSVOL（グループポリシー等） |
/etc/ansible/ に近い |
高 |
| レジストリ（System、SAM 含む） |
/etc 全体 |
高 |
バックアップメディアには AD のすべての認証情報が含まれます。バックアップ先のアクセス制御は DC 本体と同等のセキュリティを適用してください。
まとめ
| 設計要素 | 推奨 | 理由 |
|---|---|---|
| OS インストール形式 | Server Core | 攻撃面の最小化 |
| 役割の分離 | DC 専用（他サービス混在禁止） | 横移動リスクの排除 |
| ネットワーク | 静的 IP、最小ポート開放、LDAPS 必須 | 通信経路の制限 |
| 冗長構成 | DC 2台以上 | 単一障害点の排除 |
| ブランチ拠点 | RODC + PRP 設定 | 物理盗難リスクの軽減 |
| バックアップ | System State 含む定期バックアップ | 障害復旧 |
| 構築方法 | PowerShell による自動化 | 再現性・ドキュメント化 |
デフォルト設定のまま DC を運用することは、PermitRootLogin yes かつパスワード認証を有効にしたまま SSH を公開するようなものです。DC の設計はドメイン全体のセキュリティポスチャーを決定します。