The problem is our user cannot be granted permission to VIEW ANY DATABASE, nor CREATE DATABASE. So we've setup an account that is db_owner of the database and created blank database to fill.
Tested locally, above works only when we GRANT user to VIEW ANY DATABASE so won't apply in our target environment. My assumption was that EF is trying to establish whether database is already there, but since it cannot see any it'll always try to create one. Is there any way around it? Ideally - is there a setting that will tell EF that DB is there and there's no need to look for it?
This is a bug in EF6. The code makes the incorrect assumption that db_id('dbname') works without VIEW ANY DATABASE. It only works if the login running the query is the database owner. Not a mere member of the DB_OWNER fixed database role. I've reported it, and suggesed an improvement. But I'm not sure it will get fixed.
As a workaround just make the app user the real database owner. That won't prevent sysadmins from connecting as dbo. eg
alter authorization on database::AppDatabase to Appuser
You'll have to drop the database user before making the login the owner.
I'm using SQL Server 2014/2016. Is it possible to deny a user(s) view access to all database but the ones they have access to without making the user owner?
I don't want the user to have owner permissions as well as I'll be adding multiple users to the database.
I've gone through a lot of threads and it doesn't seem like you can but it seems like an obvious feature that people may want so I'm not too sure.
DENY VIEW ANY DATABASE TO userName
ALTER AUTHORIZATION ON DATABASE:: [DbName] TO userName
Regards
in my SQL2008 I have a user which is in the "db_datareader", "db_datawriter" and "db_ddladmin" DB roles, however when he tries to modify a table with SSMS he receives a message saying:
You are not logged in as the database owner or system administrator. You might not be able to save changes to tables that you do not own.
Of course, I would like to avoid such message, but until now I did find the way...
Therefore, I try to modify the user by adding him to the "db_owner" role, and of course I do not have the message above.
My question is:
Is it possible to keep the user in the "db_owner" role, but deny some actions like alter user or ? I try "alter any user" securable on DB level, but it does not work...
THANKS!
If the user is part of db_ddladmin it shouldn't be a problem. This is just a warning
Members of the db_ddladmin fixed database role can run any Data Definition Language (DDL) command in a database. It is probably just a warning from SSMS, try it out create a user and try to alter some tables
My understanding has always been that any user with db_owner rights can do anything to a database, up to and including dropping it. Certainly, this was true through SQL 2005. I've heard nothing to imply that this has changed with SQL 2008.
Those are indeed warnings, and I don't see any way to disable that type of warning in SSMS.
In 2008R2 the behavior I'm seeing is users with "db_datareader", "db_datawriter" and "db_ddladmin" still need to be granted view definition to be able to make edits in SSMS by right-clicking and selecting design. If you haven't granted view definition, then the design view will open (with warnings) read-only.
See: MSFT Connect Bug
To me it seems more discoverable to assign view definition permissions to your ddladmin users through a role, rather than doing it for specific user accounts as stated in the workaround on Connect. This will add a db_definitionviewer database role:
USE <DB Name>;
CREATE ROLE db_definitionviewer;
GRANT VIEW DEFINITION TO db_definitionviewer;
EXEC sp_addrolemember 'db_definitionviewer', '<DOMAIN\group> | <DOMAIN\User>';
Here is the scenario. I have a SQL Server 2005 production database/server. It currently has developers and supporters who can connect to it. I need to create a security module that gives developers read-only access to all areas of the database. This means that a developer should be able to view all objects as well as scheduled activities/jobs only.
Is it possible to enable security in this way and if so can I be gently guided on how to achieve this. I am learning to be a DBA and creating snapshots of the databases are not an option.
Thank you all in advance.
There is permission to every object.
Create a stored procedure that grant each gruop the exact permission you need on the objects you need to protect.
I'm not quite sure I follow where this "security module" will be in the architecture. Anyhow, here's one possibility that secures it from the database end.
I'm going to assume you already have users created.
Create a new role (yourdb > security > roles > new database role), say "ReadOnlyDevelopers". Make the owner dbo or whatever makes sense. Do not select any schemas to be owned by the role. Populate the "Role Members" with your developers.
Next, open the properties page on your database. Go to the permissions page. Click Add... and add the new role. Under the permissions grid at the bottom, Grant SELECT to the role.
Now assuming your developers already belong to some other role, you'll need to go into the user properties and under Database Role Membership restrict them to just the new role. At this point they should be able to just read
I'm guessing that I'm missing a detail or two (the role may need to be grated a few additional rights to "see" the database, alter passwords, etc.) but I can't get to that level of detail without setting up the entire scenario. Hopefully this pushes you in the right direction.
Is there a way to prevent users from getting into SQL Server Management Studio so that they can't just edit table rows manually? They still need to access the tables by running my application.
You can use the DENY VIEW ANY DATABASE command for the particular user(s). This is a new feature available in SQL Server 2008.
It prevents the user from seeing the system catalog (sys.databases, sys.sysdatabases, etc.) and therefore makes the DB invisible to them in SQL Management Studio (SSMS).
Run this command from the Master Database:
DENY VIEW ANY DATABASE TO 'loginName'
The user is still able to access the database through your application. However, if they log in through SSMS, your database will not show up in the list of databases and if they open a query window, your database will not appear in the dropdown.
However, this is not fool-proof. If the user is smart enough to run the Query Command:
USE <YourDatabaseName>
Then they will see the database in the Query Analyzer.
Since this solution is taking you 90% there, I would give the database some obscure name not let the users know the name of the database.
You DO NOT need to worry about them having access to the tool. Simply make sure they do not know any of the SQL logins for the specific Databases that have read/write permissions, if they do, change the password. If they have access to the DB via Windows Authentication, make sure that they are in a datareader role. You can use roles to manage what the users can do in SQL.
You can use a trigger.
CREATE TRIGGER [TR_LOGON_APP]
ON ALL SERVER
FOR LOGON
AS
BEGIN
DECLARE #program_name nvarchar(128)
DECLARE #host_name nvarchar(128)
SELECT #program_name = program_name,
#host_name = host_name
FROM sys.dm_exec_sessions AS c
WHERE c.session_id = ##spid
IF ORIGINAL_LOGIN() IN('YOUR_APP_LOGIN_NAME')
AND #program_name LIKE '%Management%Studio%'
BEGIN
RAISERROR('This login is for application use only.',16,1)
ROLLBACK;
END
END;
https://www.sqlservercentral.com/Forums/1236514/How-to-prevent-user-login-to-SQL-Management-Studio-#bm1236562
I would suggest you lock down the database and give appropriate read-only (or other) rights to the user. That way the user can still use management studio to run select queries and such.
If you don't want the user to have any rights at all then you could do that as well.
If your application is running as a service/user account then only that account requires access to the database. The individual users' account do not require any access to the database and therefore they won't even have read access. Your app will be the gateway to the data.
If the users are running the application under their user accounts then grant them read-only permission. You can simply add them to the db_datareader role.
Hope this helps!
You can deny 'Users' access rights to the ssms.exe executable file, while granting the relevant users/administrators rights to it.
If your application only used stored procedures to modify the data, you could give the end users access to run the stored procs, but deny them access to modify the tables.
Don't let them know what the database login is.
If you can't restrict the login, use stored procedures exclusively for updates and disable any CREATE,DELETE,INSERT, or UPDATE permissions for that user.
An Application Role will allow you to secure database objects to your application instead of the logged on user.
I agree with Jon Erickson as a general rule
do not allow any users access to the tables, but only allow access through stored procs
do not allow general user accounts access to stored procs, but only the account your app runs under (whether it's an integrated login or SQL login)
Make well usage of Database Roles, if Users should only have SELECT (read) access assign them the db_datareader Role. Even if they login using SSMS they will can execute only SELECT statements.