web-dev-qa-db-ja.com

SQL Serverエージェントが「実行」権限を監視しない

不思議な権限の問題があります。特定のユーザーとして実行するように構成された既存のSQL Serverエージェントジョブが機能しなくなる原因が最近発生しました。彼らは以前働いていた。現在、基本的な権限エラーがスローされています（たとえば、SELECT権限が拒否されました）。

これが特定のテストケースです。ユーザーjohndoeは、サーバーレベルのsysadminロールを持っています。次のクエリは、SQL Server Management Studioのjohndoeで実行すると正常に機能します。

select * from TableA into TableB

しかし、まったく同じクエリを単一ステップのSQL Serverエージェントジョブに入れ、そのステップをユーザーjohndoeとして実行するように構成すると、次のエラーが発生します。

ユーザーとして実行：johndoe。 SELECT権限は、オブジェクト「TableA」、データベース「MyDatabase」、スキーマ「dbo」で拒否されました。 [SQLSTATE 42000]（エラー229）。ステップは失敗しました。

この一見自発的な変化を引き起こした可能性があるものについて何か提案はありますか？

sql-server-2008-r2sql-server-agent
7
dlh

実際にクエリを実行しているSQLユーザーを確認しましたか？権限レベルに応じて、SQLエージェントは、ユーザーがより高いレベルのアカウントを「偽装」することを許可している場合があります。

T-SQLステップを使用してジョブを作成します。

SELECT ORIGINAL_LOGIN(), SUSER_NAME(), USER_NAME();

ログ出力をテーブルまたはテキストファイルに作成し、実際に最終クエリを実行しているユーザーを確認します。本来あるべきユーザーではない場合は、トレースして、なりすましの発信元を突き止める必要があります。

フィルターされたビューを使用してCRM Dynamicsデータベースで問題が発生しました。指定されたCRMユーザーはフィルターされたデータを表示できます。ジョブがシステムアカウントの偽装を使用している場合、システムアカウントはCRMユーザーとして存在しないため、データは返されません。

3
Stuart Moore

userとして実行：johndoe

EXECUETE ASコンテキストはuserコンテキストであり、ログインコンテキストではありません。そのため、EXECUTE ASサンドボックスの制限に該当します。 EXECUTE ASを使用したデータベース偽装の拡張 を参照してください。

eXECUTE AS USERステートメントを使用してプリンシパルを偽装する場合、またはEXECUTE AS句を使用してデータベーススコープのモジュール内で使用する場合、偽装のスコープはデフォルトでデータベースに制限されます。

具体的には、データベースが trustworthy としてマークされていない限り、サーバーレベルのグループメンバーシップから派生した権限を継承しません。選択は、[MyDatabase]を信頼できるものとしてマークする（したがって、[MyDatabase]のdb_ownerメンバーをsysadminの事実上のメンバーにし、すべての影響を与える）か、または明示的にに権限を付与することができます。 user [johndoe] in [MyDatabase]。

1
Remus Rusanu