Articles /

Active DirectoryでのFSMOの役割:その役割とその仕組み

Active Directory(AD)は、Microsoftによって作成されたディレクトリサービスであり、Windows Serverオペレーティングシステムのほとんどのバージョンでは、プロセスとサービスのセッ

ADは、ユーザー名、パスワードなど、ユーザーのすべての属性を格納するデータベースまたは安全な場所として想像することができます。 この中央リポジトリは、ユーザーデータの管理、セキュリティの提供、他のディレクトリとの相互運用など、多くのタスクを自動化します。

ADの初期バージョンでは、多くの競合の可能性がありました。 たとえば、ドメインコントローラが新しい従業員をデータベースに追加したとします。 広告に変更が加えられたので、それは企業全体に反映されましたが、それは問題ありません。 数秒後、別のドメインコントローラは、もはや企業で働いていなかった従業員のレコードを削除したいと考えていました。 誤って、それは同様に広告からこの従業員を削除しました。

その後存在していた競合管理システムは”last writer wins”ポリシーに従っていたため、第二のドメインコントローラによって行われた変更は有効でしたが、第一のドメ つまり、新しい従業員はもはやシステムにいなくなり、システムのリソースにアクセスできませんでしたが、これは明らかに正しくありません。

このような競合を防ぐために、シングルマスターモデルが導入されました。 このモデルでは、特定の種類の更新を実行できるのは1つのドメインコントローラー(DC)だけです。 上記の場合、最初のDCだけが従業員の追加と削除を担当し、2番目のDCがセキュリティを担当していた場合、そのような競合は発生しませんでした。

しかし、これにも制限がありました。 最初のDCがダウンするとどうなりますか？ 従業員を追加または削除するには、再度バックアップする必要があります。 単一のコントローラへのこのような重い依存は、運用上の観点からは決して良いことではありません。

だから、マイクロソフトは、各DCに複数の役割を含めるために、各DCに同じ企業内の他のDCに全体の役割を転送する機能を与えるために、後続のバージ ここでの明白な利点は、ロールが特定のDCにバインドされていないため、1つがダウンすると、このロールを別の作業DCに自動的に転送できることです。

このようなモデルは多くの柔軟性を提供するため、Flexible Single Master Operation（FSMO）と呼ばれています。

事実上、FSMOは、すべてのDCに明確な役割と責任を同時に割り当てるマルチマスターモデルであり、必要に応じて役割を転送する柔軟性を与えます。

FSMOの役割

FSMOは大きく五つの役割に分けられており、以下のようになっています:

  • スキーママスター
  • ドメイン命名マスター
  • RIDマスター
  • PDCエミュレーター
  • インフラストラクチャマスター

これらのうち、最初の二つのFSMOの役割はフォレストレベルで利用可能であり、残りの三つはすべてのドメインに必要である。

フォレストとドメインレベルのFSMOの役割

リモート拡張

各FSMOの役割を詳細に見てみましょう。

Schema master

Schema masterは、名前が示すように、ADのスキーマ全体の読み書きコピーを保持します。 スキーマが何であるか疑問に思っている場合は、userオブジェクトに関連付けられているすべての属性であり、パスワード、ロール、指定、従業員IDが含まれてい

だから、従業員IDを変更したい場合は、このDCでそれを行う必要があります。 既定では、フォレストに最初にインストールするコントローラーはスキーママスターになります。

ドメインネームマスター

ドメインネームマスターはドメインの検証を担当するため、すべてのフォレストに1つしかありません。 つまり、既存のフォレストに新しいドメインを作成する場合、このコントローラーはそのようなドメインがまだ存在しないことを保証します。 ドメイン名前付けマスターが何らかの理由でダウンしている場合は、新しいドメインを作成することはできません。

ドメインを頻繁に作成しないため、一部の企業では、同じコントローラ内にスキーママスターとドメイン命名マスターを持つことを好みます。

RID master

セキュリティ原則を作成するたびに、ユーザーアカウント、グループアカウント、マスターアカウントのいずれかにアクセス許可を追加します。 しかし、いつでも変更される可能性があるため、ユーザーまたはグループの名前に基づいてそれを行うことはできません。

あなたが特定の役割を持つアンディを持っていて、彼が会社を去ったとしましょう。 だから、あなたはアンディのアカウントを閉じて、代わりにティムを持って来た。 今、あなたは行くと、すべてのリソースのセキュリティアクセスリストにティムとアンディを交換する必要があります。

これは時間がかかり、エラーが発生しやすいため、実用的ではありません。

これが、すべてのセキュリティ原則をセキュリティIDまたはSIDと呼ばれるものに関連付ける理由です。 このようにして、AndyがTimに変更しても、SIDは同じままになるため、1つの変更だけを行う必要があります。

このSIDには、システム内のすべてのSIDが一意であることを確認するための特定のパターンがあります。 常に文字”S”で始まり、その後にバージョン(1で始まる)と識別子権限値が続きます。 これには、同じドメイン内にあるすべてのSidに共通するドメイン名またはローカルコンピューター名が続きます。 最後に、ドメイン名の後に相対IDまたはRIDと呼ばれるものが続きます。

基本的に、RIDはactive directory内の異なるオブジェクト間の一意性を保証する値です。

