FSMOの概要と役割

FSMOが「Flexible Single Master Operation」を略したもので、「フィズモ」と読みます。

ADにおいて、特別な役割を持つマスターのみが行える操作およびロールのことをFSMOと呼称します。

基本的にADは複数のADサーバで冗長構成で構築し、大体の機能はどこのADで行ってもよいようになっています。

ただし、FSMOだけは異なります。

FSMOには5つのロールがありますが、複数のADで構成された環境において、各ロールは特定のADサーバが担当となり、他のADサーバでは操作できないようになっています。

そして、これらのロールを持つADサーバが単一のサーバとなることから、「Single Master」と名前に入っているのです。

また、名前に「Flexible」と入っているように、柔軟にそのロールをもつADサーバは変更が可能です。

運用上、ころころと変えるようなものではないですが、障害発生時には別のADサーバに移行させたり、5つのロールは全て1つのADに置く必要もなく、バラバラのADに配置することで管理者が意図的に配置を最適化することも可能です。

では、なぜFSMOというロールが必要になるのか説明していきます。

ADは前の項でも記載したように複数のADサーバがある場合、基本的にはどのADでも同じ操作ができるようなマルチマスター方式というものを採用しています。

この方式のおかげて、複数のADサーバで負荷を分散しつつ、他のADで発生した変更操作などもAD間でうまく反映してくれています。

ただ、この方式にも問題があり、競合や不整合が発生する可能性がつきまといます。

原則は時間ベースで更新が後だったもので上書きをするということで少し強引にクリアしていますが、厳密に整合性を取る必要がある操作についてはこのような解消法が取れません。

ということで、厳密な整合性が必要な操作については、例外操作としてFSMOという形で分離しシングルマスターのロールで特定ADでのみ操作ができるようにしているのです。

FSMOには5つのロールが存在します。

それぞれロール毎に役目があり、フォレストで1台か、ドメインで1台か、単位が決まっています。

ここでは、各ロールの詳細を紹介します。

FSMOロール名	単位	障害時の致命傷度
スキーママスター	フォレスト単位	中（スキーマ変更が必要でなければ影響少）
ドメイン命名マスター	フォレスト単位	中（新規ドメイン作成時のみ影響）
PDCエミュレータ	ドメイン単位	高（パスワード変更、時刻同期に重大な影響）
RIDマスター	ドメイン単位	小（短期的には影響少、長期的にオブジェクト作成不可）
インフラストラクチャマスター	ドメイン単位	中（単一ドメインでは影響少、複数ドメインで重要）

スキーママスター

スキーママスターは、AD内のスキーマを一元的に管理するロールです。

スキーマというのは、AD内で作成するオブジェクトに設定する属性を定義するものです。



スキーママスターは、フォレストに1台となっており、スキーマを管理する唯一のサーバーです。

例えば、新しいシステムを導入する際にADユーザーの属性「社員番号」という新しい項目を追加したい場合、それを行えるのはスキーママスターだけです。

一度変更されると、その情報はネットワーク内の全てのActive Directoryサーバーに複製され、全てのサーバーが同じ雛形を使うようになります。

スキーママスターに問題が発生しても、日常的なログインや既存のシステム利用には影響しませんが、新しいシステムの導入や設定変更などができなくなる可能性があります。

そのため、重要なサーバーではありますが、常時稼働が絶対に必要というわけではありません。

ドメイン命名マスター

ドメイン命名マスターは、フォレストにおいて1台だけのドメインを管理する唯一のサーバです。

ADのフォレストにおいて、新しくドメインを追加したり、ドメイン名を変更したり、ドメインを削除するなどの操作が可能なロールです。

具体例を挙げると、会社が拡大して「国際営業部」という新しい部門を設立する場合、Active Directoryでは「intl-sales.company.com」といった新しいドメインを作成する必要があるかもしれません。

このような新しいドメインの追加操作を認証し、実行するのがドメイン命名マスターの役割です。

また、このサーバーは、フォレスト内での名前の重複がないように監視する役割も担っています。

例えば、「sales.company.com」というドメインがすでに存在する場合、同じ名前のドメインを別の場所に作成することはできません。

これは、会社内で部門名の重複がないように管理するようなものです。

ドメイン命名マスターに障害が発生した場合、既存のドメインは通常通り機能し続けます。

ユーザーのログインやメール送受信などの日常業務には影響しません。

影響があるのは、新しいドメインを追加したり、ドメイン構造を変更したりする場合のみです。

多くの組織では、このような大規模な構造変更は頻繁に行われないため、ドメイン命名マスターの一時的な障害が即座に大きな問題になることは少ないでしょう。

PDC (Primary Domain Controller) エミュレータ

PDCエミュレータは、ドメインに1台設置する時刻を管理するサーバです。

ドメインで1つなので、複数のドメインを持つフォレストにおいては、複数台のPDCエミューレータがあることになります。

ADに参加するPCやサーバは、時刻同期先としてそのドメインにあるADサーバが指定されます。

ドメインには複数のADサーバが存在することもありますので、時刻同期先は複数のADのどれになるかはわかりません。

PCやサーバがどのADと時刻同期するかわからないので、複数あるADサーバ達は全員同じ時刻になるようにしておかないといけないですよね。

