Active Directoryのドメインコントローラ（DC）は、どれも同じ役割をしているように見えますが、実は種類があります。ふつうの「書き込み可能なDC」と、小さな拠点向けの「読み取り専用DC（RODC）」です。さらに、DCの上には、グローバルカタログや操作マスターといった役割を持たせることができます。この記事では、DCの種類と役割の違いを整理し、RODCのしくみと、RODCが向いている場所を説明します。
- 書き込み可能なDC（RWDC）と読み取り専用DC（RODC）の違い
- グローバルカタログと操作マスター（FSMO）という、DCが持つ役割
- RODCがパスワードを持つ・持たないを決めるしくみ（PRP）と、盗まれたときに被害を小さくする工夫
DCの2つの種類
DCには、書き込み可能なDC（RWDC）と、読み取り専用DC（RODC）の2種類があります。ふだん「DC」と呼んでいるのは、ほとんどが書き込み可能なDCです。RODCは Windows Server 2008 で追加された種類で、サーバ室がなかったり、管理者がいなかったりする小さな拠点に置くことを想定しています。
この記事では、東京本社のデータセンターに書き込み可能なDCの DC01 と DC02 を置き、WANでつながった大阪営業所に RODC01 を置く構成で説明します。どれも同じドメイン（corp.example.com）のDCです。
書き込み可能なDC（RWDC）
書き込み可能なDCは、ADの変更を受け付けて、ほかのDCと双方向に複製します。どのDCでユーザーを作っても、パスワードを変えても、その変更はほかのDCに広がります。ドメインのすべてのアカウントのパスワード（から作った鍵）を持っているので、だれのサインインでも自分で確かめられます。
読み取り専用DC（RODC）
RODCは、ADのデータを持っていますが、変更は受け付けません。変更が必要なときはRWDCに回し、RWDCで変わった内容を複製で受け取ります。複製は、RWDCからRODCへの一方向だけです。そして、アカウントのパスワードは、許可した人の分しか持ちません。
この「変更できない」「パスワードを少ししか持たない」という2つの性質が、RODCを置く理由です。小さな拠点のサーバは、盗まれたり、だれかに勝手に操作されたりするおそれが高くなります。RODCなら、盗まれても全員のパスワードが漏れることはなく、RODCでADを書き換えて、ほかのDCに広げることもできません。
DCが持つ役割
RWDCかRODCかという種類とは別に、DCには追加の役割を持たせられます。代表的なのが、グローバルカタログと操作マスターです。
| 役割 | 内容 |
|---|---|
| グローバルカタログ（GC） | フォレスト内のすべてのドメインのオブジェクトを、よく使う属性に絞って持つ。ドメインが複数あるときは、サインインのときにユニバーサルグループを調べるのにも使う。何台のDCに持たせてもよく、RODCにも持たせられる |
| 操作マスター（FSMO） | スキーマの変更のように、1台のDCが代表してやるべき作業を受け持つ役割。全部で5つあり、それぞれ1台のDCだけが持つ。書き込みが必要なので、RODCは持てない |
5つの操作マスターのうち、スキーマ マスターとドメイン名前付け マスターはフォレストに1つずつ、PDC エミュレータ、RID マスター、インフラストラクチャ マスターはドメインごとに1つずつあります。最初に作ったDCが、自動ですべてを持ちます。
なかでもよく名前が出てくるのが PDC エミュレータです。パスワードの変更は PDC エミュレータに優先して複製され、ほかのDCで「パスワードが違う」となったときは、PDC エミュレータに確かめ直します。アカウントのロックアウトもここで扱います。フォレストルートの PDC エミュレータは、フォレスト全体の時刻の基準にもなります。特権グループの記事で出てきた SDProp も、PDC エミュレータで動いています。グローバルカタログについては「グループの種類とスコープ」の記事で詳しく説明しています。
RODCが向いている場所
RODCは、次のような拠点に置くことを想定しています。
- ユーザーの数が少ない
- サーバ室がなく、サーバが盗まれたり触られたりするおそれがある
- 東京本社とのWANが細い、または切れることがある
- ITに詳しい人がいない
DCが東京本社にしかないと、営業所のPCはサインインのたびにWAN越しに東京本社のDCへ問い合わせます。WANが切れると、サインインもできなくなります。かといって、営業所にふつうのDCを置くと、そのサーバが盗まれたときに全員のパスワードが漏れてしまいます。RODCは、この2つの間を取るためのDCです。
「変更は RWDC に回す」とは
RODC01 は、ADの中身を書き換えられません。大阪営業所でADの書き換えが必要な操作をすると、その書き換えは、WANの向こうにある東京本社の RWDC で行われます。これが図3の「変更は RWDC に回す」の意味です。大阪営業所でふだん起きる操作のうち、書き換えが必要になるのは次のような場面です。
| 操作 | いつ起きるか | 書き換えるところ |
|---|---|---|
| パスワードの変更 | user10 のパスワードの期限が来たときや、自分で変えたとき | 東京本社の RWDC |
| ユーザーの作成 | 入社や異動で、担当者がユーザーを作ったりグループのメンバーを変えたりしたとき | 東京本社の RWDC |
| PC のパスワード | PC がコンピュータアカウントのパスワードを変えるとき（既定で30日ごとに自動） | 東京本社の RWDC |
| DNS への登録 | PC を起動したときや IP アドレスが変わったときに、PC が自分の名前と IP アドレスを DNS に登録し直すとき | 東京本社の、書き込みできる DNS サーバ |
RODC01 は、こうした要求を受けても自分では書き換えません。要求を東京本社の RWDC へ中継する場合と、「書き込みは東京本社の DC へ」と行き先を教えて、PC や管理ツールが自分で送り直す場合があり、どちらになるかは操作によって変わります。どちらの場合も、実際に書き換えるのは東京本社の RWDC です。書き換えた内容は、ふつうの複製で、あとから RODC01 に届きます。つまり変更は、大阪から東京本社へ行って、東京本社から大阪へ戻ってきます。
- WAN が切れているあいだは、上の表の操作は東京本社に届かないので失敗します。サインインは、パスワードが RODC01 に置かれている人ならできます。
- user10 がパスワードを変えた直後は、RODC01 にはまだ古いパスワードしかありません。次の複製で新しいパスワードが届くまで、RODC01 は東京本社の DC に問い合わせて確かめます。
RODC が盗まれても、そこから AD を書き換えて会社全体に広げられないのは、この「RODC では書き換えない」というしくみがあるからです。
営業所でWANが切れてもサインインできるようにするには、RODCにDNSサーバとグローバルカタログも持たせておきます。インストールのときは、どちらも既定で有効になっています。
RODCでは、特定のユーザーやグループを「このRODCの管理者」として指定できます。指定された人は、そのRODCのローカルの Administrators と同じ権限で、更新プログラムの適用などの作業ができますが、Domain Admins や、ドメインの Administrators のメンバーにはなりません。営業所の担当者に、ドメイン全体の管理者権限を渡さずに、サーバの面倒を見てもらえます。
パスワードレプリケーションポリシー（PRP）
RODCが「だれのパスワードを持ってよいか」を決めるのが、パスワードレプリケーションポリシー（PRP）です。PRPには、許可リストと拒否リストがあります。
| リスト | 既定で入っているもの |
|---|---|
| 許可リスト | Allowed RODC Password Replication Group。このグループは最初は空なので、RODCを置いただけでは、だれのパスワードも置かれない |
| 拒否リスト | Denied RODC Password Replication Group、Administrators、Server Operators、Backup Operators、Account Operators。Denied RODC Password Replication Group には、Domain Admins、Enterprise Admins、Schema Admins、Group Policy Creator Owners、Cert Publishers、DCのグループ、krbtgt などが入っている |
判定のルールは3つです。
- 許可リストに入っている人のパスワードは、RODCに置いてよい
- 拒否リストに入っている人のパスワードは、許可リストに入っていても置かない（拒否が勝つ）
- どちらにも入っていない人のパスワードも置かない
大阪営業所の RODC01 なら、営業所の人をまとめたグループ（図5の GG-大阪営業所）を許可リストに足します。特権グループのメンバーは拒否リストに入っているので、たとえ大阪営業所にいても、パスワードがRODCに置かれることはありません。特権グループについては「特権グループの基本」の記事で説明しています。Microsoft は、Denied RODC Password Replication Group から既定のメンバーを外さないよう勧めています。
RODCでのサインインの流れ
許可リストに入っていても、RODCがすぐにパスワードを持つわけではありません。最初のサインインのときに、RWDCから受け取ります。
| タイミング | RODCの動き |
|---|---|
| 初めてのサインイン | パスワードを持っていないので、WAN越しにRWDCへ認証を回す。成功したら、PRPを見て、許可されていればRWDCからパスワードを受け取って覚える |
| 2回目以降 | 覚えたパスワードを使って、RODCが自分で確かめる。WANが切れていてもサインインできる |
| 許可されていない人 | パスワードを覚えないので、毎回RWDCへ回す。WANが切れていると、サインインできない |
WANが切れたときに備えて、あらかじめパスワードをRODCに入れておく（事前に複製する）こともできます。新しく営業所を開くときなどに使います。
盗まれたときに被害を小さくする工夫
RODCには、盗まれたときの被害を、そのRODCの中だけに閉じ込める工夫があります。
RODC専用の krbtgt
まず、krbtgt とは何かを確かめておきます。krbtgt は、ドメインを作ったときに自動でできるアカウントで、DC の中で Kerberos のチケットを発行する KDC が使います。人がサインインに使うことはなく、無効になっていて、削除も名前の変更もできません。パスワードは自動で長く強いものが設定されていて、そのパスワードから作った鍵を DC だけが持っています。この鍵で守っているのが、TGT（チケットをもらうためのチケット）です。
| タイミング | krbtgt の鍵の使われ方 |
|---|---|
| ① サインインしたとき | DC が user01 の TGT を作り、krbtgt の鍵で暗号化して PC に渡す。TGT には、user01 がだれか、どのグループに入っているか（PAC）、有効期限、PC と DC が使うセッションキーが入っている。PC はこの鍵を持っていないので、TGT の中身を読むことも書き換えることもできない |
| ② サービスチケットを頼むとき | FS01 などのチケットを頼むとき、PC は TGT をそのまま DC に見せる。DC は krbtgt の鍵で TGT を開け、開けられれば「自分たちが作った本物の TGT だ」と分かるので、中身を信用してサービスチケットを発行する |
つまり krbtgt の鍵は、「この TGT は DC が作った本物で、中身は書き換えられていない」ことを保証する鍵です。おかげで DC は、サービスチケットを頼まれるたびに user01 のパスワードを確かめ直さなくて済みます。同じドメインの書き込み可能なDCは、どれも同じ krbtgt の鍵を持っているので、DC01 が作った TGT を DC02 に見せても通用します。
逆にこの鍵が盗まれると、攻撃者は、好きなユーザーの TGT を、好きなグループを入れた状態で自分で作れてしまいます。こうして偽造された TGT は「ゴールデンチケット」と呼ばれ、ドメイン全体を乗っ取られたのと同じ状態になります。Kerberos のチケットの流れは「Kerberos認証とは？」の記事で説明しています。
そこでRODCは、ドメインの krbtgt ではなく、RODCごとに作られる専用の krbtgt_番号 というアカウントの鍵を使ってTGTを作ります。
ドメインの krbtgt は拒否リストに入っているので、RODCに置かれることはありません。RODCが盗まれても、漏れるのはそのRODC専用の鍵だけです。krbtgt_番号 のアカウントはRODCを追加・削除するときにWindowsが自動で管理するので、手で消してはいけません。
盗まれたときの対応
RODCが盗まれたり、乗っ取られたりしたときは、そのRODCに置かれていたパスワードが漏れたものとして扱います。どのアカウントのパスワードが置かれていたかは、RWDC側で確かめられます（後述のコマンドの RevealedAccounts）。ADからそのRODCのアカウントを削除し、パスワードが置かれていたアカウントのパスワードをリセットします。
Windows Hello for Business のクラウド Kerberos 信頼や、FIDO2 セキュリティキーでオンプレミスのリソースにアクセスするときに使う Microsoft Entra Kerberos は、ADの中に AzureADKerberos というRODCのオブジェクトと、専用の krbtgt_AzureAD アカウントを作ります。実際のサーバはなく、Entra ID がこのRODCの鍵で部分TGTを作ります。そのため、PRPもRODCと同じように効き、特権グループのメンバーはこのしくみでオンプレミスのリソースにアクセスできません。詳しくは「Microsoft Entra Kerberos」の記事で説明しています。
確認に使うコマンド
管理用PC（PowerShell）：ドメインのDCを、RODCかどうかとGCかどうか付きで一覧にする
Get-ADDomainController -Filter * | Select-Object Name, Site, IsReadOnly, IsGlobalCatalog
管理用PC（コマンドプロンプト）：操作マスターを持っているDCを表示する
netdom query fsmo
管理用PC（PowerShell）：RODCの許可リストと拒否リストを表示する
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -Allowed Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -Denied
管理用PC（PowerShell）：RODCの許可リストにグループを足す
Add-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -AllowedList "GG-大阪営業所"
管理用PC（PowerShell）：RODCにパスワードが置かれているアカウントを表示する
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -RevealedAccounts | Select-Object Name
管理用PC（PowerShell）：RODCで認証されたことがあるアカウントを表示する
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -AuthenticatedAccounts | Select-Object Name
管理用PC（PowerShell）：RODC専用の krbtgt アカウントを表示する
Get-ADUser -Filter 'Name -like "krbtgt_*"' | Select-Object Name
PRPを変えるコマンドは、RODCではなく、書き込み可能なDCに対して実行されます。
まとめ
| 項目 | ひとことで |
|---|---|
| 書き込み可能なDC | ADの変更を受け付け、全員のパスワードを持つ。ふだん「DC」と呼んでいるもの |
| RODC | 変更は受け付けず、許可した人のパスワードだけを持つ。小さな拠点向け |
| グローバルカタログ | フォレスト全体のオブジェクトを持つ役割。RODCにも持たせられる |
| 操作マスター | 1台のDCだけが持つ5つの役割。RODCは持てない |
| PRP | RODCに置いてよいパスワードを決めるルール。拒否が勝ち、特権グループは既定で拒否 |
| RODC専用の krbtgt | RODCごとに別の鍵でTGTを作るので、盗まれても被害がそのRODCに閉じる |
RODCは、「拠点でもサインインできるようにしたい」と「拠点のサーバが盗まれても困らないようにしたい」の両方をかなえるためのDCです。置くときは、許可リストに入れる人をその拠点の人だけに絞り、拒否リストは既定のまま使うのが基本です。
- Planning Domain Controller Placement（Microsoft Learn）
- Install a Windows Server 2012 Active Directory Read-Only Domain Controller (RODC)（Microsoft Learn）
- Install Active Directory Domain Services（Microsoft Learn）
- AD DS configuration wizard page descriptions（Microsoft Learn）
- Active Directory security groups（Microsoft Learn）
- dcpromo（Microsoft Learn）
- Review the removal of the default members from the Denied RODC Password Replication Group（Microsoft Learn）
- Active Directory accounts（KRBTGT account）（Microsoft Learn）
- KDC service on an RODC can’t start and generates error 1450（Microsoft Learn）
- Read-Only DCs and the Active Directory Schema（Microsoft Learn）
- Flexible Single Master Operations roles in AD DS（Microsoft Learn）
- Planning Operations Master Role Placement（Microsoft Learn）
- Get-ADDomainControllerPasswordReplicationPolicyUsage（Microsoft Learn）
- Cloud Kerberos trust deployment guide（Microsoft Learn）
- Deployment FAQs for hybrid FIDO2 security keys（Microsoft Learn）
コメント