Active DirectoryにおけるFSMOロールの理解

組織が Microsoft Active Directory 上で運用されている場合、AD の稼働を維持するために 1 台以上のドメイン コントローラーに依存することになります。表面的には、Active Directory はピアツーピアのモデルで動作しているように見えます。つまり、すべてのドメイン コントローラー（DC）が AD オブジェクトを作成、変更、削除する権限を持っています。これは、すべてのドメイン コントローラーが各ドメインのパーティションの書き込み可能なコピーを保持しているためです（唯一の例外は読み取り専用の DC です）。変更や追加が行われると、それらはマルチマスター レプリケーションによって他の DC に同期されます。しかし、重要な一部の操作は、Flexible Single Master Operations (FSMO) ロール、または operation master ロールとして知られる特別なロールが割り当てられた特定の DC に限定されています。

以下では、Active Directory における FSMO ロールの重要性を詳しく説明し、効果的な管理と保護を実現するためのベストプラクティスをいくつか紹介します。

FSMO ロールの概要

FSMO は Flexible Single Master Operations の略で、AD におけるマルチマスター複製モデルの制約に対処するために Microsoft が行った取り組みに由来する用語です。FSMO ロールは、特定の重要なタスクを指定されたコントローラーに割り当て、単一の権限プロセスによる変更を提供することで、Windows ドメイン全体にわたって Active Directory の機能と一貫性を確保します。これらの操作を特定のドメイン コントローラーに集約することで、FSMO ロールは Active Directory 環境の整合性と安定性の維持に役立ちます。

FSMO ロールには5つの種類があります。デフォルトでは、Active Directory domain を作成すると、すべての FSMO ロールがフォレスト内の最初のドメイン コントローラーに割り当てられます。ドメイン管理者は必要に応じて、FSMO ロールをほかのドメイン コントローラーに再割り当てできます。

FSMO ロールが必要な理由

実際の FSMO ロールを詳しく見る前に、それが必要になった背景となるマルチマスター・アーキテクチャを理解しておくことが重要です。

マルチマスター・モデル vs. シングルマスター・モデル

Microsoft の初期のネットワーク アーキテクチャは、単一のサーバーがすべてのユーザーおよびコンピューター オブジェクト アカウントを含む書き込み可能なデータベース コピーを保持するシングルマスター モデルに基づいて構築されていました。このサーバーが、アカウント データベースへの追加や変更を行うことだけを担っていました。ネットワーク内の他のサーバーは、データベースの読み取り専用コピーを維持します。これらのサーバーはユーザーの認証はできましたが、データベースを変更することはできませんでした。マスターがオフラインになったり誤動作したりすると、新しいアカウントを作成できず、既存のアカウントも変更できません。この結果、単一障害点が生じました。

シングルマスター モデルの制限に対処するため、Microsoft は Active Directory（AD）でマルチマスター モデルへ移行しました。このモデルでは、各ドメイン コントローラー（DC）がアカウント データベースの書き込み可能なコピーを保持します。この設計により冗長性と耐障害性が確保されます。つまり、1 台の DC が利用できなくなっても、処理を継続できます。とはいえ、このマルチマスター方式では、複数の DC が同時に矛盾する変更を行おうとする可能性（競合）が生まれます。そうした不整合を防ぎ、AD の整合性とパフォーマンスを維持するために、Microsoft は Flexible Single Master Operations（FSMO）ロールを導入しました。

AD における FSMO ロールの重要性

FSMO ロールを割り当てることで、Active Directory は、スキーマの更新、ドメインの命名、時刻の同期などの重要な処理が、秩序立った一貫した方法で実行されることを保証します。特定の FSMO ロールを保持している DC が停止した場合でも、そのロールを別の DC に転送できるため、継続性が保たれます。FSMO ロールの分散は、バランスの取れた効率的なネットワークを維持するうえで重要であり、組織はパフォーマンスと冗長性（リダンダンシー）に関するベストプラクティスと、固有のニーズに基づいてこの分散をカスタマイズできます。

5 つの FSMO Active Directory ロールを解説

Active Directory には、次の 5 つの独自の FSMO ロールがあります。

• スキーマ マスター（フォレスト レベル）
• ドメイン ネーミング マスター（フォレスト レベル）
• 相対 ID（RID）マスター（ドメイン レベル）
• プライマリ ドメイン コントローラー（PDC）エミュレーター（ドメイン レベル）
• インフラストラクチャ マスター（ドメイン レベル）

各 FSMO ロールと、Active Directory インフラストラクチャ内でのそれぞれの具体的な機能について詳しく見ていきましょう：

スキーマ マスター

What is the schema master FSMO role?

スキーマ マスターはエンタープライズ レベルの FSMO ロールです。したがって、Active Directory フォレスト内にスキーマ マスターは 1 つしかありません。スキーマは、オブジェクト クラス（ユーザー、グループ、コンピューターなどのオブジェクトの種類）と、それらが AD データベース に存在し得る属性を定義します。

スキーマ マスターはいつ、どのように使用されますか？

場合によっては、スキーマを変更する必要があります。たとえば、必須の新しいオブジェクトの種類や属性を追加する場合です。更新が重複したり競合したりするのを防ぐために、AD スキーマへの変更を処理できるのは、スキーマ マスター ロールを持つ DC のみです。スキーマの更新が行われるたびに、スキーマ マスターは変更がフォレスト内の他のすべての DC に複製されるようにします。

スキーマの更新が必要な場合は、スキーマ マスターが利用可能である必要があります。ただし、ほとんどの環境ではスキーマの変更は比較的まれです。スキーマ変更が必要になる可能性がある状況には、Active Directory のアップグレード、特定種類のエンタープライズ ソフトウェアの統合、フォレストの機能レベルの引き上げ、そしてフォレスト内で現在存在するバージョンよりも高いバージョンに DC のオペレーティング システムをアップグレードすることなどがあります。

ドメイン ネーミング マスター

ドメイン ネーミング マスターの役割と責任

