これは、ファイルサーバーのアクセス許可に対して推奨/有効なアプローチですか？
ファイルサーバーはITの現実であり、グループを作成し、共有フォルダーへのクライアントアクセスを管理するためのアクセス許可を適用する方法について、一般的に受け入れられている方法（ここでは、「ベスト」という言葉を使用することを躊躇します）があるかどうか知りたいです。ファイルサーバー。
私の現在の仕事では、ACL上の数十のグループから、個々のユーザーをファイルシステムに直接配置するまで、これを行うさまざまな方法のかなりの混乱を継承することになりました。私の仕事は、混乱を一掃し、会社全体でこれに取り組むための何らかの標準化された方法を考え出すことでした（大規模な環境、15万人の人員、9万台のクライアントコンピューター、数百台のファイルサーバー）。
この問題についての私の理解から、保護されたリソースごとに必要なアクセスレベルごとに少なくとも1つのグループが必要であるように思われます。このモデルは、別のアクセスレベルをサポートする必要がない限り、ファイルシステムのアクセス許可に再度触れる必要がないという点で最も柔軟性があるようです。欠点は、複数の共有リソースで同じグループを再利用する場合よりも多くのグループを作成することです。
これが私の意味を示す例です：
FILE01という名前のファイルサーバーに「テスト結果」と呼ばれる共有があり、読み取り専用アクセス、読み取り/書き込みアクセス、およびフルコントロールを必要とする人々がいます。 1つの保護されたリソース* 3つのアクセスレベル= 3つのセキュリティグループ。 AD環境では、これらをユニバーサルグループとして作成するため、フォレスト内の任意のドメインからユーザー/グループを簡単に追加できます。各グループは共有フォルダーとアクセスレベルを一意に参照するため、グループ名にはこれらの「重要な」データが組み込まれ、アクセス許可は次のようになります。
"FILE01-Test Results-FC" -- Full Control
"FILE01-Test Results-RW" -- Read & Write
"FILE01-Test Results-RO" -- Read Only
通常、組み込みのSYSTEMアカウントと、フルコントロールアクセス権を持つ組み込みの管理者も含まれます。この共有への実際のアクセス権を誰が取得するかについての変更は、ACLに触れる必要がなく、グループメンバーシップを使用して処理できるようになりました（マネージャー、技術者、QAアナリストなどの特定のビジネスロールを表す「役割」グループを追加するか、個人のみ1回限りのアクセスのユーザー）。
2つの質問：
1）これは実際に権限を処理するための推奨または有効なアプローチですか、それともよりシンプルでエレガントなソリューションが不足していますか？継承を使用しながら、状況が変化したときにファイルシステムの大部分を再ACLする必要がないという柔軟性を維持しているソリューションに特に興味があります。
2）環境内のファイルサーバーのアクセス許可とグループ構造をどのように処理していますか？大規模な環境でも作業している人のためのボーナスポイント。
私のアプローチは、ファイル/ディレクトリレベルのファイルパーミッションを使用しないことです。ファイル共有レベルのアクセス許可を使用し、サーバーファイルシステムのデータドライブ全体をEveryone Full Controlに設定します（これは無効になります）。
何年にもわたって（10年以上）、NTFSアクセス許可はより複雑であり、より多くのエラーにつながることがわかりました。権限が間違って設定されている場合、または継承が壊れている場合は、データが公開され、データを見つけて表示するのが困難になります。さらに、移動/コピーの問題にさらされています...ファイルを移動するユーザーもファイルのACLを移動しますが、コピーは宛先ACLを継承します。
読み取り/書き込みグループは同じように使用しますが、ファイル共有全体でComp MgmtMMCを使用します。完全にしないでください...ユーザーは部分的な知識/最善の意図で自分自身を撃ちます。
そのアプローチは悪くありません。原則として、個々のユーザーを使用して権限を追加することは絶対にしないでください。グループを使用してください。ただし、グループはリソース間で使用できます。たとえば、HRはファイルへのRWアクセスを持ち、MANAGERSはRを持っている場合があります。アクセスベースの列挙を設定することもできます。次のWebキャストをご覧ください。
TechNet Webキャスト：Windows Server 2003管理シリーズ（パート4/12）：グループ管理（レベル200）
アクセスベースの列挙は、生活を楽にすることもできます。
ABEは、管理する必要のあるさまざまな共有の数を減らすのに役立ちます。
あなたのアプローチは基本的に私がそれにアプローチする方法です。
私が追加するのはこれらだけです：
1）1つのサーバーだけでなく、サーバー全体で必要なものを評価することで、「役割」スキームに追加します。おそらくこれに対して外れ値に遭遇するでしょうが、それらに遭遇したときに別のグループを作成するというのが私の理論です。外れ値が1つある私の経験では、多くあります。
2）ユニバーサルグループ内のメンバーとグループがグローバルカタログサーバーに複製されるのに対し、ドメインローカルとグローバルではグループのみが複製されるため、すべてのユニバーサルグループの必要性を強く再評価します。グローバルカタログサーバーに複製されます。したがって、ユニバーサルグループに変更を加えると、レプリケーションが開始されますが、グローバルおよびドメインローカルでは開始されません。
アクセスレベルごとにリソースグループを使用する方法は正しいです。私が検討する唯一のことは、リソースにドメインローカルグループを使用することです。サーバー固有のリソースグループを作成する場合は、必ずしもユニバーサルグループを使用する必要はありません。
リソースにドメインローカルグループを使用することの欠点は、グループの総数が増えることです。利点は、Zypherが指摘したように、レプリケーションの問題が少ないことです。
提案されたアプローチはかなり堅実なようです。ただし、注意すべき点の1つは、ファイル共有を最初に設定する方法です。推奨される方法は、グループのアクセス許可を割り当てるサブフォルダーを含む単一のトップレベル共有を持つことです。 NTFSは、最上位フォルダの「トラバースフォルダ/ファイルの実行」をバイパスして、サブフォルダへのアクセスを許可できます。
この場合、構造は\ servername\sharename\group-folderのようになり、共有アクセス許可は「sharename」フォルダーに設定するだけで済み、実際のNTFSアクセス許可は「group-folder」フォルダーに設定されます。
この種の設定でも、ファイルサーバーのパフォーマンスが向上します。
私が行う他の一般的なことは、グループ名がグループフォルダー名と同じになるようにグループの命名規則を設定し（必要に応じてFC/RW/ROを追加）、UNCをフォルダーのグループ記述に貼り付けることです。 （ログオンスクリプトがそれを読み戻し、ドライブマッピングをそのように設定できるようにするため、また、どの共有フォルダーがどのグループに適用されるかをより簡単に確認できるようにするため）。
私がWindows2000以降Windowsファイルサーバーに使用している標準的な方法（MarkMinasiのMasteringWindows Serverシリーズに記載されているので、詳細を確認してください）は、ファイルサーバー自体にローカルなグループをネストに使用することです。
たとえば、MUPPETSというドメインにあるKermitという名前のファイルサーバーについて考えてみます。
カーミットがいくつかのファイル共有を持っているとしましょう：
\\Kermit\Applications
\\Kermit\Finance
\\Kermit\Sales
\\Kermit\Manufacturing
Kermitのローカルにアクセス用のグループを作成し、指定したとおりにファイルシステムへのアクセス許可を付与します（つまり、アクセスレベルごとに1つのグループを共有ごとに）
Kermit\Applications-RO
Kermit\Applications-RW
Kermit\Applications-FC
Kermit\Finance-RO
[...]
これらはローカルグループであるため、他のグループやユーザーを好きなように配置できます。ドメインローカルグループ、グローバルグループ、ユニバーサルグループ、フォレスト内の任意のドメインのユーザーアカウントです。権利管理は、ファイルシステムやADではなく、ファイルサーバーのグループに対してローカルになりました。
これにより、グループ管理に追加のレイヤーが追加されますが、（たとえば）サイトローカル管理者がそのファイルサーバーに対する管理者権限以外のものを必要とせずに独自のファイルサーバーを管理できるという利点があります。フェデレーションのようなブランチオフィス構造があり、すべてのオフィスがサーバーを使用して独自のことを行う場合、これは大きなメリットになります。数十人のローカルサイト管理者にAD管理者権限を付与する必要がない場合があります。
また、ADが多数のグループで乱雑になるのを防ぎ（サーバーごとの共有ごとにアクセスレベルごとに1つのグループをすばやく追加できます）、GC間のグループレプリケーションを最小限に抑えます。これにより、権限ではなく役割用にADグループを予約できます。
環境が厳密に標準化されており、すべてのファイルサーバーが同一で複製されている場合、これは明らかに不要なグループのもう1つのレイヤーです。また、すべての単一ファイルサーバーに存在する共有に対して同じ権限を持つ特定のADグループが必要であることがわかっている場合は、それを維持するために何らかの自動化が必要になります。
一言で言えば、ファイルサーバーが互いに異なるほど、マシンローカルグループを使用することは理にかなっています。それらが類似しているほど、現在使用しているシステムを使用したいと思うようになります。
私はNetWareからWindowsServer 2008への移行を検討しているので、これは最近よく頭に浮かびます。 Server 2008（およびある程度Server 2003R2）には、この移行を非常に簡単にする非常に優れた機能がいくつかあります。 Server 2008には、すぐに使用できるアクセスベースの列挙が付属しています。これは非常に優れた機能であり、ユーザーは自分がアクセス権を持っているディレクトリのみを表示できます。あなたがのようなシェアを持っているなら...
\\ user-home-srv\homes \
ABEがないと、エンドユーザーには数十/数百/数千のディレクトリが表示されます。 ABEを使用すると、エンドユーザーには1つしか表示されません。同じことが共有共有にも当てはまります。 ABEを使用すると、必要に応じてすべての部門ディレクトリに1つの巨大なボリュームを作成でき、ユーザーがアクセスできないディレクトリでユーザーをスパムすることはありません。 ACLの問題ではありませんが、多少関連しているので、取り上げます。
Server 2008が以前のバージョンよりも優れていると思われるもう1つの点は、ACLの継承です。大きな木の上部でACLの変更をリーフに伝播する方が速いようです。
Netwareのレガシーにより、グループ内のユーザーに基づいて名前が付けられたグループが多数あり、アクセスを許可するグループに基づいて名前が付けられたグループがいくつかあります。アクセスが制限されているディレクトリの場合は、「RO」「フル」の命名法も使用します。
モノリシックな「共有」ボリューム（まだNetWare上にありますが、Windowsに移行するときにモノリシックにする予定です）があります。これは、4,400人のワーカーすべての単一の共有ボリュームであり、350万を超えるファイルがあります。トップレベルのディレクトリはすべて部門名であり、各部門はその内部で何が行われるかを規制します。非常に大規模な部門にはいくつかの例外があり、ACLを備えた第2レベルのディレクトリがあります。
私の最後の仕事では、許可を設定することさえできたので、仕事に応募する人事部の従業員は自分のサーバーで自分の応募データを見ることができませんでした。これを行うには、いくつかのinheritance-rights-filtersが必要でした。これは、Windowsの「blockinheritance」タグに似ています。そこにあるトリッキーな部分はそれをすべて文書化することでした、しかしそれは働いた。
最良のシナリオは、すべてのユーザーを、ユーザーの職務の1つのセキュリティグループに追加することです。その後、役割は必要に応じてアクセスを委任されます。
同様に、共有フォルダには、「FILE01-テスト結果-RW」の例のように、「リソース」セキュリティグループを使用してアクセスを許可する必要があります。これには、職務、部門の役割、またはその他の該当するグループが含まれます。
この設計の利点は、追跡が困難な1回限りのアクセスではなく、グループごと（チーム、部門など）でアクセスを委任できることです。ユーザーが別の部門に異動する場合は、古いアクセスをすべてクリーンアップする必要があります。
欠点は、グループが悪用される可能性があることです。グループが何に使用されるかを明確に区別して、共有に割り当てられたリソースグループが部門グループであるかのように再利用されないようにし、アクセスの混乱を引き起こします。