Hello I am trying to grant access for a stored procedure to be able to create a database. I am currently getting an error when running a backup restore script from the application: "CREATE DATABASE permission denied in database 'master'"
I tried to grant access to the restore SP to create database
GRANT CREATE DATABASE ON dbo.my_stored_procedure TO [IIS APPPOOL\myAppName];
However this command gives me the following error
Incorrect syntax near 'CREATE DATABASE..'.
Here is the basics of the Sproc:
RESTORE DATABASE #new_db_name
FROM DISK = #file_path
WITH RECOVERY,
MOVE 'CurrentDB' TO #new_db_file,
MOVE 'CurrentDB_log' TO #new_db_log
Your syntax is wrong. You don't grant database permissions on something. You grant to a user or role.
http://msdn.microsoft.com/en-gb/library/ms178569.aspx
You can grant execute on a sproc though. That may be enough to get the database permissions you need. If not, then either give the executing user the permissions, or look into impersonation.
Related
I am trying to create a link between two schemas in SQL Developer and I have an error. The querie I am executing is:
CREATE DATABASE LINK dblink
CONNECT TO Matecode IDENTIFIED BY Matecode
USING 'Matecode';
Where Matecode it's the remote user, password and database Schema I want to be conected. Like this:
CREATE DATABASE LINK dblink
CONNECT TO remote_user IDENTIFIED BY password
USING 'remote_database';
But I am receiving this error
00000 - "insufficient privileges"
*Cause: An attempt was made to perform a database operation without
the necessary privileges.
*Action: Ask your database administrator or designated security
administrator to grant you the necessary privileges
The password and the user are ok.
Check you have "create database link" privilege to the schema where you are creating the Database link. if the privilege is not granted use below statement as 'sysdba' user to grant the "create database link" and then try to create the database link.
SQL:
grant CREATE DATABASE LINK to username;
I'm trying to add db_backupuperator to a UserMapping but I can't. It returns the Error 15150 and the message:
"Drop failed for User 'dbo' (Microsoft.SqlServer.Smo)
Additional information:
an exception occurred while executing a Transact-SQL statment or batch
(Microsoft.SqlServer.ConnectionInfo)"
I've already tried apply these sugested solutions:
https://blog.sqlauthority.com/2017/12/12/sql-server-fix-msg-15150-cannot-alter-user-dbo/
Use database_name
sp_changedbowner 'sa'
I've tried also delete the database and create a new one, but then I can't edit any option of User Mapping, can't even add db_datareader or db_datawriter
If the user is member of the dbo database role, you will first have to remove him from this role. If he is the database owner, you will first have to change the database owner to another user. Then afterwards you can grant thim indivually the permissions needed, or create a database role which includes the permissions and put him in that role. This will be much more easier, if you have additional users holding the same rights as the mentioned user.
Reference link from Here.
I'm currently working on an MVC5, EF6 project and needed a stored procedure for a piece of the project. I've written the stored procedure, and now when I try to use it within my code I get an error saying:
The EXECUTE permission was denied on object ....
Yet when I test the stored procedure in SQL Management Studio it let's me run the stored procedure just fine. I'm not really sure what to do to fix this as I've never come across this before.
First create an executor role and then grant exec permission to this role.Then make your user member of this role.
CREATE ROLE db_executor;
GRANT EXECUTE TO db_executor;
EXEC sp_addrolemember 'db_executor', 'user1'
Hopefully this is enough but in case you still have issue check the below.
The schema owner of SP and underlying objects should be the same for sql chaining permission to work.
Check schema owners by:
select name, USER_NAME(s.principal_id) AS Schema_Owner from sys.schemas s
To change the owner of an schema you can:
ALTER AUTHORIZATION ON SCHEMA::YOUR_SCHEMA TO YOUR_USER;
Examples:
ALTER AUTHORIZATION ON SCHEMA::Claim TO dbo
ALTER AUTHORIZATION ON SCHEMA::datix TO user1;
Finally if within your SP you are truncating a table or changing structure you may want to add WITH EXECUTE AS OWNER in your SP:
ALTER procedure [myProcedure]
WITH EXECUTE AS OWNER
as
truncate table etl.temp
Create a separate user role with access 'Execute' and then assign that to your current user. This is the best solution and helped me.
Please follow this link:
https://stackoverflow.com/a/26871428/6761105
We are building a management app for our system, and one of the app's abilities is to create new databases for new users. This app needs to CREATE DATABASE, RESTORE DATABASE, CREATE USER, grant permissions, etc - so the user needs to have some very strong permissions.
We are contracting these services to an external company and we do not want to give them unrestricted access to our system, we only want them to be able to do what we allow them to do. So we thought about encapsulating the entire process in a stored procedure, granting EXECUTE on this to a specific domain user, and running it with EXECUTE AS 'SA'.
Unfortunately that is not possible - SA is not a database user and when we try to define it as one, we get the error
Msg 15405, Level 16, State 1, Line 1
Cannot use the special principal 'sa'.
We then thought about using DBO and setting up cross-database ownership chaining, but this is all beginning to be a serious headache.
Does anyone know of an elegant way to do this?
This is perfectly possible with module signing.
Create a procedure that executes the elevated code.
Add EXECUTE AS CALLER to the procedure
Create a certificate and private key
Sign the procedure
Drop the private key
Export the certificate
Import the certificate in [master]
Create a login derived from the certificate
Grant the required privileges to the certificate derived login
Note that any alteration to the procedure will invalidate the signature and will require to redo the procedure. Dropping the private key is very important because otherwise the vendor can sign a different procedure and get the elevated permissions on arbitrary code. See Signing an Activated Procedure for an example.
To manage things inside a database, you can use EXECUTE AS OWNER and make sure dbo owns the stored procedure. No problems there
However, CREATE DATABASE etc requires server level permissions. Note: you don't need sysadmin permissions.
With SQL Server 2012 you can use server roles, and GRANT CREATE DATABASE to this server role. For earlier versions, you can grant this directly to the login. Or use dbcreator if your prefer.
If you decide they need to manage logins however, securityadmin has the same effective permissions as sysadmin
create database admin;
GO
alter database admin set trustworthy on
GO
alter authorization on database::admin to [sa]
GO
use admin
GO
create procedure adminProc
with execute as 'dbo'
as
create database test
GO
create login tmp with password = 'tmp', check_policy = off
GO
create user tmp
GO
grant execute on adminProc to tmp
GO
execute as login = 'tmp'
GO
-- This fails
create database test
-- This works
exec adminProc
GO
revert
GO
drop database test
GO
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