Problem
I have a SQL Server login that is allowed to create stored procedures, but not execute them. I cannot use another login to grant execute so I am looking for an alternative way to either run the code in the sp or to grant these permissions.
The EXECUTE permission was denied on the object 'sp_mystoredprocedurename', database 'mydatabasename', schema 'dbo'.
The user cannot grant execute to itself
Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.
Background
We have a Windows software application, written in Powerbuilder, that creates and updates the SQL Server database it works on itself.
On first startup the application prompts for a database admin login which it uses 1 time (we don't store this information) to create the database and a login. The login is given db_ddladmin, db_datareader and db_datawriter permissions. We currently have hundreds of these applications and databases running on servers managed by us, but also on our customers' own servers.
For this reason I would do anything to prevent the need to ask the user for a db admin login again so I can grant the execute permissions, which would be the easiest way... Downgrading all servers to SQL Server 2000 is of course also not an option :)
The stored procedure I am trying to implement is a "getnewid" method. Currently my Powerbuilder code uses multiple embedded TSQL statements to achieve this but because of network performance issues I would like to move these to a single stored procedure.
Does this help ?
CREATE ROLE db_executer
GRANT EXECUTE to db_executer
EXEC sp_addrolemember N'db_executer', N'<username>'
Try this.
GRANT EXECUTE ON sp_OACreate to UserLogin
GO
Related
I have a mvc 4 web application that interacts with a sql server database over a number of environments.
The user I connect to the database with is different in each environment. I generate a generic script of my stored procedures during each build and deployment and run it in to each environment. In the script I grant execute permissions to the db user on each sproc.
At the moment I needed a script for each environment as the user is different in each - which is a pain!
Would it be possible to create a role in each environment, same name in each environment and grant execute permissions to the role as oppose to the user? The user would be set up as part of that role.
Yes, this is exactly what database roles are for, you create a custom database role, apply the permissions to that and then you simply add the user to that database role.
Have a look at the link below for details on how to accomplish this:
SQL Server - Custom Database Role
Create a new user/login in sql azure with access to read/insert/update on the database items like tables sp,view etc.
This user will not have the permission to drop table/drop procedures.
Please give me an example.
First connect to the server and switch to the master database. In master create a login and then add a user for that login to the master database.
CREATE LOGIN [MyLogin] WITH password='xxxxxxxxx'
GO
CREATE USER [MyUser] FOR LOGIN [MyLogin] WITH DEFAULT_SCHEMA=[dbo]
GO
Next connect/switch to the database you want the new user for. Create a user in that database
CREATE USER [MyUser] FOR LOGIN [MyLogin] WITH DEFAULT_SCHEMA=[dbo]
GO
EXEC sp_addrolemember 'db_datareader', 'MyUser';
GO
EXEC sp_addrolemember 'db_datawriter', 'MyUser';
GO
GRANT EXECUTE ON SCHEMA :: dbo TO MyUser;
GO
You can also use the Azure User Management console - AUMC to manage the Logins and Users.
It's an open-source project available on CodePlex AUMC.codeplex.com
UPDATE: Since CodePlex has been retired (thanks to #Danny the code was saved), I recreated a repo in GitHub and created a release.
This new version uses .NET 4.8
Project Description
Azure User Management Console - AUMC is a User
Graphic Interface (GUI) that manages the users and logins of an Azure
SQL database. The tool is simply converting your action into T-SQL
commands and executing them on the Azure SQL Database.
A quick simple tool with a user interface!
Enjoy!
please read this article from Microsoft on how to properly create logins, users and assigning access rights in SQL Azure: Managing Databases and Logins
Then, in order to assign or deny specific permissions, review this article from Microsoft as well: Granting Access to a Database Object
And here is the link to specifically deny access to permissions: Deny Object Permissions
Note that you can also apply permissions to schemas. A schema is a container of database objects on which you can assign permissions. So you could easily place all your stored procedures in a single schema that you created to that effect, deny alter/drop permission, and grant execute on the schema directly. This way, all the objects within that schema will inherit the permissions defined. Here is the article for schema permissions: GRANT Schema Permission
Also you can do it manually by assigning proper user roles. Check out article: How to create custom user login for Azure SQL Database
Some Azure sql administration tips can be found here
http://thetechnologychronicle.blogspot.in/2013/11/azure-sql-administration-useful-commands.html
http://thetechnologychronicle.blogspot.in/2013/11/securing-windows-azure-sql-using.html
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".
I've moved to creating/using schemas in Sql Server 2005, where I've also created database roles and assigned schemas to the roles.
The problem I have is one of the db roles I have should have full access - say SuperSysRole.
However, when I assign a login to that role, it cannot execute specific commands. In particular, I want a user within this role to manage password resets. However, when I execute the stored procedure, it does not return back all users in the database.
The stored procedure has been run which returns back the details and calls a view which integrates the sysusers and sysmembers tables.
The user, say myAdmin, has been assigned to the role SuperSysRole. The role SuperSysRole has been granted execute to the stored procedure selectRoles.
It's probably a simple thing but can someone please tell me what I am missing?
My application authenticates using the myAdmin user name and password. It works fine when I login with the sa account.
Database role membership is queryable through the sys.database_principals and sys.database_role_members catalog views, which are the proper catalog views to use instead of the deprecated sysusers and sysmembers. Both have the same security restrictions:
In SQL Server 2005 and later versions,
the visibility of the metadata in
catalog views is limited to securables
that a user either owns or on which
the user has been granted some
permission.
The necessary permissions are listed in GRANT Database Principal Permissions: VIEW DEFINITION. There is no permission that can be granted to view any principal and role definition.
Your best option is to create a procedure that selects from the proper metadata catalog views and sign this procedure with a credential that is added into the db_securityadmin role. See Signing an Activated Procedure for an example how to sign a procedure. The grant EXECUTE on this procedure to whoever required to view these principals and role memberships.
However, all of this will get you nowhere with regard with the declared intent: manage password resets. Only server principals (aka. logins) have passwords, and any scheme designed at the database principals level can have no effect on server principals, since they are the wrong abstraction. And since there are no server roles to define (you can only have Windows groups as roles, but you want to use SQL Auth), you cannot have this done by role membership.
My recommendation is, again, to use code signing. Create procedures that do the activities you want (query sys.server_principals and sys.sql_logins to inspect password expiration, issue ALTER LOGIN statements to reset passwords etc) then use code signing to sign these procedures and grant the required privileges to the signature. I refer you again to Signing an activated procedure for an example how to do that. Then grant EXECUTE on these procedures to the 'special' users that have to manage these.
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.......