ドメイン ネーミング マスターはエンタープライズ レベルの役割であり、Active Directory フォレストにはドメイン ネーミング マスターが 1 つだけ存在します。ドメイン ネーミング マスターは、フォレストに新しいドメインやアプリケーション パーティションを追加したり、既存のものをフォレストから削除したりできる唯一の DC です。

ドメイン ネーミング マスターに関するよくあるシナリオ

事業の変化に伴って AD フォレストを変更する必要が出てくることがあります。また、合併や買収の影響でフォレストに追加のドメインが組み込まれることもあります。ドメインやパーティションの追加・削除は頻繁に行われず、時間的にクリティカルな操作であることもまれであるため、ドメイン ネーミング マスターの役割のオーバーヘッドは小さく、その喪失による運用への影響はほとんどない、またはごくわずかで済むと見込めます。

RID Master

RID Master ロールとは？

Relative Identifier Master (RID Master) はドメイン レベルのロールです。AD フォレスト内の各ドメインには RID Master が 1 台ずつ存在します。各セキュリティ プリンシパル（ユーザーやグループなど）が、そのドメイン内で一意のセキュリティ識別子を持てるようにするため、RID Master は自ドメインの順序に従って DC（ドメイン コントローラー）へ RID プールを割り当てる役割を担います。

SID（セキュリティ識別子）は長さが可変の英数字文字列で、次のような形式をしています。

      `S-1-5-21-1234567890-1234567890-1234567890-1001`
      

文字列の最初の部分はドメイン SID で、同一ドメイン内のすべての SID で同じです。最後の部分は RID で、ドメイン内の各 SID ごとに一意です。上の例では、1001 はそのドメイン内の特定のセキュリティ プリンシパルに割り当てられた RID です。

RID Master の機能と使用方法

RID Master は DC（ドメイン コントローラー）に RID プールを割り当てます。各プールは、固有で連続した RID の範囲で構成されており、DC はセキュリティ プリンシパル（security principal）を作成する際に、その RID を使って一意の SID を生成できます。RID の配布を一元的に管理することで、RID Master は、2 台のドメイン コントローラーが異なるセキュリティ プリンシパルに同じ RID を割り当てないようにし、ドメイン内で各 SID の一意性を保証します。

DC が RID Master から RID プールを割り当てられると、AD オブジェクトを作成するたびに RID Master と通信する必要はありません。とはいえ、ドメインの RID Master を失うと、DC 上のプールが枯渇していくため、最終的にはそのドメインで新しいオブジェクトを作成できなくなります。成熟した AD 環境では、作成されるオブジェクトが比較的少ないため、この状況が発生するまでにかなりの時間がかかります。

一般に、RID Master ロールはドメイン内のプライマリ ドメイン コントローラー（PDC）に割り当てられます。PDC は通常管理者の関心を最も集めやすく、そのため高い可用性を持つからです。成熟したドメインでは、RID Master ロールによって生じるオーバーヘッドはほとんど無視できます。このロールは他の一部のロールほどクリティカルではないものの、RID Master への接続が維持されていることを確認することは依然として重要です。

PDC Emulator (PDCE)

PDC Emulator の役割を理解する：説明と歴史

Primary Domain Controller (PDC) は、Windows NT の時代に使われていた用語で、当時は単一の DC がディレクトリの書き込み可能なコピーを保持していました。現在では、ドメイン内のほとんどの DC は書き込み可能ですが、それでも PDC の役割をエミュレートするよう指定された DC が 1 台あります。Active Directory Forest の各ドメインには、PDCE の役割を持つ DC が 1 台含まれます。

AD における PDC Emulator の機能

Primary Domain Controller Emulator は、次の役割を担います。

• 時刻の同期 — PDCE はドメインにおける権威ある時刻ソースです。すべてのワークステーションとメンバーサーバーは、PDC emulator と時刻を同期します。マルチドメインのフォレストでは、フォレスト ルート ドメインの PDCE が、フォレスト内の他のすべての PDC emulator の時間管理者（timekeeper）になります。フォレスト全体で正確な時刻管理を維持するために、ルート ドメインの PDC emulator は、外部の信頼できる時刻ソースと同期するように設定しておくべきです。時刻は非常に重要です。たとえば、要求元ホストの時計と認証を行う DC の時計の差が、指定された最大値（デフォルトでは 5 分）を超えると、Kerberos 認証は失敗します。これは、リプレイ攻撃（replay attacks）のような特定の悪意ある行為への対策に役立ちます。
• パスワードの変更と認証 —ユーザーのパスワードが変更されると、その変更は最初に、ユーザーを認証した DC で行われます。この確定されたパスワード更新は、直ちにドメインの PDCE に複製されます。アカウントが、予定されたレプリケーションによって最近のパスワード変更をまだ受信していない DC に対して認証を試みた場合、その要求はドメインの PDCE に渡されます。PDCE が認証要求を処理し、要求元の DC に対して受け入れるか拒否するかを指示します。この動作により、最近の変更が予定されたレプリケーションで完全に反映されていない場合でも、パスワードを確実に処理できるようになります。
• アカウントのロックアウト状態 — 同様に アカウントが複数回のログオン失敗によりロックアウトされると、そのロックアウトは直ちに PDC emulator で処理され、ロックアウト状態はドメイン内のすべての DC にレプリケートされます。これにより、ロックアウトされたアカウントが別の DC にログオンできないようにします。管理者がアカウントのロックを解除すると、その変更はドメイン全体を通じて直ちにレプリケートされます。
• グループ ポリシーの更新 — グループ ポリシー オブジェクト（GPO）に更新が行われると、それらは最初に PDC Emulator の役割を持つ DC にコミットされます。これにより、GPO がほぼ同時に 2 台の DC で変更された場合に起こり得るバージョン競合を防止します。
• 後方互換性 — Windows NT に依存するレガシー デバイスやソフトウェアをまだ保有している組織では、PDCE emulator は PDC として機能できます。これには、ネットワーク上のアプリケーションやデバイスに関する情報を収集して配布する Master Browser としての機能も含まれます。
• 分散ファイル システム（DSF） — デフォルトでは、DFS ルート サーバーは定期的に PDCE から更新された DFS ネームスペース情報を要求します。この動作によりリソースのボトルネックが発生する可能性がありますが、Dfsutil.exe RootScalability パラメーターを有効にすると、DFS ルート サーバーは最も近い DC から更新を要求できるようになります。

