ユーザーがいくつかのADグループに属している場合の効果的なSQL Server権限
Active Directoryグループを介したウィンドウ認証を使用して、データベースに対する異なる権限を持つ2つの異なるActive DirectoryグループにActive Directoryユーザーが存在する場合、どのActive Directoryグループが権限の設定に使用しますか？
- 最も制限的な
- 最も制限の少ない
- 2つの累積
- ランダム
私はドメイン管理者ではなく、テストドメインがないため、これをテスト環境で設定するのは難しいことがわかっています。さらに、両方の方法で結果を見てきました。誰かが答えを知っているのかと思っているだけです。
ログインに適用される権限が合計され、オブジェクトごとに最小制限から最大制限に適用されます。 DENYの権利はGRANTの権利よりも優先されます。
データベースエンジンの権限の MSDN SQL Serverページから取得/ ：
権限の確認は複雑になる場合があります。権限チェックアルゴリズムには、明示的および暗黙的な権限の両方の重複するグループメンバーシップと所有権の連鎖が含まれ、セキュリティ保護可能なエンティティを含むセキュリティ保護可能なクラスに対する権限の影響を受ける可能性があります。アルゴリズムの一般的なプロセスは、関連するすべての権限を収集することです。ブロッキングDENYが見つからない場合、アルゴリズムは十分なアクセスを提供するGRANTを検索します。アルゴリズムには、セキュリティコンテキスト、権限スペース、および必要な権限の3つの必須要素が含まれています。
アルゴリズムの一般的な手順
アルゴリズムがセキュリティ保護可能なファイルへのアクセスを許可するかどうかを決定する場合、アルゴリズムが使用する正確な手順は、関係するプリンシパルとセキュリティ保護可能なファイルによって異なります。ただし、アルゴリズムは次の一般的な手順を実行します。
ログインがsysadmin固定サーバーロールのメンバーである場合、またはユーザーが現在のデータベースのdboユーザーである場合は、権限チェックをバイパスします。
所有権の連鎖が適用可能であり、連鎖の前半のオブジェクトに対するアクセスチェックがセキュリティチェックに合格した場合、アクセスを許可します。
呼び出し元に関連付けられているサーバーレベル、データベースレベル、および署名済みモジュールのIDを集約して、セキュリティコンテキストを作成します。
そのセキュリティコンテキストでは、アクセス許可スペースに対して付与または拒否されたすべてのアクセス許可を収集します。許可は、明示的にGRANT、GRANT WITH GRANT、またはDENYとして述べることができます。または、許可は暗黙またはカバーする許可GRANTまたはDENYにすることができます。たとえば、スキーマに対するCONTROL権限は、テーブルに対するCONTROLを意味します。テーブルのCONTROLはSELECTを意味します。したがって、スキーマに対するCONTROLが付与されている場合、テーブルに対するSELECTが付与されます。テーブルでCONTROLが拒否された場合、テーブルでのSELECTは拒否されます。
列レベルの権限のGRANTは、オブジェクトレベルのDENYをオーバーライドします。
必要な権限を特定します。
必要なアクセス許可が、アクセス許可スペース内のオブジェクトのセキュリティコンテキスト内のIDに対して直接または暗黙的に拒否されている場合は、アクセス許可チェックに失敗します。
必要なアクセス許可が拒否されておらず、必要なアクセス許可にGRANTまたはGRANT WITH GRANTアクセス許可が直接または暗黙的に、アクセス許可スペース内の任意のオブジェクトのセキュリティコンテキストのIDに含まれている場合は、アクセス許可チェックに合格します。
完全を期すために（自分で忘れてしまい、これが最後に必要になったときのGoogleの結果のトップだったため）、sys.login_tokenビューとsys.user_tokenビューを使用して、現在のログインに適用されるサーバーとデータベースの資格情報を判別できます。これらは、サーバーレベルおよび現在のデータベースレベルで、SQL Serverがセッションに適用したすべてのADグループを示します。
これらのビューをsys.server_principalsまたはsys.database_principalsビューに結合すると（通常はsidまたはprincipal_id列を介して）、定義されたサーバーまたはデータベースの役割を実際に適用しているビューを導出できます。
これらをsys.server_permissionsまたはsys.database_permissionsにさらに結合すると（通常はgrantee_principal_idを介して）、個々のオブジェクトに実際に許可を適用しているのかを判別できます。
ただし、自分以外のユーザーの現在のトークンを確認する方法はわかりません（ただし、*_principalsと*_permissionsの間の結合は、最初の参照として役立ちます）。