web-dev-qa-db-ja.com

組織階層を適切にモデル化するためのOUの構造化

ネットワークのActiveDirectoryとグループポリシーでOUを使用して実験しています。ただし、個々の部門を持つことができるようにOUを構造化する正しい方法を見つけるのに少し苦労していますが、より高いレベルの管理ユーザーが組織の階層の下位にある部門のすべての権限を取得することもできます。

私が4つの組織単位を持っているとしましょう

  • 販売
  • マーケティング
  • 会計
  • エグゼクティブ

各部門には独自のドライブマッピングがあり、部門OU内の個々のグループポリシーを通じて設定しました。ただし、この構造の1つの例外は、Executive部門です。これらは会社のリーダーであるため、このOUのユーザーには、単一のドライブだけでなく、すべてのドライブマッピングにアクセスしてもらいたいと思います。ただし、OUは親を1つしか持つことができないため、ExecutiveOUがすべての部門からドライブマッピングポリシーを継承できるようにこれを設定する方法がわかりません。

ドライブマッピングごとに個別のポリシーを設定し、ドライブマッピングポリシーをアクセスしたい各部門にリンクするだけでよいと考えられます。この場合、Executive OUには、ドライブマッピングごとに1つずつ、合計4つのリンクがあります。これはある程度意味がありますが、最も保守しやすい解決策のようには思えません。部門が追加されるたびに、または既存の部門に追加のポリシーが付与された場合は、ExecutiveOUでもこのリンクを複製する必要があります。

私が持っていたもう1つの考えは、各OUのオブジェクトとしてセキュリティグループを使用し、部門のユーザーをOUではなくセキュリティグループに割り当てることでした(例:DOMAIN\Marketing)。ただし、これは私が期待するようには機能しないようです。グループポリシーは、ユーザーが適切なOUに追加された後にのみユーザーに適用されるようであり、ユーザーがどのセキュリティグループに属しているかは関係ありません。

私が考えることができる他の唯一の解決策は、単に部門のポリシーをOUから移動し、代わりにセキュリティフィルタリングに依存してポリシーをさまざまなグループに適用することです。ただし、これは、ほとんどの例とチュートリアルがポリシーオブジェクトの管理を処理する方法ではないようです。代わりに、上記のようにこれらの部門のOUを優先します。

グループポリシーオブジェクトを構造化して、目的を達成するための適切な方法は何ですか?

2
mclark1129

これを処理する適切な方法は、グループポリシーの基本設定を使用して、組織全体のドライブマップに単一のグループポリシーを使用することです。

次に、独自のセキュリティスキームに従って、各ドライブマップにターゲティングルールを設定できます。何があってもセキュリティグループが必要になるため、ターゲットルールとしてOUを使用することはおそらく避けたいと思います。

3
pauska