PDC Emulator ロールは、高い可用性があり、ネットワーク接続が良好で、高性能な DC に配置する必要があります。このロールを担う DC が失われると、運用に対して直ちにかつ重大な影響を及ぼす可能性があるためです。

Infrastructure Master

Infrastructure Master FSMO の役割

Infrastructure Master は、マルチドメインフォレストにおけるドメイン間オブジェクトの参照を扱うことを主な機能とするドメインレベルのロールです。Infrastructure Master は、自身のドメイン内のオブジェクトを、同じフォレスト内の他のドメインのオブジェクトと比較し、それらをglobal catalog サーバーと同期します。

Infrastructure Master が必要になるのはいつか、なぜか

これらの操作は、特定のケースでは不要です。もちろん、AD domain が1つだけの環境では、処理すべきクロスドメイン参照はありません。また、あるドメイン内のすべての DC が global catalog ホストである場合（今日では、ネットワーク帯域がより良いため一般的です）、それらはすべて Infrastructure Master に依存することなく最新の情報を持つことになります。

Infrastructure Master には、次の責任が割り当てられます：

• クロスドメインのオブジェクト参照 — マルチドメインのフォレストでは、あるドメインのオブジェクトが別のドメインから参照されることがあります。典型的な例として、あるドメインのユーザーが別のドメインのセキュリティ グループに追加されるケースが挙げられます。このシナリオでは、別ドメインのユーザーを表すために、グループのドメイン内にプレースホルダー（「phantom object」と呼ばれます）が作成されます。Phantom objects は、削除されたオブジェクトへの永続的な参照と、フォレスト内の別ドメインのオブジェクトを参照するリンク値属性を追跡し、管理します。
• グループからユーザーへの参照の更新 —Infrastructure Master は、クロスドメインのオブジェクト参照においてオブジェクトの SID と識別名（DN）を更新し、フォレスト内のドメイン間で GUID、SID、DN を変換する責任を負います。
• 古くなったオブジェクトのクリーンアップ — Infrastructure Master は、削除された信頼関係に由来するオブジェクトなど、もはや有効ではないオブジェクトがないかを定期的に自ドメインで確認し、それらを削除します。

Infrastructure Master ロールを持つ DC が故障した場合、影響は主に管理上のものになります。その不在中は、フォレスト間のオブジェクト リンク名が正しく解決されない可能性がありますが、フォレスト間のグループ メンバーシップは引き続き機能します。

フォレストおよびドメインのコンテキストにおける FSMO ロール

フォレスト レベルの FSMO ロール

上のリストから分かるとおり、最後の2つの FSMO ロールはフォレスト全体で動作します。つまり、フォレスト内でロールを保持できる DC は1台だけです。言い換えると、すべての Active Directory フォレストには、1つの Schema Master と1つの Domain Naming Master があります。

ドメイン レベルの FSMO ロール

残りの 3 つの FSMO ロールは、単一ドメインの管轄内で動作します。各ドメインには、Infrastructure Master が 1 つ、RID Master が 1 つ、そして PDC Emulator が 1 つあります。各ドメインは、1 つ以上の DC 上で複数のドメインが存在する環境において、この 3 つの FSMO ロールをホストします。

FSMO ロールの管理

FSMO ロールの保有者を特定する

AD 環境で 5 つの FSMO ロールをホストしている DC がどれかを把握することは重要です。FSMO ロールを所有している DC を特定する方法はいくつかあります。すぐに確認するには、次のコマンドを使ってコマンド プロンプトを使用します：

      netdom query fsmo /domain:<DomainName>
      

例を示します：

