I'm looking at using SQL LocalDB as the client side database which will replace the current SQL CE 3.5 database inside an in-house application developed in .net 4.
I've come across a problem that I'm not sure how to get around and that's with security setup of the LocalDB instance.
If I setup a script inside .net to create a private LocalDB instance, e.g. (localdb)\T1, then create a new database inside that instance plus add a SQL user account + password (non domain account), how do I stop the local windows users (like my own AD account) with admin level privileges from accessing the 'T1' instance + database using SSMS?
I could see a scenario playing out where we deploy the application, then we have some IT savvy user who goes snooping around and decides to install SSMS and connect to (localdb)\T1 with their windows account, which would give him/her full access to the database, which is exactly what I'm trying to stop from happening.
Some of our staff work remotely with no connection to a domain so we give them local admin rights to their pc so they can install software, so even if I could block their assigned windows login name, there would be nothing stopping them from setting up a new local admin account and logging in with that, opening SSMS then accessing the database.
Any pointers on this would be greatly appreciated!
In fact, it shouldn't be so hard. Install SQL Server on client machine using local admin account. To make you life easier, use Mixed Authentication.
After you have your instance installed, local admin account should have sysadmin server role assigned (that's normal security settings). Now, use the following:
Create new SQL Server user and assign sysadmin server role to that account. Close SSMS and log-in using new credentials. Or simply use sa account (not so good practice but in this case it's OK).
Go to "Security - Logins" and remove sysadmin role from local admin. Also, check in user mappings and take all rights "away" from local admin.
As a test, try to log-in as local admin, I guess you won't be able to log-in into server because there is no "home" database for that user. But even if you can log-in, it has only "public" role.
It's up to you to install your database and secure it - assign permission to user of your choice.
Regarding you fear that local admin can install MSSQL again: he/she can install it, but it would be another instance. That instance knows nothing about users in your instance so you should be safe.
You can also consider usage of application roles in SQL server.
Related
I created SQL account for an application but how do I restrict or deny the same account not to connect the database using SSMS or Azure data studio by the developers since the developers can view the user information in web.config file.
Thanks,
Sandeep
You can use Azure Active Directory to authenticate your app, so that you don't need to write the username and password in config file.
With Azure AD authentication, you can centrally manage the identities of database users and other Microsoft services in one central location.
Benefits:
It provides an alternative to SQL Server authentication.
It helps stop the proliferation of user identities across servers.
It allows password rotation in a single place.
You can read more details from this document.
Basically the answer to your question is... You can't...
There is no way to identify the client of a certain connection in Azure SQL. What you can do, for example, is restrict access to a certain server using s firewall. But if your dev env is on the same machine as your SSMS that won't work because you're then blocking the dev env as well.
In that case, the best practice is to create a dev database to which all devs have access. In that case, it doesn't matter for you everyone knows the password because it's the dev database.
For production environments, you need to treat database credentials as secrets and thus make sure they are stored in a safe place. When you're using Azure, the KeyVault may be a good place to store the password. This KeyVault has a fine grained way of allowing access to secrets for individuals as well as IT systems.
I am trying to install DNN using Web Platform Installer. It tries to connect to .\SQLEXPRESS, which I have installed along with SQL Server, and wants me password for sa. When I provide it
with a password, it says "password invalid or cannot connect to database".
I thought to myself there might be a problem with the sa account. I opened SSMS 2012. There is a red arrow downward sign on the sa account. Whenever I am trying to change login status to Granted it opens up an error message:
error 15151
Cannot alter the login 'sa' because it does not exist or you don't have permission.
Nonetheless I tried it with administrator account and also by disabling UAC. None worked. Screen shot follows:
Details:
SQLEXPRESS version: 10.0.2531
SQL Server version: 11.0.2100
Update: Following some guidelines I tried to change authentication in SQL Server Management Studio from Windows Authentication to Mixed Authentication, but it failed with the following permission error:
Make sure you're connecting with a server login that has the sysadmin server-level role. You'll need that permissions level to do what you're trying.
Check the server authentication mode. If it is or was Windows Auth only, the sa account is automatically disabled. Note that if SQL Authentication was disabled and later turned back on, the sa account will still be disabled.
If you find that nobody is in the sysadmin server-level role, you'll need to stop the server and restart it in single-user mode so you can add at least one login to the sysadmin server-level role. In single-user mode, the Administrators group has sysadmin access, but you'll have a limited subset of commands to manipulate data in tables (single user is for fixing servers, not running applications). NB: Only one connection is allowed in this mode, so if you have a broker or service that's trying to connect you'll need to disable that or it can take the session you were planning to use with SSMS.
I've inherited a VB.Net Windows forms application that is used across several hundred remote sites. On the remote sites the application connects locally to a local SQL server instance using the currently logged in Windows user at the workstation - this all works fine.
The application however also needs to connect to a remote SQL server - currently this is done using a set of connection strings and sql authentication. The DBA wants to move away from using SQL server authentication and make everything Windows authentication.
Clearly, adding hundreds of users to the remote DB is not an option. Therefore I need to be able to use the currently logged in user if connecting locally to a local SQL server and a different Windows users (which will have permissions to the db server) if I am connecting remotely.
Does anyone have any suggestions of how this can be done or can suggest an approach.
Thanks
Since both servers are on the same domain, create Active Directory Groups for the application, put the users' Windows logins into the groups, and then give the 2, 3 or 10 or whatever app-specific AD groups permissions in the databases. If you're using stored procedures, create a database role for each AD group, grant the DB role execute permissions, and add the AD groups to the DB roles.
I brought my laptop home from work hoping I could get some tasks done over the weekend. Unfortunately, I couldn't login to SQL Server using Windows Authentication. I've checked the SQL Server Configuration Manager and the instance (MSSQLSERVER) is set to Log On As Local System, which supposedly means that I should be able to login fine using Windows Authentication... or am I missing something here? Note that in the login window, I tried a lot of different combinations and it always keeps telling me that connection failed because the server is not accessible or I'm not authorized to access it.
A little background about how the instance was installed: I installed and configured it myself. I chose the Mixed Authentication mode and gave a password to the default sa user (which isn't working either by the way). The thing I suspect could be the problem is the fact that I installed the SQL SERVER instance when I was logged in as my Domain User at work (DOMAIN\UserName). Now I'm at home and I do not have access to the LAN at the office, so I'm logged in as the {COMPUTERNAME}\Kassem user.
Any thoughts?
A windows account has to be added to SQL Server to have any rights. If you didn't add {COMPUTERNAME}\Kassem, you can't login to SQL Server.
The recovery option here is the SA password, which should always work.
To connect to the default instance, connect to localhost or .. Connecting to .\MSSQLSERVER won't work, even though MSSQLSERVER is the default instance name.
I have an application built in Access 2003 that uses a system DSN ODBC to connect to a SQL Server. The ODBC uses SQL authentication. When the application is started, the user is prompted to authenticate into the database.
I have another computer set up within the same domain that has Access 2007 installed on it. I log in using the same credentials that I use to get on the machine that has Access 2003.
I converted my application to Access 2007 format and everything works fine. However, when other users try to use the application, they are prompted to enter the database password every time a table is accessed. Thinking it was a problem with my ODBC, I confirmed that the connections were set up the same way on both of my machines, and the user's machine.
Here is the interesting part, when the user logged into my machine, it started prompting for the password every time. When I logged into the user's machine, the application worked fine.
Anyone have any ideas? All help is appreciated!
Be sure to use a System DSN, not a User DSN. It's easy to create the wrong one since the tabs are side by side.
Make sure that the System DSN has SQL Server authentication picked and you have the login id and password set.
A User DSN is only visible to the user that creates it. A System DSN is available to all users and Windows services.