A software company uses an application that stores data in an SQL database.
A recent investigation lead the company to identify that users of the software were taking advantage of NT AUTHORITY\System SQL login as it had sysadmin access. This was recently removed, but as a result of the removal a number of I.T providers for users of the software have reported issues with their third-party backups. Most reports of issues are environments where they're using N-Able Cove for backups, but there's also some environments using Veeam. These are being used for system snapshots, not individual SQL database backups.
From our investigation, these backup solutions simply require the SQLWriter to appear when running "vssadmin list writers" from an elevated Command Prompt window.
Our testing on an isolated and basic environment shows that simply giving the NT SERVICE\SQLWriter login sysadmin access should allow the SQLWriter to appear when running the command from Command Prompt and allow the backup solutions to work without issue. However, real world testing shows that the only way to allow these backup solutions to work is by re-adding sysadmin access to the NT AUTHORITY\System login.
Is anyone familiar with both N-Able Cove and/or Veeam backup software and able to provide information on what exact permissions\access these backup solutions require?
Is there a way to get them to work without giving sysadmin to the NT AUTHORITY\System login? Eg- create a separate SQL login with the bare minimum permissions, or use the NT SERVICE\SQLWriter login?
Related
I have a (S:\) drive with permissions for only myself and the SYSTEM user.
I just downloaded SQL SERVER EXPRESS 2017, and when I go to create a new database, it cannot see that drive as a place to create the database.
I tried giving the Everyone group full permissions on the drive, and then it showed up as a place to make the new database.
I am wondering what user I need to actually give permissions too, as it is clearly not running under my user, since my user has full control on the drive, and it's not running as SYSTEM, since that user has full control of the drive. I don't want to give "Everyone" permissions to the drive.
Note: Doing a bit more experiments, after removing the Everyone permissions, I went looking through my users list (in the Security tab of the Drive properties), and the only user that looks to have anything to do with SQL is SQLServer2005SQLBrowserUser${myUserName}, but giving this user full control did not allow SSMS to see the drive again.
Run this query:
SELECT * FROM sys.dm_server_services
And you will see current available services on your SQL Server instance and the account mapped to each one. Add permissions to the one that's below the servicename: SQL Server (MSSQLSERVER), it will be most likely NT Service\MSSQLSERVER.
If you use Jobs on the Agent, you will need to give permissions to that account also.
How do I set up a database so that one does not have access to it? Even with installing SQL Server Management Studio on local machine.
In SQL Server with Windows user or sa can access all databases. How do you limit the access DB of the users?
For assuming that SQL Server is installed on the local machine, not on the server
You can try Single User Mode.
From the linked MSDN article:
Single-user mode specifies that only one user at a time can access the database and is generally used for maintenance actions.
Edit: You edited your question. Now it sounds more like you're asking about Security instead of how to limit the database to one user.
You can edit a user's security in SQL Server Management Studio by drilling down into Security > Logins. There you will see all logins to your instance. You can right click these entries and select Properties to made updates. The easiest way to completely bar a user from accessing any of the databases on the server is by selecting "Disabled" from the "Status" tab.
Well, if you really want to limit this to just one user, there is a simple way (but a bit risky).
Your Windows user is included in the group BuiltinAdministrators. If you really want to remove your Windows user, rerun the installation process and during the setup just change the users in those group.
But beware, you should provide another user, which has access to your database otherwise you end up with a database server without access to it.
Ater that, setup a database login and grant him access to the database you desire.
In the end, you can disable the sa login. This will prevent access with the sa account. But you should have a user which can manage logins and more. Otherwise you have no chance to recreate the password or any other administrative tasks.
I've been searching hard to get my head around security related issues in a SQL Server.
We're developing a .NET application that targets SQL Server 2008 and we want to use FileStream.
Now I've found out that SQL Server only allows FileStream through the Win32 API if you use Integrated Security. The problem is that we have around 80% of our application finished, but it is entirely based on SQL Authentication. So we are doing INSERT's straight form our application and are not using Stored Procedures for every CRUD operation.
This is relatively safe because I can store the the SQL username and password in an encrypted form. I know the password is transported in Clear Text, but I'm willing to accept that.
We want end-users to be able to connect to the databse through tools such as Crystal Reports and for that we have an extra SQL login that has only SELECT-rights granted.
Now, if we change to Integrated Security we would have to give individual users (via AD groups, etc.) rights to do the things the application can do. Otherwise the application would not be able to do it's work. But then the end-user would also have these rights when he connects straight to the DB.
I see people saying that you should use Stored Procedures for every CRUD operation and grant the EXEC-rights only to the AD-group, but how would I do this? I do not see how a user would have different authorizations when he connects directly or through the application... Can anybody enlighten me on this.
An extra question for bonus-points: Intergrated Security will not work on a Workgroup as far as I understand. How do people get FileStream to work in a Workgroup then? Or is this considered an impossibility?
Integrated security WILL work in a workgroup, using the legacy mechanism, where you have a matching username and password on the two machines. Also, a domain user can use the legacy mechanism to log into a non-domain server if the server has a matching user account.
Integrated security can even work with non-matching usernames and passwords. This may help you in your scenario.
Try this:
NET USE \\DBSERVER /USER:DOMAIN\USERNAME
You will be prompted for your password. This establishes a NetBIOS session with the database server. You should be able to see the shared folders and shared printers on the database server once you have done that.
Once a netbios session has been established between the client computer and the database server, you will THEN be able to use integrated security without being prompted for a password.
You may have to specify "named pipes" as the network protocol to usem, if it doesn't work with TCP (but I think it will). Named Pipes inherits your existing NetBIOS session, so provided you can list the shares you are probably good to go.
You can also establish the logon session using the windows API function NetUseAdd with USE_INFO_2 (level 2) information which incorporates the password.
I guess the short answer then is that you can have a special Windows logon for your application and have the users log in using that. However note that they cannot also be connected to the same server using their own username and password.
how do I limit the user access to the database I installed to the management studio for only certain people(probably me alone) to access?
But I got a surprise when I saw the database I installed to my client pc was able to be opened using window authentication. I thought it is only able to be opened by the new user I created for that database.
so how do I remove the database from being viewed by those login using window authentication.
In the SQL management studio go to "Security". Its quite possible that you will find some Windows accounts in there. This is normal behavior and they are put there on installment of the SQL instance.
What you can do is delete the ones you don't want poking around in the DB. Make sure that you at least keep 1 db administrator.
You can also restrict their access to read_only. Read this article on creating/editing users. Goto the properties of the user you want to edit and goto "Manage Server Roles". Learn more about server roles here
We have an application that uses Windows authentication to authenticate users with the database, and the SQL Server user accounts need to have certain read/write access to database tables.
The trouble is that the users can then install SQL Server Management Studio and potentially use the database in ways it's not supposed to be used, which isn't what I want.
Everything that I have read says that using integrated authentication is more secure but at the moment, any user can use Management Studio or Access/Excel to just connect to the database.
I have read question SQL Server Authentication or Integrated Security?, which suggests some workarounds, but I don't really have the option of changing the app as drastically as re-factoring all of the stored procedures etc. so I was hoping there might be another option?
Thank you,
NIco
Everything that I have read says that
using integrated authentication is
more secure
--> It's more secure in a way because it's more difficult to get the password.
If you use SQL Server authentication, the connection string contains user and password. If you know where the connection string is (often in a config file), you can open it and see user and password.
On the other hand, if you use Windows authentication, the connection string just says "Integrated Security=True" and you connect to the server with your Windows account, with the actual password buried somewhere deep in Windows' guts and more difficult to retrieve.
Of course, the big downside of Windows authentication is that if your users need write permissions on a certain table for your application, this means that they can write to the same table with ANY other application as well.
There are some workarounds, but none of them is THE silver bullet:
If your app only needs certain tables of the DB, you can just give permissions on these. So at least, the users can't do stuff in all the other tables
If the users are not allowed to access any tables at all from outside your application, there are unfortunately only two things you can do:
Change your app to SQL authentication and remove all permissions for Windows users
(you can also use a proxy service like Will Hughes suggested, but the effect is the same when the app accesses the DB directly...the point is that your users' Windows accounts don't have any permissions anymore!)
Create views and stored procedures (if they don't already exist anyway) for the stuff your app can do with the database. Give the users permissions to use these, and remove the permissions to the real tables.
--> the users can access the views and SPs directly with other tools (even if they don't have any permissions on the underlying tables...permissions on the views and SPs are enough), but they can't do anything that they can't do in your app as well.
If you don't want users to have access to your database, don't grant them access.
If you need to control what they can do - then you should do your access control in a webservice (or some other form of proxy service), which will then execute approved queries, return data, etc.