In SQL Server Manager, we want a user to only see a specific database without giving him db_owner privileges. We already tried around with DENY VIEW ANY DATABASE TO test CASCADE, but that hides all databases. To let the database appear in the database list again, I read that we should give him db_owner rights. But that's not what we want.
Is there a way to specify on a per-user basis, which databases he or she could see in the list without admin privileges?
What would be the best way to allow users to manage their own database restores from backup files? The reason I ask is because I have a user who is the db_owner for
a db. He loses access as soon as he restores the database from a backup file from another instance(of course because he does not have access on that instance), and
then someone with sa permissions has to restore his permissions. Is there anyway he can restore the backups, and then put back the db owner permission on the database that he already had?
Your best bet at this point is to create a custom stored procedure that does the following style pseudo code:
Take the database name, backup file name
Check to make sure the person requesting is the owner
Restore the database over the original
Set the owner back to the original in #2
Build in some logic to check and make sure people aren't trying to abuse it, give bad values, etc. Sign the procedure with a certificate and use a special account just for this purpose to lock down possible intruders/malicious people.
what is the need of user with out log in in SQL Server?
There is a contained database. I have created a user who can log into the contained database.
How to port the database to another server without additional user configuration?
Is the "user with out log" is going to help in this context?
Want to know more about users with out log in
Experts..please share your views
Users that don't have a login are users that exist only at the database level and therefore you cannot log in to the server with them.
They can however be assigned permissions and can be used to sign modules within those databases.
The most common uses I see for them during my day to day work are either loginless users that are created from a certificate which is then used to sign stored procedures, this means that the user actually logging in to SQL server requires very few permissions in the database and all the work is done in the context of the loginless user, helping to increase security.
I also see loginless users that are not created from certificates, but are made owners of schemas or procedures which then execute as owner, similar to the above, this means that the user lgging in only needs execute rights on the procedure, no table access at all.
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.
I'd like to setup an SQL Auth user in MS SQL 2005 that can restore some, but not all, databases in a particular instance.
I'm not sure if I should use Server Roles for this, since they would seem to apply to all databases, but Database Role membership doesn't seem right either (I don't want the SQL user to potentially 'lose' their restore ability if they restored a backup that didn't contain their database role membership).
How can I accomplish this?
You can't set up a user as such. This permissions sits above database/users at the server/login level
The login could have "dbcreator" which says:
...and can alter and restore their own
databases.
Even using GRANT would be tricky if not impossible, say, to "GRANT CREATE ANY DATABASE"
Restore is, in a way, a drop and create. Or simply a create.
I'd suggest the best solution (but probably not what you want to hear...) would be to create your own stored proc in master that checks rights and issue the RESTORE command if the login is set up as a user in that DB
Example: sp_checkandrestore 'dbname', 'backupfile'