そこで、ドメイン内の複数のAD達の時刻基準となるADサーバをPDCエミュレータと呼びます。


ドメイン内のAD達は、同じドメインにいるPDCエミュレータとなったADサーバと時刻同期をすることで、PCやサーバがどのADサーバに時刻同期に来ても時刻が一致できるようにしているのです。

また、ADユーザーのパスワード関連の操作も担当しています。

パスワードの変更や、アカウントロックのような情報はPDCエミュレータがドメイン内において一元的に管理するようになっています。

PDCエミュレータに障害が発生した場合、即座に目に見える影響が出ることがあります。

パスワード変更が他のサーバーに即座に反映されなくなったり、時刻同期の問題が発生したりする可能性があります。

RID (Relative ID) マスター

RIDマスターは、ドメインに1台設置するもので各ADが発行できるID範囲を管理するサーバです。

発行できるID範囲を管理すると言われてもパッとはわかりづらいですよね。

ADにおいては、SIDと呼ばれるフォレスト全体において一意のIDが振られます。

このSIDは、「ドメイン識別子」と呼ばれるドメインで一意のIDとRIDと呼ばれるドメインの中で振られるIDの組み合わせで成り立っています。


ドメイン識別子がドメインで一意なので、RIDの部分がドメイン内で被らないように割り振らないといけませんよね。

ドメインにはADが複数あることもあります。

各ドメインが好き勝手にRIDを振ってしまうとSIDが被ってしまうオブジェクトも出てきてしまうので、各ADに対して割り振ってよいRIDの範囲というの設定します。

AD①は0001~1000、AD②は1001~2000・・・のような形です。


このようにドメイン内の各ADに対して割り振ってよいRIDを一元的に管理するのがRIDマスターです。

RIDマスターに障害が発生した場合、すぐには問題が表面化しないことが多いです。

各ドメインコントローラーは、あらかじめRIDマスターから受け取った番号の範囲を使い果たすまでは、新しいユーザーやグループを作成できるからです。

しかし、その範囲を使い切ると、新しいアカウントが作成できなくなります。

インフラストラクチャマスター

インフラストラクチャーマスターは、ドメインに1台設置するものでドメイン間のオブジェクト参照を管理するサーバです。

ドメイン間のオブジェクト参照を管理すると記載した通りで、フォレストに複数のドメインがあり、そのドメイン内のオブジェクト間で参照が発生する場合のみ活躍するロールです。

ドメイン間でのオブジェクト参照というのがどういうものかわかりづらいと思うので、解説していきます。

例えば、ドメインA(営業本部)のグループ「営業部」にドメインB(技術本部)のユーザー「山田太郎」が所属しているような状況です。

このような場合、ドメインAのグループにはドメインBのユーザーが所属していますが、実態はドメインBにいます。

ここでドメインAのグループにはドメインBのユーザー情報を複製した「ファントムオブジェクト」と呼ばれるものが作成されます。


この時、ドメインBのユーザー情報に、例えば名前が変わる等の変更が入ってしまった場合どうなるでしょうか？

ドメインBにあるユーザー情報の実態と会うように、ドメインAにあるファントムオブジェクトの情報も更新してあげないといけませんよね。

このようなドメイン間で参照しているオブジェクトを定期的にチェックして、変更があった場合に同期をとるのがインフラストラクチャーマスターの役割です。


インフラストラクチャマスターに障害が発生した場合、影響の大きさは組織のActive Directory構成によって大きく異なります。

単一ドメインのみの環境（つまり、会社に一つの部門しかない場合）では、インフラストラクチャマスターはほとんど何もすることがないため、障害の影響はほぼありません。

複数のドメインがあり、ドメイン間でグループメンバーシップなどの参照が頻繁に行われる環境では、インフラストラクチャマスターの障害は徐々に問題を引き起こす可能性があります。

具体的には、あるドメインのオブジェクトに関する情報が他のドメインで古いままになり、最新の状態が反映されなくなります。

Active Directoryの運用において、FSMO（Flexible Single Master Operations）は決して後回しにしていい概念ではありません。

むしろ、これらの役割の理解と適切な配置こそが、AD環境の安定性を左右します。

FSMOの各ロールは、一見すると個別の機能を果たしているように見えますが、実際にはドメインの統制を保ち、衝突や不整合を防ぐために不可欠な存在です。

FSMOの設計を軽視すれば、リソース競合や認証エラー、オブジェクト管理の混乱といった深刻なトラブルに直面することになります。

特にPDCエミュレーターやRIDマスターの停止は、ユーザーのログオン遅延や新規オブジェクトの作成不能という形で、直接的な影響を与えかねません。

このような問題を未然に防ぐには、FSMOの配置と移譲を適切に行い、ドメインの成長に応じて柔軟に調整していくことが重要です。

FSMOは、ただの理論的な概念ではなく、現場の運用に深く結びついた実践的な要素です。

もし今のAD環境が安定していたとしても、その裏ではFSMOが適切に機能しているからこそ、スムーズに動いているのです。

この知識を深め、正しく運用できるかどうかが、Active Directoryの管理者としての力量を左右するといっても過言ではありません。

本記事の内容を踏まえ、今一度、自身の環境でFSMOが適切に機能しているかを確認し、最適な運用を目指してください。

知識があるかないかで、システムの安全性と可用性に大きな違いが生まれるのです。