web-dev-qa-db-ja.com

ドキュメントがない場合、ADグループにどのような権限があるかをどのようにして見つけますか？

A社に雇われたばかりで、古い管理者はもういません。インターネット制限グループにユーザーを追加するためのリクエストが送信され始めます。グループを見ると、名前のどれも意味がなく、各グループが何に対して権利を持っているか、何をしているのかを説明する文書はそこにはありません。それは私に懸念を引き起こします。セキュリティのために、誰もが正しい権利を持っているかどうかをどのようにして知ることができますか。

グループが権利を持っているものをどのようにして見つけますか？この情報を見つけるためのツールはありますか？

windowsaccess-controlactive-directory
20
Ambar Batista

「簡単な解決策はありません」という長めの答えになると思います。
これを解決するにはいくつかの戦略的な作業が必要です（これが私がこれをSFに移動することをしないに推奨した理由です）。

その理由を説明します。

Windowsは、中核として、アクセス制御の DACモデル に基づいています。
OSのすべては、ファイル、フォルダ、レジストリ、名前付きパイプ、ソケット、共有などのACLで保護できます。

ADグループを使用すると、これをRBACタイプのモデルに抽象化できますが、内部的にはDACモデルのままです。 （つまり、グループ（つまりロール）のACE（アクセス制御エントリ）を作成できますが、それでもACEを作成しています。これがアクセス時に検証されるものです）。

"mostly" を強調します。
これにはいくつかの明確な例外があります：

  1. MACの実装がいくつかあります。つまり、整合性レベル（Vista/7/2008）です。
    ただし、これは通常、内部OS保護メカニズムであり、通常、実際のアクセス制御（組み込みUAC以外）には /利用されません。 通常。
  2. OSレベルの特権。 （これらの特権を付与する特定のユーザーを指定することは可能ですが、これはRBACモデルを対象としており、RBACモデルとして機能します）。

しかし、待ってください、それはOS自体にあります...
プラットフォームとしてのWindowsは、アプリケーション（サードパーティ、MS製品、およびOSアドオン）がADグループメンバーシップをRBACメカニズムとして使用することを許可および推奨します。

  1. サードパーティのアプリケーションは、単純なAD/LDAPルックアップを介してグループメンバーシップを確認できます。これらのアプリは、グループ名を保存して解決するか、グループのSIDを保存して直接クエリする可能性があります。
  2. SQL Serverを忘れないでください-これは主に（いくつかの異なるタイプの）ロールに基づいていますが、通常はこれらのロールにAD groups を追加し、ユーザーを直接追加しないことをお勧めします。
  3. COM +はRBACによるアクセスも管理しますが、COM +ロールにユーザーではなくグループを追加することをお勧めします。
  4. Sharepointは、役割/グループ/およびメーリングリストに従ってサイトへのアクセスも管理します...

私の要点を見始めましたか？
それは絶望的だとは言いたくないですが、...

要点をまとめると：
特定のグループが持つ権限の明確なリストを見つけるには、次のすべてを再帰的にチェックする必要があります（また、グループメンバーシップについて再帰することも忘れないでください）。

  • 組織内の各サーバー：
    • すべてのフォルダとファイルのACLを再帰的にチェックします
    • すべてのフォルダとファイルで [〜＃〜] sacl [〜＃〜] を再帰的にチェックします（システムアクセス制御リスト-これらの制御監査）
    • すべてのフォルダとファイルの所有者を再帰的にチェックします
    • すべてのレジストリキーのACL、SACL、および所有者を再帰的にチェックします
    • すべての名前付きパイプ、プロセスとスレッド、サービス、ジョブなどのACL、SACL、所有者を再帰的にチェックします。
    • すべてのOSレベルの権限を確認します（GPOを使用すると、これを簡単にすることができます...）
    • すべてのCOM +ロール、MSMQロールなどを確認してください。
  • ADの各ドメイン：
    • すべてのドメインレベルの権限を確認する
    • すべてのGPO（グループポリシーオブジェクト）を確認する
  • 各データベースサーバー：
    • すべてのサーバーの役割を確認する
    • すべてのデータベースロールを確認する
    • すべてのアプリケーションロールをチェックする（MSSQL内）
  • 各Sharepointポータル：
    • すべてのサーバーレベルの役割と権限を確認する
    • すべてのサイトレベルおよびリストレベルの役割と権限を確認する
  • 各サードパーティアプリケーション：
    • ADグループの使用を確認する
    • how アプリがこれらの役割を使用することを確認します。
      ->グループ名対DN対グループSID対...例グループGUID
      ->アプリは直接ロールメンバーシップを明示的にチェックしますか、それとも「よりスマートな」再帰メソッドを使用しますか？
    • これは、サードパーティのパッケージ製品とプラットフォーム（Oracle、SAP、MQSeries、WebSphereなど）、およびカスタム開発されたビジネスアプリの両方に適用されます。

