I am granting permission on some objects to my user in a database, Is there any way to grant permission to user without using database role?
I can easily do it by creating database role, but I do not want to use role.
I assigned some objects to my user by Database User, in Securables tab, it didn't work!
create user [user_test] for login [login_test]
create role role_test authorization user_test
exec sp_addrolemember 'role_test', 'user_test'
grant select on object::dbUser.tbl_05 to role_test
I expected I could grant permission to my user and not to use Database Role.
You have (at least) 2 options here, you can assign the permission straight to your DB user (as mentioned in the comment) or you can grant permission on a certificate, which might give you better control in a production environment.
Related
Users are created with dbcreator and public role. They can create and delete their own databases.
How do I give them the ability to grant permission to their database to other users? Currently they can only see public and guest object.
You don't need to make someone a sysadmin. The minimum required permissions are described on this page.
In SQL Server, requires ALTER ANY LOGIN permission on the server or
membership in the securityadmin fixed server role.
These permissions still give a user a lot of power. They are able to delete other sysadmin logins.
Perhaps partial contained databases can be a solution for you.
A database user in a regular database needs to be mapped to a login on server level. Managing these server level logins requires a lot of permissions.
Database users within a partially contained database can exists without a login. These users can only login to that specific database. No server level permissions are required to manage these users.
I have 2 database users called SQLUser1 and SQLUser2. How can I grant INSERT permission to SQLUser2 at database level using SQLUser1?
After reading about database membership roles, I think I can achieve the solution by playing with memberships of SQLUser1. Can it be solved by giving db_securityadmin and db_accessadmin to SQLUser1?How can I control permissions of one user by another user in database level?
Any help appreciated.
Thanks,
Deeps
You must grant all/specific privilege to SQLUser1 with grant option as sa (sys admin or other higher privileged user). Then SQLUser1 will become eligible to grant privilege to SQLUser2 as outlined below
GRANT ALL TO SQLUser1 WITH GRANT OPTION
You need not to assign ALL privilege to SQLUser1. Even SQLUser1 can have only INSERT permission but WITH GRANT OPTION make him eligible to grant the same permission to other user.
Then as SQLUser1 grant specific privilege to SQLUser2
GRANT INSERT TO SQLUser2
You can do the above mentioned steps using GUI (SSMS) as well.
For more information on GRANT see HERE
you need to use a user which is db_owner.
Select the user2 and click Properties, then user mappings... using SQL Server Management Studio.
I am creating some users on SQL server but I am a little confused as to whether I grant "alter any login" or "alter any linked server" to my LOGIN or to the USER account?
As you all know, on SQL server, you create users in this order:
Create LOGIN sysUser1 (in master db)
Create USER myUser1 for LOGIN sysUser1 (in users db)
CREATE SCHEMA myUser1 AUTHORIZATION myUser1
then, run sp_addrolemember for myUser1 as needed
then, do grants
I am confused as to whether I should:
grant alter any login to myUser1
or
grant alter any login to sysUser1
Can anyone clarify? Am I thinking of this incorrectly?
ALTER LOGIN is a server level permission, so you can't grant it to database users. You need to grant it to sysUser1 in your case.
See http://msdn.microsoft.com/en-us/library/ms186717.aspx
Edit: Dito for linked server.
Logins and Linked Servers are both objects that exist at the instance level, as opposed to at the database level, so these permissions both need to be applied to the login, rather than the user.
If you are using SQL Server 2012, then it is possible to create you own Instance level roles, but in 2008 and below, you are rrestricted to the built in server roles.
There is a server role called setupadmin that lets members manage linked servers.
I want to grant access to a user to a specific database with read and write access. The user is already available in the domain but not in the DB.
So, how can I give them that access with creating a new user and password?
Someone told me that it can be done with only specifying the user, domain & the DB that you want to give the user the access to without needing to create a new user and password.
This is the old way that I was implementing. It works but it creates a new login and user rather than using the one that is available in the domain:
use DBName;
create login a_2 with password='Aa123';
create user a_2 for login a_2;
grant insert to a_2;
grant select to a_2;
This is a two-step process:
you need to create a login to SQL Server for that user, based on its Windows account
CREATE LOGIN [<domainName>\<loginName>] FROM WINDOWS;
you need to grant this login permission to access a database:
USE (your database)
CREATE USER (username) FOR LOGIN (your login name)
Once you have that user in your database, you can give it any rights you want, e.g. you could assign it the db_datareader database role to read all tables.
USE (your database)
EXEC sp_addrolemember 'db_datareader', '(your user name)'
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.