sysadmin権限を汎用アカウントから削除することで、テスト環境で権限をロックダウンし始めました。複数の開発者が使用する最初のアカウントは、ローカルSQLログインです。私はアカウントにデータベースのdb_ownerロールを与えました。開発者は、ストアドプロシージャを作成できなくなったと報告しています。
これがこの特定のSQL 2014インスタンスに当てはまることを確認しました。他の場所では再現できません。私はこれを修正するために私が考えることができるすべてを行いました。私が持っている最良の手がかりは、新しいSQLログインを作成し、同じデータベースでdb_ownerを与えたことです。また、プロシージャを作成することもできません。 db_ownerが含まれていても、元のログインでは他のユーザーデータベースにプロシージャを作成できません。
プロシージャを作成しようとすると、次のようになります。
メッセージ262、レベル14、状態18、手順TheProcedure、行30
データベース「DBTest」でCREATE PROCEDURE権限が拒否されました。
エラーメッセージは正しいです、CREATE PROCEDURE
を明示的に割り当てた後でも、ユーザーに表示されません。ユーザーは任意の手順を変更できます。 UDFの作成で同様のエラーが発生します。
データベースでCREATE FUNCTION権限が拒否されました...
誰が何が起こっているのか考えていますか?
私がするとき:
select * from fn_my_permissions(null, 'DATABASE')
CREATE PROCEDURE
はリストされていません。 sys.permissionsでDENY
を確認しましたが、何もありません。
次のクエリ:
SELECT * FROM fn_my_permissions('xyz', 'USER');
戻り値:
IMPERSONATE, VIEW DEFINITION, ALTER, CONTROL
興味深いもの-これを特定するのは難しい。公共の役割を見ることを考えましたか?
sp_helprotect 'CREATE PROCEDURE'、NULL、NULL、 's'
それはあなたに何かをもたらしますか?
チェックをバイパスするsysadminとは異なり、組み込みのデータベースロールはそれほど特別なものではないため、DENYでオーバーライドできません。
Exec sp_helpprotect Null、 'Username'を見て、どのDENYレコードが表示されるかを確認してください。
短い答え:
Devユーザーのデフォルトデータベースを特定のデータベースに変更してみてください。
SS Studioのクエリウィンドウで、データベースドロップダウンリストまたはT-SQL USE [DBNAME]を使用して、クエリウィンドウ内で適切なデータベースコンテキストを使用していることを確認します。
長い回答:
私はあらゆる状況で話すことはできませんが、これが間違いなく私たちに起こった事例を知っています。特定のユーザーのデフォルトのデータベースは「マスター」に設定され、SA権限がありました。SA権限を削除したため、突然、必要な手順-CONNECTのみ。
ユーザーのデフォルトデータベースを変更すると、データベースがこの問題を修正するのに役立ちました。 (マスターデータベースへのCONNECT権限しか持っていなかったことがわかります)さらに、USEステートメントはSS STudioクエリウィンドウで機能しました。
USE DBTest
go
Create Procedure spMyProc
as
select @@servername
そうは言っても、マスターデータベース(および他のデータベース)をチェックして、開発者がSAを使用していたときに、適切なデータベースではなく他のデータベースに誤ってコードを配置していないかどうかを確認します。私たちにとって、SA権利を削除すると、開発者がシステムをどのように使用していたかについて、重大な問題が明らかになりました。
pSデータベースの内部と外部の両方に同じ名前のユーザーがいる可能性があるため、部分的に含まれているデータベースを使用しているかどうかを知らせてください。