I have a stored procedure set up in DATABASE1 that among other things makes a call to a stored procedure call sp_start_job (this is a stored procedure in the msdb database that will fire off an agent job).
I have created a proxy login and mapped this login to user accounts in msdb and DATABASE1 databases.
In my original stored procedure, I am using EXEC as proxylogin. This proxy user has rights to execute this procedure and in the msdb database can execute the sp_start_job procedure and is additionally a member of the SqlAgentOperator,SqlAgentUser, and SqlAgentReader Roles. I have also given the user in DATABASE1 AND msdb authenicate permissions.
The idea is that any user that can execute the original procedure will actually run it under the proxylogin's credentials so I do not have to assign these permissions out. I am still running into permission error, does anyone have insight into this problem?
We got around this by turning cross database ownership chaining on
Related
I need run .dtsx packages mounted in SSIS catalog with parameters, throught an stored procedure, because one aplication fired dtsx using stored procedure with parameter values
I have created the stored procedure using
SSISDB.Catalog.Create_Execution
Set_Execution_Parameter_Value and
Start_Execution.
This works, but for run the user need have db_owner privilegies on principal_db and ssis_admin on SSISD this will only run if the executing user is a windows account, no problem with this but I need the windows account have minimal rigths on principal_db, I know I can't do it using Sql user because is necesary an windows account but when I create my procedure give execution permition for execute stored proc to an win user in the principal database, create the win user on SSISDB and give permision on catalog procedures
SSISDB.Catalog.Create_Execution
Set_Execution_Parameter_Value
Start_Execution
and add to my stored procedure the clause "execute as owner",show me next error
I tried using Execute As and specifying a windows account but I get the error
The current security context cannot be reverted. Please switch to the
original database where 'Execute As' was called and try it again.
I tried using "execute as self" and when I try run the procedure with another win user (that give permision) show me is necesary windows account.
My user has permision on
db_owner
sysadmin and
ssis_admin
I think I need come into my permissions to an user for execute this, considering that my procedure working with 2 databases principal_db (where record my procedure) and SSISDB (where live the catalog procedures for create execution and put parameters).
Somebody can help me?
SSIDB admin permission required to run DTSX package.
Package references DB2 proc, needing DBO so proc MUST have EXECUTE as OWNER
AND Proc has GRANT Execute to Win User
Schedule job step owned by WIN USER... this so? and fails?
What is the diffrence between...
execute as user = 'testuser'
AND
execute as login = 'testuser'
I am executing a cross database procedure under these logins and it works with the exececute as login but not the execute as user. It is saying the server principal "testuser" is nt able to access the database "xxx" under the securty context.
When i SELECT SYSTEM_USER after both commands I see that it is set to 'testuser'
execute as login provides impersonation to the entire server, since logins are on a server level. Since users are defined per database, execute as user impersonation applies only to a specific database, which is why you see the error when you cross databases.
The EXECUTE AS can be added to stored procs, functions, triggers, etc.
Example to Execute As:
CREATE PROCEDURE dbo.MyProcedure
WITH EXECUTE AS OWNER
In this case you are impersonating the owner of the module being called.
You can also impersonate SELF, OR the USER creating or altering the module OR...
impersonate CALLER , which will enable to module to take on the permissions of the current user, OR...
impersonate OWNER, which will take on the permission of the owner of the procedure being called OR...
impersonate 'user_name', which will impersonate a specific user OR...
impersonate 'login_name' with will impersonate a specific login.
Setting permission on objects like stored procedures can be accomplished with
GRANT EXECUTE ON <schema>.<procedurename> to <username>;
However, you may also want to grant security rights at both the login and user level.
You will want to determine and grant ONLY the necessary rights
for the objects that require access (such as execution). Consider use of the "EXECUTE AS" capability which enables impersonation of another user
to validate permissions that are required to execute the code WITHOUT having to grant all of the necessary rights to all of the underlying objects (e.g. tables).
MOST of the time, you will only need to grant EXECUTE rights to stored procs and then rights are granted to all objects referenced within the stored proc.
In this way, you do not need to give implicit rights (example: to update data or call additional procs). Ownership chaining handles this for you.
This is especially helpful for dynamic sql or if you need to create elevated security tasks such as CREATE TABLE. EXECUTE AS is a handy tool to consider for these.
This example may help clarify all of this:
--Create a user called NoPrivUser with public access to a database (e.g. dbadb)
USE [master]
GO
CREATE LOGIN [NoPrivUser] WITH PASSWORD=N'ABC5%', DEFAULT_DATABASE=[dbadb], CHECK_EXPIRATION=ON, CHECK_POLICY=ON
GO
USE [DBAdb]
GO
CREATE USER [NoPrivUser] FOR LOGIN [NoPrivUser]
GO
NOTE: CREATOR OR OWNER OF THIS PROCEDURE WILL REQUIRE CREATE TABLE RIGHTS within the target database.
use DBAdb
go
CREATE PROCEDURE dbo.MyProcedure
WITH EXECUTE AS OWNER
AS
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].MyTable') AND type in (N'U'))
CREATE TABLE MyTable (PKid int, column1 char(10))
INSERT INTO MyTable
VALUES (1,'ABCDEF')
GO
GRANT EXEC ON dbo.MyProcedure TO NoPrivUser;
GO
-- Now log into your database server as NoPrivUser and run the following.
use dbadb
go
EXEC dbo.MyProcedure
--(1 row(s) affected)
Now try to select from the new table while logged on as NoPrivuser.
You will get the following:
select * from MyTable
go
Msg 229, Level 14, State 5, Line 1 The SELECT permission was denied on
the object 'MyTable', database 'DBAdb', schema 'dbo'.
That is expected since you only ran the procedure under the security context of Owner while logged on as NoPrivUser.
NoPrivUser as no rights to actually read the table, Just to execute the procedure which creates and inserts the rows.
With the EXECUTE AS clause the stored procedure is run under the context of the object owner. This code successfully creates dbo.MyTable and rows are inserted successfully.
In this example, the user "NoPrivUser" has absolutey no granted rights to modify the table, or read or modify any of the data in this table.
It only takes on the rights needed to complete this specific task coded WITHIN the context of this procedure.
This method of creating stored procedures that can perform tasks that require elevated security rights without permanently assigning those rights come be very useful.
Login scope is at the server level while user scope is at the current database level
http://msdn.microsoft.com/en-us/library/ms181362.aspx
I wish to grant a stored procedure read access to a table in SQL Server 2008 R2
I will then grant a user access only to the stored procedure, not to the table itself.
How do I do this?
Grant EXEC access to the single stored procedure and no permissions to the table.
Grant EXECUTE On [SpName] To [Principal]
There is no such concept as a read permissions to a table for a stored procedure. Stored procedure permissions are separate from other objects. If a user has permission to run a stored procedure, they can run it no matter what it does, even if they don't have permission to the underlying objects.
The following article is a very detailed look at several different methods for granting permissions using stored procedures. It's definitely worth a read.
http://www.sommarskog.se/grantperm.html
Most of the time, ownership chaining will take care of permissions problems. As long as the stored procedure and the underlying table have the same owner, the user only needs permission to EXECUTE the stored procedure.
In a comment to another answer, you mention that the stored procedure is in a different database from the table. You might look at module signing as a method for allowing access only through the stored procedure. Another alternative, if possible, is to create the stored procedure in the same database as the table, then grant access to users in the other database. That way, ownership chaining will take effect.
I am looking for a way to have a database user only have rights to execute stored procedures and functions. This needs to be a dynamic setting so that every time i add a stored procedure or function they have rights to it.
Constraints
I cannot change the names of the schema or stored prcedures or functions.
In SQL Server 2005 and newer, you can create a new database role
CREATE ROLE db_executor
and then grant that role the permission to execute - without specifying anything.
GRANT EXECUTE TO db_executor
This role can now execute all stored procedures and function in the database - and it will be able to execute any future stored procedures you add to the database, too!
So now just add this role to your user and you're done:
exec sp_addrolemember #rolename = 'db_executor', #membername = 'your-user-name-here'
PS: of course, you could also grant this permission to just a single user:
GRANT EXECUTE TO your-user-name
This makes management a nightmare, however - so I wouldn't go down that path..
I have a database where all access is controlled by stored procedures. The DBA would like to avoid giving users direct read/write access to the underlying tables, which I can understand. Hence all updating and selecting of data is done via stored procedures. Basically he has created one role that has EXECUTE permissions to all the stored procedures in the database and given users that role.
The problem is that one of the stored procedures dynamically builds a SQl Query and executes it via "Execute sp_Executesql". Without going into great detail the query is built dynamically because it changes significantly depending on many user input parameters. The stored procedure in question is only a SELECT sql statement however I am finding that just giving the stored procedure EXECUTE permission is not enough. The underlying tables referenced within the stored procedure that make use of "Execute sp_Executesql" need to have been given "datareader" access or else the stored procedure fails.
Any thoughts on how to correct this? I really wanted to restrict access to the tables to only stored procedures, but I need to find a way to work around the stored procedures that make use of "Execute sp_Executesq"l. Thank you.
In the wrapper proc you can use EXECUTE AS OWNER or EXECUTE AS SomeuserWithNoLogin
This will change the login context for the duration of the stored proc which includes sp_executesql.
If you use OWNER, it will work because you're already using ownership chaining.
If your DBA (good man!) does not want you running as dbo, then set up a user that has full read but no rights. EXECUTE AS <user> requires an entry is sys.database_principals
Like this:
CREATE USER SomeuserWithNoLogin WITH WITHOUT LOGIN
EXEC sp_addrolemember 'db_datareader', 'SomeuserWithNoLogin'
For more info, see EXECUTE AS Clause on MSDN and CREATE PROCEDURE
The real problem is that sp_Executesql is in the master database, not necessarily the database your working in. Your DBA has to give execute sp_Executesql permission to the calling procedure. Than anyone who has permission to call that procedure will be able to run the sp_Executesql.