RIDマスターリカバリ機能

すべてのドメインコントローラーが同等であることは誰もが知っていますが、一部はより同等です。 これらの特別なコントローラーは、 オペレーションマスターまたはFSMOマスターと呼ばれます。 これらのロールの所有者には特別な注意が必要です-何かがうまくいかなかった場合、それらをどのように転送し、いつキャプチャするかを計画する必要があります。 Active Directoryドメインをサポートしており、上記のいずれかがニュースである場合は、提供したリンクで記事を読むか、他の場所でそれについて読むことを強くお勧めします。



ただし、誰からも目立つ役割が1つあります。それはRIDマスターです。 このロールを操作するときに必要な追加のアクションを人々が忘れるのを見たことが何度かありました。ActiveDirectory環境をバックアップから復元するとき、またはRIDマスターロールを引き受けるときに覚えておく価値のあることについて話したいと思いました。



rIDAvailablePoolとRID範囲の無効化を覚えているか、さらにはわからない場合は、catにようこそ。



RIDマスター



まず、一般にRIDマスターが必要な理由と、それが回避に役立つトラブルを思い出してみましょう。



ドメイン内の各オブジェクトのセキュリティ識別子(SID)の形式は、 Domain SID-RIDです。 相対識別子(RID)の一意性は、ドメイン内のオブジェクトのSIDの一意性を保証します。 各コントローラーが個別にRIDを生成した場合、その一意性を確保するための明確でシンプルなメカニズムを考案することは困難です。 オブジェクトを作成するたびにRIDを生成するコントローラーを1つ作成すると(スキーマとドメインの命名のウィザードと同様に)、Active Directoryマルチマスターの主なプラスは失われます-ストレージの分散とデータの変更の機能。 したがって、ドメインにはRIDマスターがあり、RIDブロックを各コントローラーに割り当てます。その結果、各コントローラーはオブジェクトの新しいSIDを作成できます(結局、ブロックは単独で使用するために発行されます)。RIDマスターがオフまたは壊れても、システムは動作し続けますブロックサイズにより、アクティブなウィザードがなくてもActive Directoryがしばらく機能するためです。



同じSIDを持つ複数のオブジェクトを取得するのがなぜそんなに怖いのですか? この質問に答えるために、アクセス制御リスト(ACL)とローカルグループがドメインサーバーとワークステーションでどのように機能するかを見てみましょう。 どちらもユーザーの名前ではなく、SIDに基づいてユーザーに権限を付与します(これは、グラフィックスナップインでSIDを表示できる場合があるためです-システムは単に、ユーザーにとって快適な名前にそれを解決できず、そのまま表示します)。









つまり、環境に2つのユーザー、つまり1つのSIDを持つユーザーがいると想像すると、同じ権利を受け取ることになります。 さらに、最も不快なのは、ドメインの2つの異なる部分の管理者がこれらの2人のユーザーに異なるリソースへの権限を与えようとすると、この同じ一致するSIDに権限が発行され、誰が意図したかを判断する方法がないことです。 一般に、これは非常に不快であり、これは許可されません。これは、RIDマスターが正常に処理します。



RIDAvailablePool属性



バックアップからRIDマスターを復元しようとするまで、すべてが順調に行われます。 ここで余談をする必要があります。 バックアップからコントローラー復元する必要はありません 。 コントローラーに問題がある場合は、ドメインからコントローラーを削除し、サーバーをきれいに再配置して、コントローラーとしてドメインに再入力するのが正しいでしょう。 ただし、バックアップが唯一の選択肢であるシナリオがあります。 たとえば、AD DSインフラストラクチャ全体が破壊された場合、復元する必要があります。 何がおかしいのでしょうか?



RIDマスターは、ロールオブジェクトをシステムオブジェクトDOMAIN \ System \ RID Manager $に保存します。









このオブジェクトの属性により、たとえば、ドメイン内の現在のRIDマスターが誰であるかがわかります。 rIDAvailablePool属性に興味があります。









ここには、最後に発行されたブロックとドメインに残っているRIDの数に関する情報が保存されます。 問題は、ADインフラストラクチャがバックアップから復元された場合、この属性の値が廃止されることです。 同時に、サーバーまたはアプリケーションのローカルグループのメンバーシップは、ユーザーとグループのSIDによって指定されます。 つまり、すべてをそのままにすると、新しいオブジェクトは古いオブジェクトの権利を受け取ります。 これを回避するには、rIDAvailablePool値を手動で変更する必要があります。 お気づきの方は、前のスクリーンショットで非常に大きな意味を持っています。 実際、この値は長整数形式で格納され、範囲の上限と下限の両方が含まれています。 表示するには、任意のツールを使用して、大きな整数値の上部と下部を操作できます。 たとえば、 Utilitiesセクションのldpへのラージ整数コンバーター









衝突から身を守るには、このバックアップの取得後にドメイン内のオブジェクトを作成できるよりも明らかに大きい数を追加して、下部を変更する必要があります。 このために、特別なユーティリティはもう必要ありません-一番下に追加する量、一般的に属性に追加する量。



これで、新しいウィザードは新しい値から始まるRID範囲を発行します。 紛争から安全ですか? いや



RID範囲の無効化



新しいRID範囲が正しく発行されることを保証したという事実にもかかわらず、まだ問題が1つあります。バックアップ時に復元されたドメインコントローラーには既に独自の範囲がありました。 この範囲は回復後はどこにも行かず、使用すると問題が発生する可能性があります。



これを回避するには、「 無効化 」操作を実行する必要があります(誰かがより適切なロシア語に出会ったか知っている場合は、コメントで発音してください)。 これを行うには、Microsoftが提供する iRIDPool.vbsスクリプトを使用します 。 このスクリプトをコントローラーで作成し、管理者として実行します。 マイクロソフトは、このような操作を実行するたびに、無効な識別子を使用できなくなるため、RIDドメインで理論的に使用可能な数を減らすように警告しています。



これで、安全になり、何が起こったとしても環境を復元し続けることができます(ADの場合、たとえば、メタデータをクリアしてドメインに新しいコントローラーを導入するなど)。



この記事が、FSMOのすべての役割の中で、特別な注意を必要とするのがRIDマスターである理由を学習または更新するのに役立つことを願っています。



All Articles