I have a sql server 2012 instance set up as a filestore on a networked server. I need all users on computers on the same network to be able to browse the file system representing the file table. However all user can see the server, and top level directory but do no have permission to access/ open it.
What permissions should I be looking at to enable access.
use myDatabase
go
grant view definition to [user]
Run the following code within SQL
ALTER DATABASE myDatabase
SET FILESTREAM ( NON_TRANSACTED_ACCESS = FULL )
GO
Providing that FILESTREAM is enabled for the instance, this has been done, and a valid directory has been specified, it should work.
You could probably consider providing a Domain Group (1) access to the server and (2) database containing the filetable and then grant (3) specific permission to each Filetable to allow them access to its contents.
This could be done by using either using individual GRANT statements (SELECT, DELETE, UPDATE, INSERT - optional ALTER if you want them to be able to browse at the server/instance/filetablefolder level) or creating a Database role and giving it these permissions and then linking the Domain Group to that role.
some information on general FILETABLE access for users here
Add this to SQL accounts "NT AUTHORITY\Authenticated Users"
and give access to database
Related
I tried to migrate a SQL Server database by Export Data-tier Application (.bacpac file) from an Amazon RDS instance to other, but import didn't succeed. So now I want to delete the database (which is empty), when I try to:
DROP DATABASE mydatabase;
I get the error:
Cannot drop the database 'mydatabase', because it does not exist or
you do not have permission
Some context:
I've tried using SQL Server Management Studio, and choosing close connections: same error.
I'm logged as master user.
I can create and drop other databases, but not this one.
I just have these effective permissions on this database: CONNECT, SHOWPLAN, VIEW DATABASE STATE, VIEW DEFINITION (don't know why or how is this possible).
Any help is greatly appreciated!
I ran into this same issue. After trying to restore a database via SSMS using a .bacpac, it fails and leaves you with a database that you appear to not have permissions to drop.
A workaround, is to use the rdsadmin rename function to rename it to something else, which then seems to fix the permission issue and allows you to drop it.
EXEC rdsadmin.dbo.rds_modify_db_name N'<OldName>', N'<NewName>'
Then just drop the DB. Hope that helps someone else in the same predicament.
This is the answer for an old thread but who knows, it might help someone having the same issue.
I ran into the same problem, but in my case, my database was in an offline mode. If the database is in offline mode, it won't allow you to drop it with the drop command. first, you should bring the database back online by running this sp and then execute the drop table command.
EXEC rdsadmin.dbo.rds_set_database_online databasename
If your database is in a Multi-AZ deployment, then you need to run this command to drop those databases:
EXECUTE msdb.dbo.rds_drop_database N'DBName'
Sounds like your not a member of the correct role.
https://msdn.microsoft.com/en-us/library/ee240822.aspx
Permissions
A DAC can only be deleted by members of the sysadmin or serveradmin fixed server roles, or by the database owner. The built-in SQL Server system administrator account named sa can also launch the wizard.
https://msdn.microsoft.com/en-us/library/ms178613.aspx
Permissions
SQL Server - Requires the CONTROL permission on the database, or ALTER ANY DATABASE permission, or membership in the db_owner fixed database role.
Azure SQL Database - Only the server-level principal login (created by the provisioning process) or members of the dbmanager database role can drop a database.
Parallel Data Warehouse - Requires the CONTROL permission on the database, or ALTER ANY DATABASE permission, or membership in the db_owner fixed database role.
I have a user who needs to rename a database. I could give dbcreator privileges, but this would allow the user to rename any database, and even create new ones.
So I tried to create a stored procedure that the user would call to do the job.
CREATE PROCEDURE SPMyRenameDB
WITH EXECUTE AS 'MySuperUser' -- MySuperUser is a SQL user with dbcreator permission
AS
ALTER DATABASE A MODIFY NAME = B
GO
I get an error :
The server principal "MySuperUser" is not able to access the database "A" under the current security context.
I tried with sp_renamedb, I get : User does not have permission to perform this action.
Even a simple SELECT statement to a table in database A is not allowed : The server principal "MySuperUser" is not able to access the database "A" under the current security context.
When I connect as MySuperUser and query the database A, it works as expected. (MySuperUser is a SQL user with dbCreator and sysAdmin privileges on the server).
I suspect that the "WITH EXECUTE AS" statement has some security restrictions that do not allow to use it outside of the current database.
The Stored Procedure is in a database (other than A and B) where the user has db_owner permissions.
Any suggestions ? I do not need to stick with my "WITH EXECUTE AS" approach. Anything that would do the trick is welcome.
Thanks,
Yves
Check ALTER DATABASE in MSDN -> Permissions
Requires ALTER permission on the database.
So just query as following
USE A
GO
GRANT ALTER TO 'someuser'
GO
User must be member of dbcreator server role. (MSDN documentation is wrong!).
I am trying to give all the permissions to a user in the User Mapping section of a database. But, I am encountering this error:
"Cannot use special principal dbo"
Server roles of the user:
This is happening because the user 'sarin' is the actual owner of the database "dbemployee" - as such, they can only have db_owner, and cannot be assigned any further database roles.
Nor do they need to be. If they're the DB owner, they already have permission to do anything they want to within this database.
(To see the owner of the database, open the properties of the database. The Owner is listed on the general tab).
To change the owner of the database, you can use sp_changedbowner or ALTER AUTHORIZATION (the latter being apparently the preferred way for future development, but since this kind of thing tends to be a one off...)
Fix: Cannot use the special principal ‘sa’. Microsoft SQL Server, Error: 15405
When importing a database in your SQL instance you would find yourself with Cannot use the special principal 'sa'. Microsoft SQL Server, Error: 15405 popping out when setting the sa user as the DBO of the database. To fix this,
Open SQL Management Studio and Click New Query. Type:
USE mydatabase
exec sp_changedbowner 'sa', 'true'
Close the new query and after viewing the security of the sa, you will find that that sa is the DBO of the database. (14444)
Source:
http://www.noelpulis.com/fix-cannot-use-the-special-principal-sa-microsoft-sql-server-error-15405/
This answer doesn't help for SQL databases where SharePoint is connected. db_securityadmin is required for the configuration databases. In order to add db_securityadmin, you will need to change the owner of the database to an administrative account. You can use that account just for dbo roles.
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.
How can you hide databases you do not have access rights to when logging into SQL Server 2005 / 2008?
Currently if a user connects, they see all the databases on the server, meaning they have to scan though the list to find their database.
After hours of trying to figure out how to create a user account which only has access to 1 DB, and can only see that DB. I think i figured it out!!!!
Create a user account ( make sure its not mapped to any Database, otherwise you will get the final error Msg 15110, Level 16, State 1 and note proposed solution)
USE [master]
GO
CREATE LOGIN [us4]
WITH PASSWORD=N'123',
DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=OFF,
CHECK_POLICY=OFF
Right Click on the upper section of the SQL (SQLSERVER Name)>Properties>Permissions>Click on the user account, and select Deny to view databases.
use [master]
GO
DENY VIEW ANY DATABASE TO [us4]
Right Click on the newly created DB, Properties,Files, and change the Owner to the newly created account.(important note: ALTER ROLE [db_owner] ADD MEMBER [us4] does not work)
USE [dbname]
GO
EXEC dbo.sp_changedbowner #loginame = N'us4', #map = false
At this point, once the user logs in he will see the Master,tempdb and will also see the new DB which he is a DB Owner of..You may want to go to Tools>Option and enabled the option to hide system objects so that you don't show the master,tempdb,etc. You may also need SP1 if this option does not work
Msg 15110, Level 16, State 1, Line 1
The proposed new database owner is already a user or aliased in the database.
proposed solution to Msg 15110: to resolve above error simply delete the user from database security node and try again
Hope that helps...
Nikhil
This actually won't work the way that makes sense or that you might expect that it would.
You REVOKE VIEW ANY DATABASE from the public role, but then the user has to be the database owner of the database or it can't be seen, but it still can be accessed.
The problem is a Database Engine Security shortcoming and not likely to be fixed in the current or future release of SQL Server.
Erland Sommarskog opened the following connect item for this a while ago, and it recently was discussed on twitter and with Microsoft by the SQL MVP's.
Vote for the connect and help make it more of a priority for Microsoft to fix:
Connect Feedback
Basically the permissions are stored at the database level, so it would require enumerating each database to determine if the user has connect rights to display the database in the object explorer, which is an expensive task to perform and how the older EM used to do things.
The proposes solution is for this information to be maintained at the server level as well, which is a major change.
You would need to revoke the permission 'VIEW ANY DATABASE' from the role PUBLIC (SQL SERVER 2005 onwards)
Add user to DB as Db owner after removing VIEW ANY DATABASE rights
This will show only the database owned by the login in SSMS.
USE master; GO
DENY VIEW ANY DATABASE TO [loginname]; GO
USE [your db]; GO
DROP USER [loginname]; GO
USE master; GO
ALTER AUTHORIZATION ON DATABASE::[your db]TO [loginname]; GO
Note: this requires the login to exists already
There appears to be a server-side setting on MS SQL 2005 and 2008 to restrict the databases a user may see. I found the following text at sql-server-performance.com
In SQL Server 2005 it is possible with a new server side role that has been created. VIEW ANY DATABASE permission is a new, server-level permission. A login that is granted with this permission can see metadata that describes all databases, regardless of whether the login owns or can actually use a particular database. Please note By default, the VIEW ANY DATABASE permission is granted to the public role. Therefore, by default, every user that connects to an instance of SQL Server 2005 can see all databases in the instance.