I have a SQL Server 2005 database and I need to be able to grant a user(someday a group) read only database permissions with the ability to view but not run or modify stored procedures across over a dozen databases. Is there a way to do this with the current database roles included with SQL Server 2005 or does the user have to be granted permissions on each individual stored procedure. Thank you.
GRANT VIEW ANY DEFINITION TO [Domain\UserName] worked for me.
Related
I have a user that have grants to execute one procedure into one SQL Server 2008 R2 database.
This procedure connects to other databases but execution fails for this user, because it do not see this other databases.
How can I have a user with execution grants of some procedures in a single database where this procedures connects to other databases?
Thank you.
The login used for execution needs permission to do what your procedure does on the target database(s) the procedure is working on.
I'm probably not phrasing that correctly. I have been asked to find a way to create a group in Azure; grant that group dbreader and dbwriter rights to SQL server, then create users in that group and assign non-Azure applications to those users. I am sure I'm not phrasing some of this correctly. The idea is that applications in the field should have access to the Azure-based Sql Server but only reading and writing to the DB.
RON
from your question it is not very clear if you are asking about SQL Server on the plain VM or SQL Server as a service (SQL Azure). If SQL Server on the VM, then it should be the same as locally.
If SQL Azure, you can try to add your user to the db_dbdatareader/writer role using Visual Studio or SSMS.
Or use the SQL syntax, something like this one:
CREATE ROLE MyDatabaseReaderRole AUTHORIZATION [dbo]
GRANT
ALTER,
CONTROL,
DELETE,
EXECUTE,
INSERT,
REFERENCES,
SELECT,
TAKE OWNERSHIP,
UPDATE,
VIEW DEFINITION
ON SCHEMA::dbo
TO MyDatabaseReaderRole
GO
-- Add an existing user to the new role created
EXEC sp_addrolemember 'MyDatabaseReaderRole', 'SomeUser'
GO
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".
At the bottom of most of our stored procedures we have a grant similar to
GRANT EXECUTE ON [dbo].[uspFOO] TO [DOMAIN\SQLServerUsers]
Luckily for me, our domain is changing and we now need to go through and change the permissions. Does anyone know of an easy way to do this using the DB metadata so I can pull out all the places where [DOMAIN\SQLServerUsers] is given permission to run and substitute it with [DOMAIN2\SQLServerUsers]?
Thanks.
For those asking, this is on SQL Server 2005.
What version of SQL Server are you on??
In 2005 and up, you could
create a new database role "db_executor" and do
GRANT EXECUTE TO db_executor
grant that database role to all necessary users
This will create a "catch all" role that has execute rights on every existing and future (!!) stored proc in your database. Yes, that does include future stored procs, too! Very handy indeed (at least as long as every user is allowed to execute all stored procs)
That way, you don't have to create separate GRANT EXECUTE statements for each and every stored proc.......
Can anyone help me with this problem please?
I have 2 databases on the same server, both owned by sa. A Windows login has permission to execute a stored proc in database A that selects data from a table database B. The stored proc and table are also both owned by dbo. The Windows login is a member of a Windows domain group that is a member of a database role in database A that has the permission to execute the stored proc, but it has not been granted or denied any permissions on database B directly. The login is able to execute stored procs in database A that use database A and other procs that access other databases that the login has permissions to already but when it attempts to execute this stored proc it generates the error "The server principal "" is not able to access the database "B" under the current security context." Cross database ownership chaining is enabled at the server level but the two databases have is_db_chaining_on = 0 in sys.databases.
Is it as simple as you have to enable cross-database ownership chaining at both the server and database level?
From memory if you enable cross-database chaining at the server level it is available for all databases, you do not have to specifically set it on the database level.
How did you set chaining on? For some system settings a restart is required, or you can run the RECONFIGURE command in a query window.
http://msdn.microsoft.com/en-us/library/ms176069(SQL.90).aspx