次のスクリプトを使用して、PowerShellでも行えます。

      (Get-ADForest).Domains |

ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `

Select-Object Domain, HostName, OperationMasterRoles
      

以下は、PowerShellを使用した例です：

Windows Active Directory Toolsを使って、どの DC が FSMO ロールを割り当てられているかも確認できます。Active Directory Users and Computers で、ドメインを右クリックし、以下のように「Operations Masters」を選択します：

次に各タブをクリックして、3つのドメイン FSMO を確認します。

次のものを使用して Active Directory Domains and Trusts t を確認し、右クリックして Active Directory Domains and Trust を選択してから Operations Master を選択することで、どの DC が「Domain Naming Master」ロールを保持しているかを見つけられます（下図のとおり）。

すると、現在のロールの保有者を特定するために、次のポップアップが表示されます。

スキーマ マスター FSMO を特定する手順は、もう少し手間がかかります。Active Directory Schema のスナップインを使用すれば、その情報を確認できます。ただし、そのスナップインは Windows Server では既定で表示されません。アクセスするには、Schmmgmt.dll ファイルを使って登録する必要があります。まず、[スタート] > [ファイル名を指定して実行] をクリックし、[名前を付けて実行]（[開く]）ボックスに regsvr32 schmmgmt.dll と入力します。次に、下図のように [OK] をクリックしてください。

正常に登録できたら、次の手順を行う必要があります：

1. コンソール メニューで Add/Remove Snap-in をクリックし、[追加] をクリック、[Active Directory Schema] をダブルクリックし、[閉じる] をクリックしてから [OK] をクリックします。
2. 左上のペインで Active Directory Schema を右クリックし、[Operations Masters] をクリックすると、スキーマ マスター ロールを保持しているサーバーを表示できます。

以下のスクリーンショットに例を示します：

これにより snap-in にアクセスできるようになり、Active Directory Schema を右クリックして Operations Master を選択できます。

FSMO ロールの移動と強制取得（Seizing）

FSMO ロールを移動するタイミングと方法

Active Directory は FSMO ロールを DC に自動的に割り当てますが、別の DC にロールを転送したい場面もあります。たとえば、現在そのロールが割り当てられている DC を、メンテナンスのために停止する必要がある場合です。ドメイン管理者およびエンタープライズ管理者はいずれも、必要に応じてドメインコントローラ間でこれらのロールを移動する裁量を持っています。

FSMO ロールの奪取

FSMO ロールの転送では、現在の保有者と、対象となるドメイン コントローラーのロールの両方がアクティブであり、ネットワーク接続されている必要があります。現在の FSMO ロール保有者が利用できず、復元できない場合は、ドメイン管理者または企業管理者がそのロールを奪取する必要があります。これはより急な対応となるため、FSMO ロールの奪取は必要な場合に限って実施してください。

ベスト プラクティスとトラブルシューティング

効率を高めるための FSMO ロール配置の最適化

Active Directory 内での FSMO 配置に関して厳格なルールがあるわけではありませんが、次の推奨事項に従うことで最良の結果が得られます。

• PDC Emulator と RID Master は、他のドメイン コントローラーからすぐに利用でき、接続が良好な信頼できるドメイン コントローラーに配置してください。これらの役割は、日常的な Active Directory の活動にとって重要だからです。
• 可能であれば、Infrastructure Master をグローバル カタログ サーバーに配置しないようにしてください。もちろん、すべての DC がグローバル カタログ サーバーである場合は、このことはできません。
• 2 つのフォレスト側の役割（Schema Master と Domain Naming Master）は、あまり頻繁に利用されないため、同じ DC に配置してください。

よくある問題と解決策

FSMO が利用できないことを示す可能性のある重要な事象がいくつかあります。たとえば、Schema Master が停止している場合、AD スキーマの更新を試みるとすべてエラーになります。また、Domain Naming Master にアクセスできない場合は、フォレスト内でドメインの追加や削除もできません。このような状況では、その役割を持っている DC がどれかを確認し、アクセス可能であることを検証する必要があります。

割り当てられた FSMO ロールを持つ DC にアクセスできないことは、複数の要因（例：）によって発生する可能性があります。

• サーバーがオフライン、または電源が落ちている
• ネットワーク接続の問題
• DNS 設定のエラーまたは障害

これらの問題のトラブルシューティングには、ネットワーク全体での接続性を確認するためにネットワーク診断ツールを使用し、SRV レコードを含む DNS 設定を検証し、FSMO ロールを保持しているサーバーの物理的および論理的な健全性を確認する必要がある場合があります。問題が解決しない場合は、別の正常な DC へロールを転送することを検討してください。さらに最終手段として、現在の保有者が恒久的に利用できない場合は、ロールを seizing してください。

FSMO ロールの監視と監査

これらの FSMO ロールは非常に重要であるため、これらのロールを保持しているサーバーを定期的に監視する必要があります。最も基本的なレベルでは、ドメイン コントローラー上のイベント ログを確認できます。特定のイベントによって、FSMO ロールがいつ転送されたのか、または奪取されたのかを示すことがあります。組織によっては、FSMO ロールの変更に関連する履歴データやアラートを持つ監視または管理ソフトウェアを使用している場合もあります。さらに、高度な機能を提供するサードパーティ製ツールも存在します。その一例が Netwrix Auditor for Active Directory です。この製品は FSMO ロールの監視を自動化し、不審または予期しない変更があればアラートで通知します。また、この種の履歴に必要に応じてアクセスできるように、これらの FMSO ロール変更がいつ行われたかを文書化しておくこともベストプラクティスとされています。

Netwrix でできること

見てきたとおり、FSMO ロールは業務の継続性とセキュリティの両方にとって重要です。そのため、FSMO ロールへのすべての変更を監査することが欠かせません。Netwrix Auditor for Active Directory はこの監視を自動化し、不審な変更があれば通知してくれるため、ダウンタイムや data breach に至る前に対処できます。

もちろん、FSMO ロールを保護することはセキュリティ戦略の一部にすぎません。Netwrix Auditor for Active Directory は、必要な中核システムに対する包括的な可視性とコントロールを提供します。Active Directory での変更やその他の活動を継続的に監視・分析して、出現しつつある脅威をいち早く検知し、ビジネスプロセス、ユーザーの生産性、セキュリティへの影響を最小限に抑えるために、迅速かつ効果的に対応できるよう支援します。

結論

AD の FSMO ロールは、表面の下でどれほど多くのことが起きているかを示す一例です。フォレスト レベルの FSMO ロールは毎日必ずしも重大ではないかもしれませんが、ビジネスはドメインの FSMO ロールとサービスに依存しています。定期的に発生することが想定される障害の脅威に加えて、これらのロールは、業務運用を妨害しようとする悪意のある脅威アクターにとって理想的な標的にもなります。つまり、AD 環境の複雑さを把握するための可視性が必要です。

AD サポート チームは、こうした課題に対処するために自動化された監視ツールを導入する傾向がますます強まっています。これらのソリューションにより、次のようなことが可能になります：

• FSMO ロール保有者の状態とパフォーマンスに対する可視性の向上
• FSMO ロール割り当てにおける変更や異常に関するリアルタイム アラート
• 問題が拡大する前に潜在的な問題を事前に特定
• 過去の変更を追跡できる広範な監査機能。

このような先回りのアプローチにより、AD 管理者が AD インフラの健全性と安定性を維持し、組織全体のセキュリティ体制を強化することができます。

よくある質問

FSMO とは何ですか？

FSMO は Flexible Single Master Operations の略です。これらの操作は、競合を防ぎ、ネットワークのスムーズな動作を確実にするために、特定のドメイン コントローラーに割り当てられた特別な責任です。

FSMO とは何で、どのような役割がありますか？

Active Directory はマルチマスター モデルに基づいており、FSMO が指定された権限を指定されたドメイン コントローラーに割り当てます。

5 つの FSMO ロールとは何で、ロールの保有者はどのように確認しますか？

5 つの FSMO ロールは次のとおりです。

• スキーマ マスター：AD スキーマの更新を担当します。
• ドメイン ネーミング マスター：フォレスト内でのドメインの追加または削除を制御します。
• RID（相対 ID）マスター：DC に RID プールを割り当てて、固有のセキュリティ識別子（SID）を作成します。
• PDC（プライマリ ドメイン コントローラー）エミュレーター：パスワードの変更と時刻の同期を処理し、特定の種類の認証のフォールバックとして機能します。
• インフラストラクチャ マスター：他のドメイン内のオブジェクトへの参照を管理します

標準 Active Directory tools と PowerShell を使用すると、これらの FSMO の役割ホルダー（役割保持者）がどのドメイン コントローラーであるかを確認できます。

FSMO の役割はどこに配置されていますか？

既定では、Active Directory フォレスト ルート ドメインの最初のドメイン コントローラーが Schema Master と Domain Naming Master をホストします。各ドメインの最初のドメイン コントローラーが PDC Emulator、RID Master、Infrastructure Master をホストします。Active Directory の管理者は必要に応じて、これらの役割を他の DC に移動できます。

なぜ FSMO の役割を seize するのでしょうか？

ドメイン コントローラーが突然オフラインになった場合、その FSMO の役割は利用できなくなります。元の役割ホルダーに接続できない場合は、役割の転送（role transfer）はできません。その場合は、役割を seize して別の DC に割り当てる必要があります。

最も重要な FSMO ロールは何ですか？

すべての FSMO ロールは重要ですが、PDC Emulator はドメインの時刻、パスワードの変更、そして グループ ポリシー の構成を管理するため、最も重要です。場合によっては、レガシー システムが認証要求を処理する唯一の手段としてそれに依存していることがあります。

FSMO ロールはどのように確認しますか？

どのドメイン コントローラーが Active Directory の FSMO ロールを保持しているかを確認する方法はいくつかあります。1 つは、コマンド プロンプトで “netdom query fsmo” コマンドを使用することです。また、Active Directory のツールや PowerShell を使って、各ロールをホストしているサーバーがどれかを調べることもできます。

FSMO ロールはどこに配置すべきですか？

AD 環境にドメイン コントローラーが 1 台または 2 台しかない場合、この点について選択肢はあまりありません。すべての FSMO ロールは、フォレスト内のほかのすべての DC と良好な接続性を持つ DC に割り当てる必要があります。可能であれば、Infrastructure Master をグローバル カタログ サーバーに配置しないでください。

どの FSMO ロールは一緒に配置すべきですか？

Schema Master と Domain Naming Master の 2 つのフォレスト レベルの FSMO ロールは同じ DC に配置するのが望ましいですが、これはあくまで推奨です。

Active DirectoryのFSMOロールとは何ですか？

Microsoftは、5つの重要な操作に対して特定のドメインコントローラーを唯一の権限として指定することで、競合のリスクを軽減しました。これらはFlexible Single Master Operations（FSMO）ロールであり、これらを理解することは安定した適切に管理されたActive Directory環境の管理に不可欠です。

Active Directory は、すべてのドメインコントローラーがドメインパーティションの書き込み可能なコピーを保持するマルチマスターモデルで動作します。この設計により、個々のDCがオフラインでも操作が継続される耐障害性が得られますが、競合する変更が発生する可能性もあります。

このガイドでは、5つのFSMOロールそれぞれを説明し、どのドメインコントローラーがそれらを保持しているかを特定する方法、および状況に応じてロールを転送または奪取するために必要なコマンドを提供します。

5つのFSMOロールのそれぞれは、2つのスコープのいずれかに属します：

デフォルトでは、フォレスト内で最初のドメインコントローラーを昇格させると、5つのFSMOロールすべてがそのDCに割り当てられます。環境の成長や運用ニーズの変化に応じて、管理者がこれらを再配分できます。

FSMOはFlexible Single Master Operationsの略で、1回に1つの指定されたドメインコントローラーのみが処理できる5つのActive Directory操作を指します。これらの操作をスコープごとに単一の権限あるDCに制限することで、複数のコントローラーが同時に実行しようとした場合に発生するデータ衝突をActive Directoryが防止します。

Netwrix AuditorはActive DirectoryのFSMOロール割り当てを監視し、計画されたメンテナンス時間外でのロール転送または取得が発生した場合にチームに通知します。デモを申し込む

なぜマルチマスター複製にはシングルマスター操作が必要なのか

フォレストスコープのロールは、フォレストに含まれるドメイン数に関係なく、ADフォレスト全体で正確に1つの所有者がいます。ドメインスコープのロールは各 Active Directory ドメインごとに正確に1つの所有者がいるため、3つのドメインがあるフォレストには3つのRID Masters、3つのPDC Emulators、および3つのInfrastructure Mastersがあります。

FSMO ロールの重要性

コンフリクト防止

初期のネットワークディレクトリサービスはシングルマスターモデルに依存していました。1台のサーバーがアカウントデータベースの書き込み可能なコピーを保持し、他のすべては読み取り専用のレプリカを保持していました。このモデルは競合を防ぎましたが、単一のサーバーへの強い依存を生みました。サーバーがオフラインになると、新しいアカウントを作成したり既存のアカウントを変更したりできませんでした。

FSMOロールはActive Directoryを一貫性があり、安全で回復可能な状態に保ちます。その重要性は、ドメインコントローラーが故障したり、プレッシャー下でロールの移行が必要になったり、攻撃者がロール保持者を狙ったときに初めて明らかになります。

Active Directory はそのモデルをマルチマスター レプリケーションに置き換えました。すべてのドメイン コントローラーはディレクトリのローカルコピーに書き込みができ、変更はスケジュールされたレプリケーションを通じて他のすべてのコントローラーに伝播します。この設計は回復力を提供しますが、2つのコントローラーが同時に動作するとディレクトリが破損する特定の操作を露呈します。FSMO ロールは、マルチマスター モデルが安全に動作できない場所で単一マスターの権限を強制することでこれを解決します。

認証の信頼性

セキュリティ体制

指定されたシングルマスター権限がない場合、2つのドメインコントローラーが同時に競合する操作を処理する可能性があります。1つは新しいユーザーアカウントにRID 1050を割り当て、もう1つは同じRIDを別のアカウントに割り当てる、または2人の管理者が互換性のない属性定義でスキーマを拡張する場合です。どちらの場合も、解決策のないディレクトリの破損が発生します。FSMOロールは、各重要な操作に対して常に1つの権威あるソースが存在することを保証します。

災害復旧

5つのFSMOロールとは何ですか

PDC EmulatorのFSMO指定は、ヘルプデスクがアカウントのロックを解除し、ドメイン全体で数秒以内に反映させることができる理由です。これがなければ、Kerberos authenticationの判断は、その時点で特定のDCが保持しているパスワードのバージョンに依存し、最近のパスワード変更とログイン試行の間に競合状態が発生します。パスワード処理の単一マスターモデルは、すべてのDCに認証失敗時の既知のエスカレーション経路を提供し、その経路は1つのDCがPDC Emulatorの役割を持つことでのみ機能します。

5つのFSMOロールのうち3つは、高価値の攻撃シナリオの経路上に直接位置しています。Schema Masterは攻撃者がディレクトリスキーマを拡張して永続化メカニズムを導入できるかを制御します。RID MasterはSIDの割り当てを制御し、RIDの操作はprivilege escalationおよびSID履歴攻撃の既知のベクターです。PDC Emulatorは認証とアカウントロックアウトを処理し、ドメインアクセスを維持したりロックアウト警告を抑制しようとする者にとって主要なターゲットとなります。

Active Directoryは5つのFSMOロールを定義します。Schema MasterとDomain Naming Masterはフォレストレベルで動作します。RID Master、PDC Emulator、およびInfrastructure Masterはドメインレベルで動作します。

1. スキーママスター

FSMO ロールを持つドメインコントローラーが障害を起こした場合、復旧経路はチームがどのロールを保持していたか、障害が一時的か永久的かによって異なります。ロールの割り当てを追跡しない組織は、プレッシャーの中で問題を発見します。新しいユーザーアカウントが作成できなくなったり、時間同期がずれたり、Group Policy の更新が停止したりします。ロール保持者を文書化し、転送手順をテストすることがADの回復力の運用基盤です。

各フォレストには1つのSchema Masterがあります。Active Directory databaseのスキーマはすべてのオブジェクトクラス（ユーザー、グループ、コンピューター、プリンターなど）と、それらのオブジェクトが持つことができるすべての属性を定義します。スキーマの変更はSchema Masterのみが書き込めます。

2. ドメイン命名マスター

各フォレストには1つのDomain Naming Masterがあります。フォレストからドメインやアプリケーションパーティションを追加または削除する権限を持つ唯一のドメインコントローラーです。

スキーマの更新はまれです。フォレストの機能レベルを上げたり、Active Directoryを新しいバージョンにアップグレードしたり、スキーマを拡張するエンタープライズソフトウェア（Exchange Serverが一般的な例）を統合したり、フォレストに新しいWindows Serverのオペレーティングシステムバージョンを導入したときに発生します。これらの操作を成功させるには、Schema Masterがオンラインでアクセス可能である必要があります。

コミットされると、スキーマ変更はフォレスト内のすべてのドメインコントローラーに複製されます。スキーママスターがオフラインの場合、スキーマ更新の試行は失敗し、DCに再びアクセス可能になるまで操作は完了しません。

3. RID Master

SIDは次の構造に従います:

組織のディレクトリ構造が変更されるときにDomain Naming Masterとやり取りします。子ドメインの追加、不要なドメインの削除、または買収した会社のドメインの吸収が該当します。これらの操作はまれで、時間的に重要でないため、Domain Naming Masterの可用性要件はドメインレベルの役割よりも低くなっています。短時間のDomain Naming Masterの停止は日常業務に影響を与えません。

RID Masterは、RIDプールをドメインコントローラーに割り当てることでこの一意性を維持します。DCが新しいセキュリティプリンシパルを作成する必要がある場合、毎回RID Masterに問い合わせるのではなく、割り当てられたプールからRIDを取得します。プールが不足すると、DCはRID Masterに新しいプールを要求します。

RID Masterがオフラインになると、ドメインコントローラーは既存のRIDプールを使ってオブジェクトの作成を続けます。大規模なプールを持つ成熟した環境では、これが長期間続くことがあります。最終的にすべてのDCプールが使い果たされると、オブジェクトの作成が失敗します。

4. PDC エミュレーター

各ドメインには1つのRID Masterがあります。Active Directory内のすべてのセキュリティプリンシパル（ユーザー、コンピューター、グループ）には一意のセキュリティ識別子（SID）が必要です。SIDはドメイン全体のプレフィックスと相対識別子（RID）で構成されます。RID部分がドメイン内で各SIDを一意にします。

各ドメインには1つのPDCエミュレーターがあります。これは他のどのFSMOロールよりも多くの責任を負い、日々のドメイン運用に最も直接的な影響を与えます。PDCエミュレーターは以下を担当します：

ドメイン SID はドメイン内のすべてのオブジェクトで同じです。最後のセグメント（この例では1001）は、特定のセキュリティプリンシパルに割り当てられた RID です。

• 時刻同期: PDCエミュレーターは、そのドメインの権威ある時刻ソースです。すべてのワークステーションとメンバーサーバーはこれに時刻を同期します。マルチドメインフォレストでは、フォレストルートドメインのPDCエミュレーターがフォレスト内の他のすべてのPDCエミュレーターの時刻管理者として機能します。ルートドメインのPDCエミュレーターは信頼できる外部時刻ソースと同期する必要があります。クライアントと認証DC間の時刻差が5分を超えるとKerberos認証が失敗するため、正確な時刻は必須です。
• アカウントロック処理： account lockoutが発生すると、PDCエミュレーターは即座に処理し、ドメイン内のすべてのDCにロックアウト状態を複製します。管理者がアカウントのロックを解除すると、PDCエミュレーターは変更を即座に複製します。
• パスワードの変更と認証： ユーザーがパスワードを変更すると、その変更は即座にPDC Emulatorに複製されます。ユーザーがまだ通常の複製で更新されたパスワードを受け取っていないDCに対して認証を試みると、そのDCは認証要求をPDC Emulatorに転送します。これにより、最近のパスワード変更がスケジュールされた複製を通じてまだ伝播していなくても、ドメインは有効な資格情報を受け入れます。

PDCエミュレーターを、高性能でドメイン内の他のすべてのコントローラーと良好なネットワーク接続を持つDCに配置してください。故障すると運用に即時かつ明確な影響があります。

• DFS名前空間の同期: デフォルトでは、DFSルートサーバーはPDC Emulatorから更新された名前空間情報を要求します。大規模環境ではリソースのボトルネックが発生する可能性があります。Dfsutil.exeのRootScalabilityパラメーターを有効にすると、DFSルートサーバーは代わりに最も近いDCから更新を要求できます。

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

• Group Policyの更新： の変更は Group Policy Object をPDCエミュレーターの役割を持つDCに最初にコミットします。これにより、2人の管理者が異なるDCで同じGPOを同時に編集した場合に発生するバージョン競合を防ぎます。

各ドメインには1つのInfrastructure Masterがあります。主な責任は、マルチドメインフォレスト内で正確なドメイン間オブジェクト参照を維持することです。

Infrastructure Masterがオフラインになると、クロスドメインのオブジェクト名が正しく解決されない場合があります。クロスドメインのグループメンバーシップは引き続き機能するため、運用への影響は主に管理上のものです。

FSMOロール保持者の見つけ方

Infrastructure Masterが不要になる条件は2つあります。単一ドメインのフォレスト（ドメイン間参照が存在しない）と、すべてのDCがグローバルカタログサーバーである環境（十分なネットワーク帯域幅を持つ現代的な環境で一般的）です。どちらの場合も、すべてのDCはInfrastructure Masterに依存せずに最新のドメイン間情報を保持しています。

あるドメインのユーザーが別のドメインのセキュリティグループに追加されると、Active Directory はグループのドメインにプレースホルダーオブジェクト（ファントムオブジェクトと呼ばれる）を作成してクロスドメインユーザーを表します。Infrastructure Master はこれらのファントムオブジェクトをグローバルカタログと同期して最新の状態に保ちます。また、削除された trusts またはドメイン のオブジェクトへの参照を削除して、古くなったオブジェクトをクリーンアップします。

netdom query fsmo の使用

PowerShellの使用

ターゲットドメインの完全修飾ドメイン名に <DomainName>Expand を置き換えてください。出力には各役割を保持するDCのホスト名が表示されます。

この netdomExpand コマンドは、RSATがインストールされたドメイン参加済みのWindowsマシン、またはドメインコントローラー上で実行されます。単一のクエリで5つの役割保持者をすべて返します：

Active Directory管理ツールの使用

PowerShellはより細かい制御を提供し、複数ドメインの環境でうまく機能します。以下のスクリプトはフォレスト内のすべてのドメインを照会し、FSMOロールが割り当てられているすべてのDCを返します：

どのドメインコントローラーが5つのFSMOロールを保持しているかを知ることは、計画されたメンテナンスとインシデント対応の両方において前提条件です。組み込みのActive Directory management toolsを使用して3つの方法があります。

RID Master、PDC Emulator、および Infrastructure Master を見つけるには：

1. Active Directory ユーザーとコンピューターを開きます。

より簡単なドメイン別クエリには、Get-ADDomainExpand と Get-ADForestExpand を直接使用してください:

GUIツールは Active Directory Users and Computers でドメインレベルの3つのFSMOロールを表示します。

1. 左ペインでドメイン名を右クリックし、Operations Mastersを選択します。
2. Active Directory Domains and Trustsを開きます。

Domain Naming Master を見つけるには:

1. ダイアログには現在のDomain Naming Masterが表示されます。
2. 現在の役割保持者を表示するRID、PDC、およびInfrastructure タブを確認してください。
3. 左側のペインで Active Directory Domains and Trusts を右クリックし、Operations Master を選択します。

Schema Master を見つけるには： Active Directory Schema スナップインはデフォルトで読み込まれません。最初に登録してください：

FSMO ロールの転送方法

1. ファイル名を指定して実行ダイアログ（Win + R）を開き、regsvr32 schmmgmt.dll と入力します。Expandクリックしてください OK。

3. 左側のペインで Active Directory Schema を右クリックし、Operations Master を選択して現在のSchema Masterを表示します。

2. MMC（mmc.exeExpand）を開き、ファイル > スナップインの追加/削除に移動して、Active Directory Schemaを追加します。

転送は、FSMOロールを現在の所有者から別のDCに移動し、両方のコントローラーがオンラインで通信している間に行われます。計画された操作には、DCの廃止、負荷や冗長性のためのロールの再分配、古くなったハードウェアの交換に転送を使用してください。

PowerShell経由での転送

単一の役割を転送する:

5つの役割すべてを一度に転送：

転送を開始する前に、両方のDCがオンラインでアクセス可能かつ正常にレプリケーションされている必要があります。レプリケーションの状態は repadmin /replsummaryExpand で確認してください。

PowerShellは、特に複数の役割を一度に移動する場合に、役割を転送する最も効率的な方法です。Move-ADDirectoryServerOperationMasterRoleExpand コマンドレットは5つの役割すべてを処理します。

GUI経由の転送：

5つの役割名の値は SchemaMaster、DomainNamingMaster、PDCEmulator、RIDMaster、および InfrastructureMaster ですExpand。

FSMO ロールを取得する方法

宛先DCのNetBIOS名またはFQDNに TargetDCName Expandを置き換えます。PowerShellは各役割の移行前に確認を求めます。スクリプトシナリオでプロンプトを抑制するには -Confirm:$falseExpand を追加してください。

転送後は必ず netdom query fsmoExpand を実行して新しい役割の割り当てを確認してください。

ntdsutilを使ったロールの取得:

取得する前に、元のDCの復元または回復を試みてください。回復が不可能な場合は取得を進め、元のDCを降格せずにドメインに再参加させないようにしてください。

RID Master、PDC Emulator、および Infrastructure Masterの場合：ADUCを開き、Operations Mastersに移動して該当するタブを選択し、Changeをクリックします。Domain Naming Masterの場合：Active Directory Domains and Trusts > Operations Master > Changeを使用します。Schema Masterの場合：Active Directory Schemaスナップイン > Operations Master > Changeを使用します。

接続後、各ロールを個別に取得してください:

Seizureは、元の所有者との調整なしにFSMOロールを新しいDCに強制的に割り当てます。現在のロール所有者が永久にオフラインで回復不可能な場合にのみseizureを使用してください。元の所有者がネットワークに戻る可能性がある場合はロールをseizeしないでください。seizure後に以前のロール所有者をオンラインに戻すと、手動での修復が必要なスプリットブレイン状態が発生します。

役割を受け取るDCで管理者権限のコマンドプロンプトを開き、ntdsutilExpandを実行します。次に、以下の手順に従ってください：

すべての押収が完了したら、ntdsutilを終了するには quit Expandを2回入力してください。

FSMOロール配置のベストプラクティス

次のコマンドで新しい割り当てを確認してください：netdom query fsmoExpand それらの役割に依存するサービスをオンラインに戻す前に。

役割の配置はADの安定性と復旧時間に直接影響します。次を確認してください：Active Directoryセキュリティのベストプラクティスガイド これらの役割固有のガイドラインとともに、より広範な強化推奨事項のために：

• 可能な場合は、役割を物理的な場所に分散させてください: マルチサイト環境では、プライマリサイトのDCに役割を配置することで、役割依存の操作におけるWAN依存を減らせます。プライマリサイトがオフラインになった場合に迅速に役割を移動できるよう、文書化された転送計画と組み合わせてください。
• あまり使用されていないDCにSchema MasterとDomain Naming Masterを一緒に配置： これらのフォレストレベルの役割はめったに呼び出されません。同じDCにまとめることで、パフォーマンスのボトルネックを作ることなく管理が簡素化されます。

これらの配置決定をサポートするためのドメインコントローラーの設定および構成に関するガイダンスについては、Netwrixのドメインコントローラー展開ガイドを参照してください。

Netwrix AuditorがFSMOロールの変更を監視および監査する方法

• ドメイン内で最も信頼性の高いDC上のPDCエミュレーターとRIDマスター： 両方の役割は高い可用性が必要です。PDCエミュレーターの障害は即座にユーザーに影響を与えます。RIDマスターの障害はプールが枯渇するにつれて時間とともに蓄積されます。最も信頼性が高く、接続が良好なDCに配置してください。
• グローバルカタログサーバー以外のInfrastructure Master： すべてのDCがグローバルカタログサーバーでない環境では、Infrastructure Masterはグローバルカタログのコピーを持たないDCで実行する必要があります。グローバルカタログを持つInfrastructure Masterは更新すべきファントムオブジェクトを見つけられないため、ドメイン間の参照を最新の状態に保つことができません。ドメイン内のすべてのDCがグローバルカタログサーバーである場合（現代の環境で一般的）、この制限は適用されません。

FSMOロール変更のリアルタイムアラート

Netwrix Auditor for Active Directoryは、ネイティブログがキャプチャする内容とセキュリティチームが対応すべき内容のギャップを埋めます。

Active Directoryは、役割を受け取ったドメインコントローラーで記録され、前の保持者を示すディレクトリサービスのイベントログのイベントID 1458の下にFSMOの移行を記録します。このイベントは移行が行われたことを確認しますが、調査に必要な完全なアカウントコンテキストやセッションの詳細は提供しません。

ディレクトリ全体で監視すべき内容を完全に把握するには、Active Directory auditing guidelines は追跡すべきイベントの全範囲をカバーしています。

不正なFSMOロールの移譲または奪取は、通常の運用障害を超える影響をもたらす確認されたAD攻撃ベクターです。ドメインコントローラーで十分な権限を得た攻撃者は、PDC Emulatorロールを奪取して認証要求を傍受したり、時刻同期を操作したり、ドメイン全体のGroup Policyの配布を制御したりできます。これらの変更は、行為者や意図を特定するのに十分なコンテキストがなく、Windowsのネイティブイベントログに表示されないことがあります。

完全な前後の監査記録

Netwrix AuditorはFSMOロールが転送または奪取された瞬間にアラートを送信します。アラートは、変更がPowerShell、GUI、またはntdsutilを介して行われたかどうかに関係なく発生し、変更を開始したアカウント、ソースのワークステーション、およびタイムスタンプが含まれます。チームは計画された転送をすぐに確認し、さらなる被害が発生する前に認識されていない変更をエスカレーションできます。

コンプライアンス対応レポート

計画された転送と無許可の押収を区別する

すべてのFSMOロール変更は、前のロール保持者、新しいロール保持者、操作を実行したアカウント、および変更の正確な時刻とともに記録されます。Windowsのネイティブイベントログにはこのコンテキストが含まれていません。インシデントの再構築が必要な場合（内部調査または外部監査のため）、複数のドメインコントローラーからのログ集約に頼らずに完全な記録が利用可能です。

Netwrix Auditor はアカウントとセッションの完全なコンテキストをキャプチャするため、チームは役割変更を変更管理記録と照合できます。スケジュールされたメンテナンス期間中に名前付き管理者アカウントによって実行された移行は、以前に管理活動のないアカウントによる占有とは異なります。監査証跡により、その区別が明確かつ正当化されます。

デモをリクエストして、NetwrixがFSMOロールの変更を監査し、すべてのActive Directoryの変更を追跡し、セキュリティチームが必要とする調査準備済みの証拠を生成する方法をご覧ください。

FSMOロールの割り当ては、特権アクセスの範囲の一部であり、SOX、HIPAA、およびISO 27001の監査で調査されます。Netwrix Auditorは、手動でログを抽出することなく、監査人の要求を満たすActive Directoryの特権変更に関する事前作成済みレポートを生成します。ロール変更の履歴は保持され検索可能であるため、コンプライアンス証拠は必要に応じて利用可能であり、急いでまとめる必要はありません。