異なるフォレストのドメイン ユーザーへの権限の大規模な割り当て

どうやら私のカルマは、あらゆる種類の簡単ではない方法で標準タスクを実装することです。誰かが問題について異なるビジョンを持っている場合は、問題を解決できるように話し合ってください。

ある晴れた朝、ドキュメント フォルダーを持つプロジェクトのサブフォルダーを含むさまざまな共有に対する権利をユーザー グループに配布するという興味深いタスクが発生しました。すべて問題なく、フォルダーに権限を割り当てるスクリプトが作成されました。そして、グループには異なるドメイン、異なるフォレストのユーザーを含める必要があることが判明しました (それが何であるかを忘れた人のために）。共有自体が Synology メディア上にあり、PSI フォレストの FB ドメインに登録されているとします。タスク: 別のフォレスト内のドメインのユーザーがこの共有のコンテンツに非常に選択的にアクセスできるようにします。

しばらくして、技術仕様は次のような形式になりました。

• 2 つのフォレスト: PSI フォレスト、TG フォレスト。

  

• 各フォレストには 3 つのドメインがあります。PSI (ZG、PSI、FB)。 TG (TG、HU、KC)。
• フォレスト間には信頼関係があり、Synology はすべてのフォレスト内のすべてのセキュリティ グループを認識します。
• 共有およびフォルダ/サブフォルダには、FullControl 権限を持つ FB ドメイン管理者アカウントが必要です
• フォルダーの名前は体系化する必要があります。管理者がプロジェクト ID を調整し、私はセキュリティ グループの名前をプロジェクト ID にリンクすることにしました。
• システム共有内のプロジェクト フォルダーには、適切なアクセス権限 (R/RW/NA、NA – アクセス権なし) を持つ .xlsx ファイル内に事前に準備された構造が含まれている必要があります。

  

• 1 つのプロジェクトのユーザー/グループ メンバーの権限を、そのプロジェクトの特定のディレクトリのみに制限できる必要があります。グループのメンバーシップによっては、ユーザーは他のディレクトリ/プロジェクトにアクセスできない場合があります。
• プロジェクト フォルダーを作成するときは、プロジェクト ID に対応する名前を持つグループが、適切なドメインにできるだけ自動的に作成される必要があります。

技術仕様に関する注記

• 信頼関係の設定は技術仕様の範囲に含まれていません
• プロジェクト ID には数字とラテン文字が含まれています
• すべてのドメインのプロジェクト ユーザー ロールには標準名が付いています
• プロジェクト全体の開始前に、フォルダーとアクセス権 (アクセス マトリックス) を含む .xlsx ファイルが準備されます。
• プロジェクトを実施する際、対応するドメインにユーザーグループを作成することが可能
• 標準の MS Windows 管理ツールを使用して自動化を実現します

技術仕様の実装

これらの要件を形式化した後、ディレクトリを作成し、ディレクトリに権限を割り当てる方法をテストするために戦術的な一時停止が行われました。プロジェクトを複雑にしないために、PowerShell のみを使用することを目的としていました。前に書いたように、スクリプト アルゴリズムは非常に単純に見えました。

• プロジェクト ID から派生した名前 (KC40587 など) と、アクセス マトリックスで指定された対応する役割を持つグループを登録します。KC40587-EN- エンジニア用。 KC40587-PM – プロダクトマネージャーなど向け
• 作成されたグループの SID を取得します
• プロジェクト フォルダーと対応するディレクトリのセットを登録します (サブフォルダーのリストは、サブフォルダーが作成され、アクセス マトリックスで定義されている共有によって異なります)。
• アクセス マトリックスに従って、プロジェクトの新しいサブディレクトリに対する権限をグループに割り当てます。

ステージ 1 で遭遇した困難:

• スクリプト内でアクセス行列を指定する方法の誤解 (現在、多次元配列が実装されていますが、それを埋めるためのパスは .xlsx ファイル/アクセス行列の内容に基づいて検索されています)

  

• PoSH を使用して Synology ドライブ上の SMB 共有にアクセス権を設定できない (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-) nas -share?forum=winserverpowershell) のため、多くの時間が失われ、icacls アクセス権編集ユーティリティを使用してすべてをスクリプトに適合させる必要があり、テキスト ファイルと cmd ファイルの中間リポジトリの作成が必要でした。

現在のモードでは、プロジェクトのフォルダーを登録する必要性に応じて、cmd ファイルの実行が手動で制御されます。

また、このスクリプトは他のフォレストのグループを登録するためにも実行する必要があり (クロスドメインという用語が使用されました)、比率は 1 対 1 だけでなく、XNUMX 対多の場合もあることも判明しました。

これは、隣接するフォレストを含む他のクロスドメインのグループが、任意のドメインのリソースへのアクセスを要求できることを意味します。均一性を達成するために、すべてのフォレストのすべてのサービス ドメインの OU に対称構造 (黒い縦長の楕円) を作成することが決定されました。彼らが言うように、軍隊ではすべてが醜くても均一であるべきです。

したがって、プロジェクト 80XXX を TG ドメインに登録すると、スクリプトが実行されます。

1. このドメインおよびクロスドメイン、つまり従業員がこのリソースにアクセスする必要があるドメインに、対応する OU (赤い水平楕円) を作成します。

2. - のような名前のグループを OU に入力します。ここで、

• SRC_ ドメイン - 従業員が DST ドメイン リソースにアクセスできるクロスドメイン
• DST_domain – リソースへのアクセスが実際に提供される必要があるドメイン、つまり、そのためにすべてが開始されたドメイン
• — プロジェクト番号
• ROLES – アクセス マトリックスにリストされているロールの名前。

3. 関連するすべてのドメインのすべてのグループの SID の配列を読み取り、後続のデータ転送のために特定のプロジェクトのサブフォルダーへの権限を定義するファイルに保存します。

4. 実行可能ファイル モード「icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt」で icacKC ユーティリティによって使用される一連の権限を含むソース ファイル (パラメーター /restore) の生成

5. すべてのプロジェクト フォルダーに対して起動されたすべての icacl を結合する CMD ファイルを作成する

先ほども書きましたが、実行ファイルの起動は手動で行われ、実行結果の評価も手動で行われます。

最終的に直面しなければならなかった困難:

• プロジェクト フォルダーがすでに多数のファイルでいっぱいである場合、既存のボリュームで icacls コマンドを実行するとかなりの時間がかかり、場合によっては失敗することがあります (ファイル パスが長い場合など)。
• /restore パラメーターに加えて、フォルダーが作成されず、ルートからの継承権限が無効になっている以前の既存のフォルダーから転送された場合に備えて、/reset パラメーターを含む行を追加する必要がありました。
• グループを作成するスクリプトの一部は各フォレストの任意の DC で実行する必要があり、問題は各ツリーの管理アカウントに関係します。

一般的な結論: 同様の機能を備えたユーティリティがまだ市場に存在しないのは非常に奇妙です。 Sharepoint ポータルをベースに同様の機能を実装することも可能のようです。
また、Sinology デバイスでフォルダー権限を設定するために PoSH ユーティリティを使用できないことも理解できません。

もし興味があれば、github 上にプロジェクトを作成してスクリプトを共有する準備ができています。

出所： habr.com