はじめに
FSMOロールについて理解が曖昧だったので、検証しながら確認した際の記録を紹介します。
FSMOとは何かを調べれば、本記事に書いてある通りの説明に辿り着けます。ただ、説明だけ読んだだけでは「？」でした。実際に操作することでADについて少しだけ理解が進んだ気がしました。やはり、手を動かすというアプローチは大切です。
FSMOロールとは
FSMO (Flexible Single Master Operations) ロールは、Active Directory (AD) ドメインやフォレスト内で特定の重要な操作を管理するための特定の役割を持つドメインコントローラー (DC) に割り当てられた役割のことです。
以下、５つのロールがあります。なお、最初はチャットCPTに聞いたことを原稿にしていましたが、調べていくうちに嘘が分かり、Microsoftの公式からひっぱってきました。
フォレスト全体でのFSMOロール
- スキーママスター (Schema Master)
- スキーマ操作マスターは、スキーマの変更を管理します。
- ドメイン名前付けマスター (Domain Naming Master)
- ドメイン名前付け操作マスターは、フォレストとの間でドメインと他のディレクトリ パーティション (ドメイン ネーム システム (DNS) アプリ パーティションなど) を追加および削除します。
ドメイン内でのFSMOロール
- RIDマスター (Relative ID Master)
- RID マスター FSMO 役割所有者は、特定のドメイン内のすべての DC からの RID プール要求を処理する単一の DC です。 また、オブジェクトをドメインから削除し、オブジェクトの移動中に別のドメインに配置する役割も担います。
- PDCエミュレーター (Primary Domain Controller Emulator)
- PDC エミュレーターは、クライアント パスワードの変更を処理します。
- インフラストラクチャマスター (Infrastructure Master)
- インフラストラクチャ マスターは、独自のドメイン内のグループに追加される他のドメインのセキュリティ プリンシパルの名前を更新します。
※参考
Windows の Active Directory FSMO 役割
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/active-directory/fsmo-roles
操作マスターの役割の配置を計画する
https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/plan/planning-operations-master-role-placement
つまり何？という人向けに
ADに詳しくないと、「つまり、どれがどんな役割を持ってるの？」ということになります（私が説明を読んでもピンと来なかったらだけかもしれませんが…）。重要な要素なのに理解が及んでいないのは致命的なので、それぞれのロールを持っていない場合に、影響のある操作をした際の挙動を１つ１つ見ていこうと思います。
※ただし、挙動としてエラーにならなかったものや確認できなかったものがありますので、ご了承ください。
検証
構成
■1台目のAD
サーバ名：adsv02
IPアドレス：172.16.1.148
ドメイン：mochi.ricecake24book.com
■2台目のAD
サーバ名：adsv03
IPアドレス：172.16.1.149
ドメイン：mochi.ricecake24book.com
■3台目のAD
サーバ名：adsv04
IPアドレス：172.16.1.150
ドメイン：kome.ricecake24book.com
ステータス確認
全てのFSMOロールを確認する場合は、以下のコマンドで確認できます。
|
1 |
netdom query fsmo |
本記事ではFSMOロールをadsv03に持たせた状態で、adsv02でAD操作を行います。ロールを持っていないとどんな操作が出来ないのか、一例にはなりますが挙動を確認していきます。
スキーママスター
ステータス確認は以下のコマンドです。
※本記事では検証前に対象のロールのステータス（どのサーバが役割を持っているか）を確認してから検証を行います。
|
1 |
Get-ADForest | Select-Object SchemaMaster |
検証内容
スキーママスター（上記説明再掲）
スキーマ操作マスターは、スキーマの変更を管理します。
説明が説明になっていないような気がしますが、実際にスキーマ操作画面を確認して、設定変更を試みてみます。
検証
MMC（マイクロソフト管理コンソール）を開きます。
adsv02を選択し［OK］を選択します。
［OK」を選択します。
各設定に変更を加えようとしても、グレーアウトしていて操作できません。
［属性］についても同様。
比較できないとよく分からないので、操作するADをadsv03に変更します。
先ほどとは違い、新規作成ができるようになっています。
作成画面。
［クラス］についても同様に作成可能です。
ドメイン名前付けマスター
ステータス確認を実施します。
|
1 |
Get-ADForest | Select-Object DomainNamingMaster |
検証操作内容
ドメイン名前付けマスター（上記説明の再掲）
ドメイン名前付け操作マスターは、フォレストとの間でドメインと他のディレクトリ パーティション (ドメイン ネーム システム (DNS) アプリ パーティションなど) を追加および削除します。
名前の通り、ドメインの操作時に影響するようなので、今回はadsv05という関係のないADを子ドメインとして追加してみようと思います。
検証
以下の通り、子ドメインを追加しようとします。
エラーになりました。詳細を確認します。
はっきりと原因が書かれていました。これくらい分かりやすいと検証しがいがありますね。
RIDマスター
ステータスを確認します。
|
1 |
Get-ADDomain | Select-Object RIDMaster |
検証操作内容
RIDマスター（上記説明再掲）
RID マスター FSMO 役割所有者は、特定のドメイン内のすべての DC からの RID プール要求を処理する単一の DC です。 また、オブジェクトをドメインから削除し、オブジェクトの移動中に別のドメインに配置する役割も担います。
RIDの管理者がいない状態となるので、ユーザー作成時の挙動を確認します。
検証
以下はadsv02での操作です。ユーザーを新規登録します。
設定値を入力していきます。
パスワード設定も問題なくできそう…。
完了してしまいました。
MMCコンソールでも実行できるか確認します。
やはり作成できました。
どうやらロールを持っていなくても作成自体はできて、情報も内部的にレプリケーションされている可能性があるみたいです。作成時にエラーになると推測していましたが、予想ははずれました。
ADSV03を停止させた状態ではどうか
もしかするとadsv03と疎通できてしまっているからエラーにならないのかな？と考え、adsv03を停止させてみてから同じことを行ってみました。結果は問題なく作成できました。ロールがなくてもユーザー自体は作成できてしまうみたいです。
さらに1台別にAD追加した場合、そのADからどう見えるか
ADSV04という3台目のADを追加して検証してみました。ADSV02の画面では作成されるものの、管理者がいないと他のADには伝搬されないのでは？と予想しました。
検証内容
ADSV03をRIDマスターにして、停止させる。ADSV02でユーザを作成する。
このとき、ADSV04はレプリケーションされて新しいユーザは見えるか。
結果
ADSV04からも問題なく見えました。管理者がいなくても、内部的にレプリケーションがされるらしいです。
私の力ではRIDマスターがいないことで致命的なエラーを起こせなかったです…。一旦断念します。
PDCエミュレーター
ステータスを確認します。
|
1 |
Get-ADDomain | Select-Object PDCEmulator |
検証操作内容
PDCエミュレータ（上記説明再掲）
PDC エミュレーターは、クライアント パスワードの変更を処理します。
パスワード変更というワードがあるので、ユーザのパスワードを変えてみます。
検証
早速パスワード変更を試してみます。
適当なパスワードに変更します。
エラーなく変更されました。
こちらも内部的にレプリケーションが成立するらしいです。
ADSV03を停止させた状態ではどうか
結果は、問題なくリセットが成功しました。ただし、少し時間がかかりました。もしかするとAD間で更新をかけようとして通信が発生しているかもしれないです。
さらに1台別にAD追加した場合、そのADからどう見えるか
ADSV04という3台目のADを追加して検証してました。
検証内容
ADSV02をRIDマスターにして、停止させた後、ADSV03でユーザのパスワードリセットを実行します。このとき、ADSV04を参照しているクライアントPCで当該ユーザでログインするとき、パスワードはリセット後のものになるのか確認します。。
結果
ADSV04からも問題なく変更後のパスワードでログインできました。やはり内部的にレプリケーションがされるらしいです。
インフラストラクチャーマスター
ステータス確認を行います。
|
1 |
Get-ADDomain | Select-Object InfrastructureMaster |
検証操作内容
インフラストラクチャーマスター（上記説明再掲）
インフラストラクチャ マスターは、独自のドメイン内のグループに追加される他のドメインのセキュリティ プリンシパルの名前を更新します。
他のドメインというのがキーワードです。一つのグループにドメインの違うユーザを所属させることで、ドメイン間をまたぐ操作を行います。
検証
グループスコープを［ユニバーサル］にしてグループを作成します。
以下の通り、ドメインが異なるユーザが登録されている状態を作ります。
以下は作成した側のADでまた画面です。グループに所属せることも閲覧することもできました。
一方、adsv04（変更操作を行っていないAD）で確認すると、他のドメインのユーザが見えません。
なお、上記の［所属するグループ］タブを選択した際に、以下の警告が出ました。
まとめ
検証を通じてどのロールがどのような役割なのか、おおまかな部分を理解することはできたと思います。
正直なところ、FSMOロールの有無の影響をしっかり調べられているような気はしていなく、もっとクリティカルな部分で影響があるのかもしれないです。
とはいえ、FSMOって何？のレベルから簡単な触り部分を知ると言うきっかけを作るには十分かなとも思うので、何かの助けになれば幸いです。
