Best way to create SQL user with read only permissions? - sql-server

What is the best-practice to create a read-only user for a specific database?
I created a new user and granted the db_datareader role, however, this user still has access to the master db and other system databases. is that ok? or should i deny access on some system tables/databases as well to make it more secure?
Thanks.
Ok, so if i create a new user, will he have any more default permissions i have to deny?
if i do
~create login
~create user for login..
~grant EXECUTE for user
will the user only have EXECUTE permissions or will he have additional permissions as well for the active database?

Hi I believe the user can view other database in the object explorer too.
CREATE LOGIN me with password = 'me', check_policy = off
sp_changedbowner 'me'
GO
USE MASTER
GO
DENY VIEW ANY DATABASE TO me
GO

Well you can use denywrite as an role option. The user has to "see" the master, because the master contains the list of databases that he will enventually connect to, but he will only have guest privalages there. You can then deny access to other specific databases. AFAIK he does not need to see tempdb or msdb as its the SQL engine that accesses these

Related

T-SQL grant login for attach or detach databases

I have a question about security in SQL Server.
Is it possible to create a login with only authorization to attach or detach databases?
I don't want it as sysadmin.
If you check the documentation, you will see that for attaching a database we need:
Requires CREATE DATABASE, CREATE ANY DATABASE, or ALTER ANY DATABASE
permission.
and for detaching:
Requires membership in the db_owner fixed database role.
If you check the security hierarchy and download the Chart of SQL Server Permissions, you can check what other permission a user will have if he has any of the above permissions.
For example, if he has ALTER ANY DATABASE:
Basically, these rights are on the top of the security hierarchy and if you allow a user the ability to attach database, ze will be able to do other operations overt it, too.
If you don't want to make the user member of sysadmin role, that's OK. You can make the user member of dbcreator role:

Azure SQL database - application user setup