これで完成ですか？
残念ながら、違います。たとえば、組織内のすべての desktops のレビューは含めませんでした。これらの shouldnt には特定のADグループレベルの権限が設定されているためです（ただし、例：管理者およびヘルプデスク）-ただし、それらは頻繁に実行されることに注意してください。
しかし、これは完全なリストではありません...

これは、DACモデルを使用する場合の大きな欠点です。これらのACLをすべて検索する中心的な場所がないため、「D」も「分散」の場合と同じように使用できました。
RBACとDAC/ACLの違いは何ですか？ で述べたように：

  • 通常、DAC定義はデータ/リソースにアタッチされますが、RBACは通常、コード/構成/メタデータ（ロールアクセス）とユーザーオブジェクト（またはテーブル-各ユーザーが持つロール）の2つの場所で定義されます。

さて、ソリューションについて少し：

  • 上記のリストのさまざまな部分を収集するためのいくつかのツールがあります。フォルダのACLを収集するためのPowerShellスクリプトを使用した@Ianの回答。そのためのツールは他にもたくさんあります（私は過去にCACLSを使用することが知られています）。いくつかは here と記されています。
    リストの特定の部分のツール/スクリプトをリクエストする場合、ServerFaultでより良いアイデアを得ることができます。ただし、これはリストの一部にすぎないことを考慮してください。
  • いくつかの大手ベンダーの「ロール管理」製品と「ロールディスカバリー」製品は、通常、Identity Managementスペースにあります。具体的にお勧めすることはできませんが、調べる価値はあります。 [ 〜＃〜] ca [〜＃〜] （以前はまともな（完全ではないが）ツールであったEurekify）、 [〜＃〜] ibm [〜＃〜] 、 Oracle 。
    もちろん他にもあります。 heavy は、スタートアップからでさえ、最良の小規模ベンダーを見つけることに傾倒します（たぶん、私は偏見があります;））。 ）。つまり、より大きなベンダーに買収されていないものからです。
  • 組織、ビジネス要件などをマッピングするプロセスを開始することができます（これは簡単なことではありませんが）-どのような特権を目指すかget だけでなく、現状は今。前のポイントで言及したツールのいくつかは、ここで役立ちます。
  • 以前の役割の分析とモデリングがうまくいった場合は、本格的なIdM/IAM/EAMソリューションの導入を検討してください。繰り返しますが、ベンダーに対する私のコメントはまだ残っています。
  • いずれにしても、ACLの配布を最小限に抑えることを目指し、プッシュは最小限に抑えてRBACを可能な限り集中化します。

そして、幸運にも before の不快な状況になる可能性のある人への最後の警告の言葉：
間違いなく IdM/IAM/EAM製品などの集中型承認プラットフォームを調べます。 （いくつかは他のものより much 優れていることに注意してください、そしていくつかはこの状況を解決することすらありません。）

tl; dr： 正しく、本当にねじ込まれています .上記を参照してください。 ;）
（すべての希望が失われるわけではありません...）

23
AviD

これに対する答えは、このデータをどのように表示/管理するかによって異なります。これをすべて取得するには、PowerShellをお勧めします。

PowerShellを使用する場合は、ネイティブADコマンドレットまたはQuestの無料コマンドレット（http://www.quest.com/powershell/activeroles-server.aspx）を使用できます。ネイティブコマンドレットを使用するには、ドメイン内に少なくとも1つのWindows Server 2008 R2ドメインコントローラー、またはWindows Server 2008 R2サーバーで実行されているAD LDS構成セット内に少なくとも1つのインスタンスが必要です。詳細は http： //technet.Microsoft.com/en-us/library/ee617195.aspx 詳細。

実際には、特定のグループのアクセスレベルのフォルダACLを再帰的に確認するだけです。いくつかの場所（ ここ と ここ ）が試行されますが、これはスクリプトがナビゲートしなければならない非常に大量のファイル構造であるため、間違いなく時間がかかる可能性があります。ネストされたグループではさらに複雑になります。

編集：@AviDは元のコマンド構文についてスポットオンであり、それは完全に間違ったことをしていました！より話題に編集されました。

4
Ian Pugsley

これは、次のようにWindowsコマンドプロンプトから実行できます。

  • レポートを保存するディレクトリに移動します。何も選択されていない場合は、ログインしているユーザーのディレクトリがデフォルトになります。例はcd C:\Users\Administrator\Desktop

  • 次のコマンドを使用してレポートを生成します。

    gpresult /s servername /user INTERNAL\user1 /h gpreport.html

  • 上記のコマンドは、レポートが選択されたユーザーに適用されるGPOSおよびルールに基づいてレポートを生成します。このユーザーは、特定のグループのメンバーであるユーザーである必要があります。または、特定のグループの設定をテストするためのテストユーザーを作成できます。

  • この情報を見つけるもう1つの方法は、GPOを編集することです。Windows2008では、すべての設定を表示してステータス順に並べ替えるオプションが必要です。次に、 GPO。

1
Brian Winning Jr.