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.
Related
Suppose I have a login metamanager\test which shows when I execute T-SQL, but it is not there when when I expand Security -> Login in SSMS.
Same with a database user.
I try to replicate but failed
use master
select * from sys.syslogins is used for login
use DB
select * from sys.sysusers is used for database user
A LOGIN and a USER are completely different objects.
A LOGIN is a server object, and appear in sys.syslogins, as you see.
A USER is a database object, and for a LOGIN to have access to a database, it needs to have a USER mapped to the LOGIN in that database. A LOGIN with no mapped logins in any databases, and without any server level roles, will be unable to access any of the database on the instance, apart from those that the public roles has in tempdb and master.
It appears, here, you need to create the user in the database, and then give it the appropriate permissions. You can create the USER with the following:
USE {YourDatabase};
GO
CREATE USER 'metamanager\test' FOR LOGIN 'metamanager\test';
You'll need to give it the appropriate permissions afterwards.
Also, after you have created the user, ensure you have refreshed your object explorer. Object explorer doesn't automatically refresh after you create an object.
Not sure if you explaining it correctly, but syslogins and server_principals are about the same. Only the difference that server_principals include "Roles".
As far as I know it is impossible to have something in syslogins, which does not exist in server_principals.
Is it somehow possible to set the user permissions per connection in SQL-Server?
for example:
DENY insert ON all TO user
DENY update ON all TO user
DENY delete ON all TO user
So, suppose a user is connected as sa (* see EDIT) in my application, can I somehow change (and possibly restore) permissions at some point for this user (so for e.g. at that point he has a read-only access)?
EDIT: sorry for giving a wrong example. the user is NOT sa but other user with full access.
As I mentioned in the comments, permissions aren't set at connection level, they are set at Login and User level.
If you have a connection, and you change the permissions of the login/user being used, those permissions will be applied immediately to that connection, and any others; thus a connection using the Login and User AppUser cannot have different permissions to another connection user the exact same Login and User.
If you need an application to have different permissions for different things, there's nothing wrong with creating multiple Logins and Users; each with their own permissions. You then control the Login the application uses my using different connection string, depending on the role needed. This is quite a common practice; for example you might have a different database for your application's security model, and thus a different login is used to make changes to that database.
there are system stored procedures about security section and i guess that would be the only way since SQL gotta be secured.
https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/security-stored-procedures-transact-sql?view=sql-server-2017
https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-dropsrvrolemember-transact-sql?view=sql-server-2017
EXEC sp_dropsrvrolemember 'JackO', 'sysadmin';
I wonder if there is a way to grant permission to an SQL server user to restore the database but not write data into the tables via ssms.
In fact, I don't want a user to go to the ssms and change data unless the user is "sa".
Is there a chance to perform it?
If a Login is restoring an existing database, that database will contain any user permissions it previously had; if those users can/do map to logins on that server, then those Logins will map to those users and thus retain those permissions. You can't, for example, stop a user with the db_datawriter database role performing an INSERT, UPDATE, etc, on an object in the database, unless they also explicitly have a DENY. If, therefore, the Login is not an sa but can restore the database, and that Login maps to a user with "write" privileges, then they can write to the restored db. You can't stop that.
If you want to control who can write to a restored database, then the database administrator(s) should be the only Login's that can restore databases, then, have scripts set up that change the permissions on the newly restored database, which removes any user permissions to "write" to the database, and also removes any user's from the db_owner role.
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
Is there an easy way to lock a sql server express 2005 so that only DBOs can get to it, assuming you have a system where everyone has been granted rights individually and you can't just disable a role?
ALTER DATABASE <dbname> SET RESTRICTED_USER
and to set operation back to normal:
ALTER DATABASE <dbname> SET MULTI_USER
You can remove all other access than dbo from the database, then only the dbo's will be able to use it.
However, members of the sysadmin group are by default dbo's, I am not sure if you can block access for these users.
Is there not a server wide setting for DBO-Only? I do not have an example close to hand, but from my Sybase days I seem to remember such a setting.
Restricted user mode should do it. Granted it will also let in dbcreator and sysadmin, but that only makes sense. So ensure your accounts don't have one of those roles either or they will be able to get in when in Restricted User Mode.
http://technet.microsoft.com/en-us/library/ms188124.aspx
Restrict Access
Specify which users may access the database. Possible values are:
* Multiple
The normal state for a production database, allows multiple users to access the database at once.
* Single
Used for maintenance actions, only one user is allowed to access the database at once.
* Restricted
Only members of the db_owner, dbcreator, or sysadmin roles can use the database.