I am using Azure SQL database with sharding (single tenant approach). So, when the application connects to DB it goes into Shard and creates a proper connection to the tenant's DB (tenant is identified by login name).
However, we've been using a server admin credentials for that on a development stage.
Now, I'd like to create a separate application user with much more limited permissions compared to server admin.
In a very general case, what I want is to have a user that can connect to the Shard Map and figure out a connection string to any of the Shards, but have different permissions for each of the shards. For example, some application user may need to be able to connect to DB_1 with full read-write permissions, to DB_2 with read-only permissions and no permissions to connect to DB_3.
In a simpler case I just need a user that doesn't have any update permissions to ShardMap and other internal databases, but has a normal read/write/execute access to all tenant databases(shards).
I was googling around and din't find any good recipe how to do that, what are the best practices, etc.
I'd appreciate if someone could answer me or point to a docs.
Thank yuo!
In each database create a role for the Application Users, and grant the minimal permissions needed for the application to run. Granting permissions on the Schema level is a good choice here, as you don't have to manage object-level permissions.
create role ApplicationUsers;
grant select, insert, update, delete, execute on schema::dbo to ApplicationUsers;
Then if you want a single identity to access all the databases, create a login with a password. Then in each Tenant database create a user mapped to that login.
--create a server-level Login
create login AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
--add a user mapped to that login in each database
create user AppUser for login AppUser;
alter role ApplicationUsres add member AppUser;
Or create a user in each database with a different password or a database user mapped to an Azure Active Directory identity.
create user AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
alter role ApplicationUsers add member AppUser;
or
create user [tenant123user#mydomain.onmicrosoft.com] from external provider;
alter role ApplicationUsers add member [tenant123user#mydomain.onmicrosoft.com];

Restrict database for only one user

i dont know how to ask my question but still i try. I am using SQLServer2008R2. I have created one database say DB1 and also created one SQLServer user say User1. Now I want that only User1 can have access of DB1 database and other user can not access to DB1.
You should look at the security node in management studio for your database.
Check that your user is the only login that associated with your database.
If you want to prevent that user creating another user, revoke his permissions to create users.
For more information on users and roles, see the documentation http://msdn.microsoft.com/en-us/library/aa337552.aspx

Preserving SQLServer permissions

How can I stop a particular user from accessing the database for a period of time but at the same time not lose the permissions the user has on db objects.
Basically when he comes back (ie when access is given back) he should have all the permissions he had before his access was cut off. If I use sp_revokedbaccess 'myuser' the user myuser loses all permissions he had on db objects.
Is there a way to preserve myuser's permissions without resorting to cumbersome backup permissions and restore permissions kind of workarounds?
Thoughts:
DENY CONNECT user or DENY CONNECT SQL TO login (sp_revokedbaccess is deprecated)
You cannot use ALTER_LOGIN with the DISABLE argument to deny access to a Windows group (quoted from link)
Assign all rights to a database role, then revoke rights from user. Add user to role when needed. It's a bad idea to assign object rights to users directly anyway.
If user has sysadmin rights, you can't deny them anything at all (perhaps CONNECT SQL?)
If user has db_owner rights (assumes set up in DB), you can't deny them anything in the database except CONNECT
The simplest way i see it is to disable the login. You can do this on the login properties in SSMS under the status page.
You can achieve the same thing with the following T-SQL:
Assuming your login is bob a sql login, but can also be a windows login
ALTER LOGIN bob DISABLE
Then, to enable the login
ALTER LOGIN bob enable
You should be able to explicitly DENY him a permission, then revoke the deny.
You can also disable the login with ALTER LOGIN ... DISABLE, but will block at server level, not database level.
A hack solution is to map the user to a different login, then map him back (ALTER USER .. LOGIN = ...), but is a hack and I'm not sure even works correctly.
How is the user accessing the database? If via an application, then just log the user out and require the user to re-authenticate.
we want to remove access during maintenance but bring him back after it is done.
Have the maintenance process acquire exclusive locks on whatever tables it is processing. This locks everyone out until the processing is complete.
Can you switch the database to single user mode? http://msdn.microsoft.com/en-us/library/ms345598.aspx
Or script up the permissions before you remove them: http://www.sql-server-performance.com/articles/dba/object_permission_scripts_p1.aspx. I know this is "backup permissions and restore permissions" - but this script makes the process a lot less cumbersome.
If the current password is known, change the password to a temporary value during the maintenance window. Re-setting the password to its initial value serves this purpose without making any material changes to the account.
If you are using Windows authentication and you can lock out this user from everything on the domain, you can set the times the user is allowed to log on in Active Directory. I can't provide detailed instructions but there should be something on ServerFault by now.

Permissions required for 'CREATE USER' in SQL Server 2005?

I am trying to create a SQL server login and database user from within my application, along with a custom application user row. I want these users to be able to create other users - i.e. the application will control who can/can't create users but I need all users to have permissions for creating SQL server logins and database users.
I have got the server login permissions working - i.e. an existing user/login can create a new login - by adding the logins to the 'securityadmin' server role - which grants the 'ALTER ANY LOGIN' privilege.
I tried to do the same with the database users - adding them to the 'db_accessadmin' database role - which supposedly grants the ALTER ANY USER privilege, which is required for CREATE USER.
However any time I try to create a new database user using a user with the above privileges I get a permissions exception.
I have tried manually granting the ALTER ANY USER permission to a particular user (GRANT ALTER ANY USER TO demouser) but this doesn't work either.
Technically, yes. Whether it's right or wrong... no comment.
Anyway, database security is split into 2 functions:
db_accessadmin to manage users (or "ALTER ANY USER" permission as you mentioned)
db_securityadmin allows you to manage roles memberships and object permissions (or "ALTER ANY ROLE permission)
This is mentioned for sp_addrolemember.
You are actually changing the role, not the user, by running sp_addrolemember so "ALTER ANY ROLE" is enough without having full db_owner rights.
My bad - I have found the issue - it was not the CREATE USER that was failing, but a subsequent call to 'sp_addrolemember'. This requires further permissions that I wasn't assigning.
In particular I needed to add my users to the db_owner database role in order to allow them to assign other/new users to fixed database roles.
Is there a cleaner way to allow me to achieve what I am trying to do here - i.e. create users that are allowed to create other users?
This seems very dangerous, easily becoming a security nightmare. Not knowing anything about why you think this is the best solution to accomplish your objective I can't really tell you not to do it this way, but wow!! - I would think long and hard about whether this really is necessary. The spider-webbing of users just seems like it could quickly be impossible to manage from a DBA perspective.
Would you not be able to just have one SQL account that has the permissions to add users, and the application uses that every time to add new users? Those users then would not need the ability to add other users. Maybe this won't work for your specific objective, but surely there is some other way.
But having said all that ... no, there is not really a cleaner way. The user would have to be assigned to the correct roles in order to have the ability to later add other users.
/*
TOPIC: create a login ,who can add other logins to databases (securityadmin server role)
*/
USE MASTER
GO
Create login securityTestLogin with password = '##somepassword123'
-----add this to server , this is server level security role -------
EXEC master..sp_addsrvrolemember #loginame = N'securityTestLogin', #rolename = N'securityadmin'
--- first this login should be a user in database where we want to give other users access
USE HTDBA
GO
Create user securityTestLogin for login securityTestLogin
EXEC sp_addrolemember N'db_accessadmin', N'securityTestLogin'
-- depends on your requriemtnt you might also want this permission too
--EXEC sp_addrolemember N'db_securityadmin', N'securityTestLogin'
GO
------ Now we think about adding other users to different database roles -------------
/*
There is one gottcha , db_securityadmin role cannot add users to the fixed database roles ,only
db_owner can perform this action , but for security we don't want to give this permission .
so we need a work around
Create a role with required permission and then add users to that role.
*/
--Create user defined database role Readers
EXEC sp_addrole DBUser
-- Add this role to fixeddbroles to get database level permission
EXEC sp_addrolemember db_datareader, DBUser
EXEC sp_addrolemember db_datawriter, DBUser
GO
--------READY TO TEST --------
------ we are using this sample login for test
use master
Go
Create login testlogin1 with password='##somepassword123'
use HTDBA
go
Create user testlogin1 for login testlogin1
--- now add this user to user created DBUser role .
EXEC sp_addrolemember DBUser, testlogin1
A very good article on SQL permissions:
http://www.sqlservercentral.com/articles/Security/sqlserversecurityfixeddatabaseroles/1231/

Resources