SIDは次のようになります。S-1-5-32365098609486930-1029….. ここで1029は、長い一連の数字があなたのドメイン名である間にSIDを一意にするRIDです。

しかし、これも競合につながる可能性があります。 同時に2つのユーザーアカウントを作成したとします。 これらのオブジェクトの両方が同じSIDを持つ可能性があるため、競合が発生する可能性があります。

この競合を回避するために、RIDマスターは各ドメインコントローラに500のブロックを割り当てます。 このようにして、DC1は1から500までのRidを取得し、DC2は501から1,000までのRidを取得します。 ドメインコントローラがRidを使い果たすと、RIDマスターに接続し、このRIDマスターは別のブロック500を割り当てます。

RID Master FSMO role

だから、RID masterは、すべてのSIDが一意であることを確認するために、単一のドメイン内のDcからのRIDプール要求を処理する責任があります。

PDC emulator

PDCはPrimary Domain Controllerの略で、スキーマの読み取り/書き込みコピーを持つドメインコントローラが1つしかなかった時代から来ています。 残りのドメインコントローラは、このPDCのバックアップでした。 そのため、パスワードを変更する場合は、PDCに移動する必要があります。

今日、Pdcはもうありません。 しかし、時刻同期やパスワード管理のようなその役割のいくつかは、PDCエミュレータと呼ばれるドメインコントローラに引き継がれます。

まずパスワード管理を見てみましょう。

あるドメインコントローラに行き、パスワードの有効期限が切れているためにパスワードをリセットしたとしましょう。 次に、別のサイトの別のマシンにログオンし、認証のために別のドメインコントローラに接続するとします。 最初のドメインコントローラがパスワードの変更を他のコントローラに複製していない可能性があるため、ログインが失敗する可能性があります。

PDCエミュレータは、パスワードリセット用のコントローラであることにより、これらの混乱を回避します。 そのため、ログインに失敗したときに私のクライアントはPDCエミュレータに連絡し、パスワードの変更があったかどうかを確認します。 また、間違ったパスワードによるすべてのアカウントのロックアウトは、このPDCエミュレータで処理されます。

パスワード管理以外では、PDC emulatorはエンタープライズシステムで時刻を同期します。 AD認証ではセキュリティのためにkerberosと呼ばれるプロトコルが使用されるため、これは重要な機能です。 このプロトコルの主なタスクは、送信中にデータパケットがネットワークから取り出されたり、改ざんされたりしないようにすることです。

だから、認証プロセス中にサーバークロックとシステムの間に五分以上の差がある場合、kerberosはこれが攻撃であると考え、あなたを認証しません。

いいですが、ここでPDCエミュレータの役割は何ですか？

まあ、あなたのローカルシステムは、ドメインコントローラとその時間を同期し、ドメインコントローラは、順番に、PDCエミュレータとその時間を同期します。 このようにして、PDCエミュレーターは、ドメイン内のすべてのドメインコントローラーのマスタークロックになります。

マイクロソフト

このコントローラがダウンしていると、セキュリティが数ノッチダウンし、パスワードが攻撃に対して脆弱になります。

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

インフラストラクチャマスターのコア機能は、ドメイン内のすべてのローカルユーザーと参照を参照することです。 このコントローラは、それが存在しているオブジェクトを含むドメインの全体的なインフラストラクチャを理解しています。

オブジェクト参照をローカルで更新し、他のドメインのコピーで最新であることを保証します。 この更新プロセスは、一意の識別子、場合によってはSIDを介して処理されます。

Infrastructure masterは、Global Catalog(GC)と呼ばれる別のADツールに似ています。 このGCは、active directory内のすべてがどこにあるかを知っているインデックスのようなものです。 一方、インフラストラクチャマスターは、単一のドメイン内で制限されているため、GCの小さなバージョンです。

さて、なぜここでGCについて知ることが重要なのですか？ GCとinfrastructure masterは同じドメインコントローラーに配置しないでください。 これを行うと、GCが優先されるにつれてインフラストラクチャマスターは機能しなくなります。

一般的に、ドメインコントローラが一つしかない場合、これはあまり重要ではありません。 ただし、複数のドメインコントローラーを持つ大規模なフォレストがある場合は、GCとinfrastructure masterの両方が存在すると問題が発生します。

ここで状況を見てみましょう。 GCサーバーを検索する複数のドメインがあります。 あるドメイン内では、グループメンバーシップに変更を加え、インフラストラクチャマスターはこの変更を認識します。 ただし、ユニバーサルグループに変更が加えられなかったため、GCサーバーは更新されません。 つまり、GCとインフラストラクチャマスターが同期していない可能性があり、これにより認証の問題が発生する可能性があります。 そのため、すべてのドメインにインフラストラクチャマスターまたはGCのいずれかがあることを確認しますが、両方ではありません。

要約

ご覧のとおりです。 FSMOの役割は、active directory内での競合を防止すると同時に、active directory内のさまざまな操作を柔軟に処理できます。 それらは大きく5つの役割に分けることができ、そのうち最初の2つはフォレスト全体の役割であり、残りの3つは特定のドメインに関連します。

組織にFSMOの役割を実装しましたか？ 私たちとあなたの考えを共有してください。

写真提供：ウィキメディア

Leave a Reply