I am using EXECUTE AS to allow a least-privilege user to run some SQL stored procedures as a sysadmin. I know that I need TRUSTWORTHY=ON on the source database (the one running the stored procedures) in order to impersonate the sysadmin on other databases on my server. However, even with impersonation granted and TRUSTWORTHY=ON, I still get the following error when trying to touch other databases as the impersonated user:
The server principal [least_privileged user] is not able to access the database XXX under the current security context.
(And yes, I know that module signing is the more secure option. I'm not looking to go that route.)
Can anyone help me?
Use execute as owner.
Make sure the procedure is in the dbo schema.
Make sure the database owner has sysadmin rights on the instance. I
have noticed that SQL logins work better for this purpose than ones
from Windows.
Check trustworthy=on for the database.
This way, you don't need additional impersonation grants, but it is a way less secure solution. It will work, though.
Related
I created SQL DB. and I want to allow only "DB owner" to access stored procedures. I want to prevent all other users including 'sa' user from doing that . how to do that ?
short answer: you can't.
long answer: sa is the owner of the whole server so cannot be cut out of anything on the server. you can prevent all other users (that does not have a sysadmin role) from using the stored procedures but again you have no way to lock out sa and/or any user with sysadmin role.
you may revoke permission to SA but SA can grant these permissions back easily.
actually you may lock out SA user if you disable SQL authentication or disable the user but anyway you cannot prevent other users with sysadmin role to interact with the stored procedures: this is by design.
please post a question with the actual requirement: this question looks like a solution you are trying to implement; maybe we can help you find a suitable solution for the actual issue.
as a side note, if you don't trust the admin of the server there is something wrong...
I've been asked to hide the definition of several SQL Server stored procedures and initially looked at the WITH ENCRYPTION option but from what I can tell a fellow admin can simply decrypt this.
Is there anyway to hide the definition even from other admins with sa privileges?
There is no way.
If you are a member of the sysadmin role, you can decrypt the sql modules easily, for example by using this tool: https://www.devart.com/dbforge/sql/sqldecryptor/
It needs access to one of two things:
The Dedicated Admin Connection
DBCC PAGE
A sysadmin has access to both. Even if you explicitly deny their use, they can just re-grant themselves.
However, you can audit their use. Once you have that setup, the rest is a matter of the contract between you and the vendor. If you set this up correctly (ask your lawyer), they should have no incentive to even try.
The Point: I want to be able to create a directory on the filesystem through a non-sysadmin SQL user.
I'm creating a web front-end for a deployment script which creates new databases from a specified template database.
Essentially I'm backing up said template database and then restoring this as a brand new database with a different name.
Our DB server has our client databases stored in sub-folders within our database store. If I were to use the default settings it would look something like:
D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\[ClientRef]\[ClientRef].mdf
D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\[ClientRef]\[ClientRef].ldf
I only have SQL access to the database server (via a programming language, hosted on a separate box) so I can't execute anything other than SQL.
My database user is extremely limited, however I would like to somehow grant this user to access/execute master.dbo.xp_create_subdir only. Is this possible at all?
I'm loathe to give our local DB user sys-admin rights, it has a limited user for a reason.
DB Server is Microsoft SQL Server 2008 R2.
Cheers, any help will be appreciated.
One possible solution is to write your own sproc that internally uses master.dbo.xp_create_subdir.
Create the sproc while logged in as an account that's a member of the sysadmin role and use "WITH EXECUTE AS SELF". Then grant permissions to that other account to execute this sproc. The database catalog where you create this wrapper-sproc must be marked as "trustworthy" or you'll still get the: User must be a member of 'sysadmin' server role. error.
E.g.
CREATE PROCEDURE [dbo].[sprocAssureDirectory] #directoryFullPath varchar(4000)
WITH EXECUTE AS SELF
AS
BEGIN
EXEC master.dbo.xp_create_subdir #directoryFullPath;
END
Just make sure you add any needed assertions/checks to your sproc that make sense for your application (e.g. the path can only be of a pattern that you expect).
Belated Update: Added the critical mention of marking the catalog as trustworthy.
You could give access for the user to use that stored proc explicitly. It is gonna be something like:
GRANT EXECUTE ON OBJECT::master.dbo.xp_create_subdir
TO <SQL USER>;
It sounds like that user is limited for a reason though and getting the extra permissions to run something like that can get a little push back from whoever is managing the DB. So be careful when dealing with getting the elevated privledges.
I've been working on giving a development team the ability to have read-only access to a SQL environment, I'm at the last step. I need them to be able to see users/logins and roles. I noticed that with view defintion granted on any given DB, it allows their login to view the users/roles for each DB, however even granted on master/msdb/model it does not allow the login to view the server wide logins/roles. What would be the best way to accomplish this? I have tried view defintion and I have tried view server state, neither has worked for server logins to be visible to the user.
Note: I don't want them to have any more access beyond that so I don't want them to be assigned a predefined role.
I'd recommend writing a stored procedure using Execute As permissions, and giving them permissions to run that. Have that stored proc output the list of users and you should be good to go.
I am not a db admin but i read an article related to setting security / permissions using schemas in sql server 2012. I tested a little for setting permissions to some views.
This might help http://msdn.microsoft.com/en-us/library/dd283095.aspx
This is my setup:
SQL server 2005
UserA already setup as user on the server but not on databaseA.
GRANT Execute ON [GetOrders] TO [UserA] AS [dbo]
As you can see, i have missed out a step. I haven't added UserA to the database yet. This doesn't fail and lets me grant execute on the object.
I believe in 2000 it would have thrown an error and not allowed me to do this.
Now, I have all these objects with the correct permissions set but the users cannot see the database. To resolve this i have to remove the users from the database, re-add them properly and then give permissions.
Why is this allowed and is there a way to either prevent it or have it create the db login automatically whenever a new user is given object permissions.
thanks.
This is the part throwing you off.
TO [UserA] AS [dbo]
Ditch the "as dbo" part. It's granting the right to the dbo user. Without the "AS [dbo]" part it will throw an error.
It's probably allowed to give DBAs the flexibility to modify the users and permissions when the database is not attached to your production server. I don't believe you have to re-add the users. Take a look at this guy's script: http://www.lazycoder.com/weblog/2007/06/04/re-associate-sql-users-with-logins/