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/
Related
I created a user and gave him access to run sp. That sp also has to update a table based on the type of work.
But when the user runs sp, it gives an error:
The SELECT permission was denied on the object 'fn_dblog', database 'mssqlsystemresource', schema 'sys'.
Does anyone have a solution to this problem?
The required permission to use the fn_dblog system table-valued function is sysadmin role membership.
Importantly, this function is undocumented so it should not be used in application code, especially to update a table.
EDIT:
Your comment indicates the function is used in a trigger. You could create a certificate and certificate user that's a sysadmin role member as described here and then sign the trigger with that certificate. That will confer sysadmin permissions to the trigger code and allow non-sysadmin users to use the function but only in the context of the trigger.
I would normally include an example T-SQL script in my answer but I want to strongly discourage you from going down the path of using the undocumented system function in app code.
You have a classic XY problem that needs to be solved differently. Ask a new question about how to provide the functionality you need without using fn_dblog. Include your existing code in the question.
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 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.
I am trying to give permissions to a user I just created and has a login associated logged into my master.
I was not able to give any permissions since it says you do not have permissions to do this.
I gave myself dbowner rights in the master but still.
Any help?
Might it be that the database I created does not have the schema dbo?
UPDATE:
I thought you said the user you added didn't have any permissions, my bad! Well the answer still might be helpful :-)
I'm not an SQL expert so this may not answer your question, but I had to do something like this today and listing my steps might help.
You can use a graphical tool like Azure User Management Console (AUMC) if you want to add users without having to write a bunch of SQL queries.
Connect to your server, go to Logins and create a new login (if you want to give server access as well), then go to Users, select your database, create a new user, then here you can link the user to the login you just created and give database permissions.
Here is the documentation on granting users/logins permissions:
http://blogs.msdn.com/b/sqlazure/archive/2010/06/21/10028038.aspx
EXEC sp_addrolemember 'db_datareader', 'readonlyuser';
I am using SQL Server 2008 Express edition.
I have created a Login , User, Role and Schema.
I have mapped the user to the login, and assigned the role to the user.
The schema contains a number of tables and stored procedures.
I would like the Role to have execute permissions on the entire schema.
I have tried granting execute permission through management studio and through entering the command in a query window.
GRANT EXEC ON SCHEMA::schema_name TO role_name
But When I connect to the database using SQL management studio (as the login I have created) firstly I cannot see the stored procedures, but more importantly I get a permission denied error when attempting to run them.
The stored procedure in question does nothing except select data from a table within the same schma.
I have tried creating the stored procedure with and without the line:
WITH EXECUTE AS OWNER
This doesn't make any difference.
I suspect that I have made an error when creating my schema, or there is an ownership issue somewhere, but I am really struggling to get something working.
The only way I have successfully managed to execute the stored procedures is by granting control permissions to the role as well as execute, but I don't believe this is the correct, secure way to proceed.
Any suggestions/comments would be really appreciated.
Thanks.
There are couple of issues that I can see in your case.
First of all you would need View Definition granted for you to be able to see the objects in the Management studio.
I would recommend this if you want the role to have all permissions,
GRANT EXECUTE, SELECT, INSERT, UPDATE, DELETE, VIEW DEFINITION
ON Schema::SchemaName TO [RoleName/LoginName]
Also make sure the owner of your user-defined schema is "dbo".