RODCのパスワード複製ポリシーを理解するときに、最初に押さえるべき結論はひとつです。これは「誰を認証してよいか」を決める設定ではなく、誰の資格情報をRODCにキャッシュしてよいかを決める仕組みです。Allowed に入れただけでは即キャッシュされず、Denied はキャッシュ禁止、実際にRODCへ複製済みかどうかは別の一覧で確認します。新しい RODC は既定で資格情報をキャッシュしないため、支店運用では「WAN断でも本当に使い続けたいユーザーと端末だけ」を最小限で許可するのが基本です。(Microsoft Learn)
「Allowed に入れたのにオフラインで使えない」「reveal と auth2 の違いが分からない」「特権アカウントまで複製されそうで怖い」と悩みやすいテーマでもあります。この記事では、RODCのパスワード複製ポリシー（Microsoftドキュメントでは Password Replication Policy / PRP）の見方、設計の判断基準、ありがちな誤解、トラブル時の切り分け、代替策まで、実務にそのまま使える形で整理します。
RODCのパスワード複製ポリシーで本当に決まること
PRP は、RODC がパスワードをキャッシュできるかどうかを決める ACL のような仕組みです。Microsoft の説明でも、PRP は「RODC がパスワードをキャッシュできるかを決める」ためのもので、一覧は「キャッシュを許可するアカウント」と「明示的にキャッシュを拒否するアカウント」に分かれます。Allowed RODC Password Replication Group は既定で空なので、新しい RODC は資格情報をキャッシュしません。また、Denied RODC Password Replication Group は Allowed より優先されます。(Microsoft Learn)
内部の属性名まで覚える必要はありませんが、ツールごとに見ている対象が違うため、ここを混同すると運用がぶれます。
| 見るもの | 実際の意味 | 誤解しやすい点 |
|---|---|---|
| Allowed list | RODC にキャッシュしてよい候補です。Allowed に入っていても、まだ実際にキャッシュ済みとは限りません。(Microsoft Learn) | 「Allowed = もう支店でオフライン認証できる」ではありません。 |
| Denied list | そのアカウントのパスワードを RODC に複製してはいけない一覧です。Denied は Allowed より優先されます。(Microsoft Learn) | 「Denied = その RODC 経由では絶対に認証できない」ではなく、まずはキャッシュ禁止の意味です。 |
| auth2 list | その RODC が認証に関与した主体の履歴です。(Microsoft Learn) | 「auth2 にいる = キャッシュ済み」ではありません。 |
| reveal list | RODC に秘密属性がすでに“reveal”された主体で、運用上は「実際にキャッシュ済みか」を見る一覧です。(Microsoft Learn) | 「Allowed に入れた全員が reveal に出る」わけではありません。 |
1アカウント単位で結果を確実に確認したいなら、Get-ADAccountResultantPasswordReplicationPolicy が便利です。戻り値は Allow / DenyExplicit / DenyImplicit / Unknown で、特に DenyImplicit は「明示的に拒否はしていないが、許可もしていないためキャッシュされない」状態を意味します。グループのネストを見落としていないか確認したいときに役立ちます。(Microsoft Learn)
Get-ADAccountResultantPasswordReplicationPolicy `
-Identity 'BR01-USER01' `
-DomainController 'BR01-RODC'認証の流れを知ると設計を誤らない
RODC での認証は、ざっくり言うと次の流れです。
- ユーザーまたはコンピューターが RODC にサインインを要求します。
- その資格情報がすでに RODC にキャッシュされていれば、RODC はその後のサインインをローカルで処理できます。(Microsoft Learn)
- 認証が成功すると、RODC は PRP を使って、そのユーザーまたはコンピューターの資格情報を今後キャッシュしてよいかを判断します。(Microsoft Learn)
- 許可されていない、またはまだキャッシュされていないアカウントは、書き込み可能な DC に到達できないと AD DS のリソースや機能を使えません。Microsoft の復旧ガイドでも、RODC にキャッシュされていないローカルリソースへの認証要求は writable DC に転送され、writable DC がオフラインなら失敗すると説明されています。(Microsoft Learn)
- さらにパスワード変更直後は注意が必要です。RODC は新しいパスワードを通常レプリケーションで受け取るまで、ハブ DC や PDC を必要とすることがあります。(Microsoft Learn)
ここから分かるのは、PRP は単なる「許可リスト」ではなく、WAN 断時にその拠点だけでどこまで自己完結できるかを左右する設定だということです。支店でオフライン継続を求めるなら、Allowed に入れる対象を慎重に決めないと意味がありません。(Microsoft Learn)
どんな運用に向くか、向かないか
RODC + 最小限キャッシュが向くのは、支店で WAN 断時も一般ユーザーのログオンやローカルリソース利用を続けたいが、RWDC を置くほどの要件や物理セキュリティはないケースです。Microsoft も RODC を、支店などの物理的に安全性が低い環境を想定した読み取り専用 DC と位置付けています。(Microsoft Learn)
逆に、WAN が安定していてオフライン継続が不要なら、Allowed を空のまま、またはかなり絞って運用するほうが安全です。新しい RODC は既定で資格情報をキャッシュしませんし、キャッシュしない運用なら RODC 側に置かれるパスワードの範囲を最小化できます。(Microsoft Learn)
一方で、広い範囲のオフライン継続を求めるのに、パスワードはほとんど持たせたくないという要件は両立しにくいです。キャッシュしないアカウントは writable DC に到達できなければ AD DS の機能を使えないため、この要件が強いなら RODC の設定だけで解こうとせず、RWDC の配置やアプリ構成そのものを見直したほうが現実的です。(Microsoft Learn)
実務で失敗しにくい設計の進め方
許可するのは「拠点で本当に使う人」と「拠点で動く端末」だけ
Microsoft は、RODC には「WAN がオフラインでもその拠点でログオンできる必要があるユーザー」だけをキャッシュさせるべきだと明記しています。実務では、これをそのまま設計原則にするとぶれません。(Microsoft Learn)
具体的には、次のようなサイト専用グループを作ると運用しやすくなります。
BR01-Users-RODC-AllowBR01-Computers-RODC-Allow- 必要なら
BR01-Servers-RODC-Allow
ここで大事なのは、ユーザーだけでなくコンピューターも設計対象だという点です。PRP の説明も、対象を user / computer として扱っています。支店PCや支店サーバーを WAN 断でも安定運用したいなら、ユーザー側だけ Allowed にして満足しないことが重要です。(Microsoft Learn)
Domain Users や Domain Computers を丸ごと許可しない
Allowed の設計で最も多い失敗は、手早く済ませようとして Domain Users や Domain Computers を丸ごと入れてしまうことです。これをやると、「その拠点で本当に必要な最小限」という原則が一気に崩れます。RODC が支店など比較的リスクの高い場所に置かれる前提を考えると、広いグループをそのまま許可するのは避けたほうが安全です。(Microsoft Learn)
特権側はさらに厳格に扱います。Microsoft は、Denied RODC Password Replication Group の既定メンバーを外すとセキュリティ リスクになると警告しており、代表例として Domain Admins、Enterprise Admins、Schema Admins、Cert Publishers、krbtgt などを挙げています。RODC 作成時の既定 deny にも、Administrators、Server Operators、Backup Operators、Account Operators などが含まれます。既定の deny を崩すのは、かなり強い業務上の理由がある場合だけに留めるべきです。(Microsoft Learn)
パイロットでは auth2 を見てから allow を固める
現場では、最初から完璧な Allowed グループを作ろうとして迷いがちです。そんなときは、まず小さく始めて auth2 を観測するほうが現実的です。repadmin /prp view <RODC> auth2 は、その RODC が認証に関与した主体の一覧を見せてくれます。さらに repadmin /prp move は、auth2 に溜まった主体を新しいグループへ移し、必要ならそのグループを Allowed に追加できます。/users_only や /comps_only も使えるので、ユーザー用と端末用を分けて固めやすいです。(Microsoft Learn)
repadmin /prp view BR01-RODC auth2
repadmin /prp move BR01-RODC BR01-RODC-Allow-Users /users_only「実際にその RODC を使ったアカウント」から許可対象を絞り込めるので、設計が机上の空論になりにくい方法です。特に、支店ごとに使う人や端末が明確に分かれている環境で有効です。(Microsoft Learn)
切り替え前に prepopulate する
Allowed に入っていても、まだキャッシュ済みとは限りません。Microsoft も「キャッシュしてよい一覧にあるからといって、RODC がそのパスワードを必ずしもキャッシュ済みとは限らない」と明記しています。支店切り替え前、WAN メンテナンス前、拠点開設前のように「最初のログオンから失敗してほしくない」場面では、prepopulate を使う価値があります。(Microsoft Learn)
repadmin /rodcpwdrepl BR01-RODC HUBDC01 "CN=BR01-USER01,OU=Branch,DC=contoso,DC=com"repadmin /rodcpwdrepl は writable DC 側で PRP を評価し、許可されていないアカウントなら失敗します。つまり、prepopulate は PRP を迂回する裏口ではありません。Allowed 設計が正しいかの確認にも使えます。(Microsoft Learn)
検証は「allowed」「resultant」「reveal」の3段階で見る
実務では、次の順で見ると迷いにくいです。
Get-ADDomainControllerPasswordReplicationPolicy -Allowedで 候補 を確認する。(Microsoft Learn)Get-ADAccountResultantPasswordReplicationPolicyで そのアカウントの最終判定 を確認する。(Microsoft Learn)repadmin /prp view <RODC> revealで 実際にキャッシュ済みか を確認する。(Microsoft Learn)
この3つを分けて見るだけで、「Allowed にあるのに使えない」「一覧にはいないのにキャッシュされているように見える」といった混乱の大半は整理できます。
よくある誤解とトラブルの見分け方
Allowed に入れたのに、WAN断でログオンできない
最初に疑うべきなのは、「Allowed には入れたが、まだ reveal には出ていない」状態です。Allowed はあくまでキャッシュ許可候補であり、実際にキャッシュ済みかは別です。切り替え前に prepopulate するか、writable DC に到達できる状態で一度認証させてから reveal を確認します。(Microsoft Learn)
次に見るのは、ユーザーだけでなくコンピューター側の扱いです。支店PCや支店サーバーが AD 依存の動作を続けるなら、コンピューター アカウントも設計対象です。さらに、パスワード変更直後は新しいパスワードが通常レプリケーションで RODC に届くまで挙動が不安定になりえます。(Microsoft Learn)
ADUC と repadmin で見える一覧が違う
これは珍しくありません。Microsoft のトラブルシュート記事でも、MMC は任意の DC（RODC 自体を含む）から情報を集めるのに対し、repadmin /prp は常に読み書き可能な DC を参照すると説明されています。つまり、問い合わせ先が違うのです。レプリケーション不整合があると、同じ RODC を見ているつもりでも結果がずれます。(Microsoft Learn)
このときは、どちらが正しいかを感覚で決めず、resultant と reveal を併用して切り分けるのが安全です。
PRPは正しそうなのに、reveal に想定外のアカウントが出る
このケースは要注意です。Microsoft は、RODC や Enterprise Read-Only Domain Controllers に誤って Replicating Directory Changes All 相当の権限が与えられると、パスワードを含むすべてのユーザー属性が RWDC のように複製されうると案内しています。PRP だけを見て「設定は正しい」と判断しないことが重要です。(Microsoft Learn)
想定外の reveal が出たら、次を疑います。
- ドメイン パーティションの ACL に余計な複製権限がないか
- RODC の実効グループ メンバーシップに問題がないか
- RODC オブジェクトや Allowed グループのレプリケーション不整合がないか
ここまで確認して初めて、「PRP の設計ミス」なのか「権限の誤付与」なのかを切り分けられます。(Microsoft Learn)
PRPだけで足りないときの代替策・併用策
特権の高い人間のアカウントには Protected Users も選択肢
管理者用の人間アカウントをさらに厳しく守りたいなら、Protected Users グループも検討できます。Microsoft は、このグループが資格情報のキャッシュを防ぎ、NTLM や一部の Kerberos 動作にも制約をかけると説明しています。一方で、オフライン サインインをサポートしなくなるため、支店での一般利用アカウント向けではありません。サービス アカウントやコンピューター アカウントを入れるのも非推奨です。つまり、管理者専用アカウント向けの防御策として使うのが現実的です。(Microsoft Learn)
アプリ独自の秘密属性は、PRPではなく RODC filtered attribute set を検討する
PRP が扱うのは、あくまで「そのアカウントの資格情報を RODC に持たせるか」です。もし AD DS をデータストアとして使うアプリが、独自のパスワードや暗号鍵のような属性を持っているなら、別の対策が必要です。Microsoft は、そのような属性には RODC filtered attribute set を使い、そもそも RODC へ複製しないようにできると説明しています。ただし、システム クリティカル属性は追加できません。(Microsoft Learn)
ハイブリッド認証では、PRPが別の機能に影響することもある
最近のハイブリッド環境では、Windows Hello for Business の cloud Kerberos trust にも PRP 設計が影響します。Microsoft FAQ では、ユーザー資格情報をキャッシュできる RODC に対する認証では cloud Kerberos trust が失敗しうると案内しています。該当環境では、「RODC だからいつも同じ挙動」と考えず、PRP を含めて事前検証したほうが安全です。(Microsoft Learn)
最後に整理すると
RODCのパスワード複製ポリシーを誤解なく理解するコツは、Allowed・Denied・auth2・reveal を別物として扱うことです。Allowed は「キャッシュしてよい候補」、Denied は「キャッシュ禁止」、auth2 は「その RODC が認証に関与した履歴」、reveal は「実際にキャッシュ済み」です。Allowed に入れただけでは終わりではなく、reveal まで確認して初めて「支店で本当に使える」状態か判断できます。(Microsoft Learn)
次にやるべきことは明確です。まず、WAN断でも使い続けたい拠点ユーザーと拠点端末を洗い出します。次に、サイト専用の Allowed グループを作り、既定の Denied を崩さずに適用します。最後に、resultant と reveal で検証し、必要なら prepopulate まで実施します。この順番で進めれば、RODC の PRP は「分かりにくい設定」ではなく、支店運用を安全に成立させるための実用的な制御に変わります。(Microsoft Learn)
コメント