Problem restoring a SQL Server backup - sql-server

I have a SQL Server 2008, which is part of a domain. Now I make a backup of a database of this server and restore it on a SQL Server, which is not part of a domain.
I have an C# application, which uses this database. On the NON-Domain machine I get now exceptions like this:
"Cannot execute as the database prinzipal because the principial "dbo" does not exist, this type of principal cannot be impersonatedm or you don not have the permission"
I think, the problem is, that the database owner is a domain user and this user doesn't exist on the target machine (backup machine)!? How can I solve this ?

The MS SQL server follows a 2 layer user system.
You must make sure that your login is an actual login on the SQL Server (this refers to the SQL Server itself NOT to the actual database).
You find the SQL Server users in the Management Studio under:
Server root -> Security - Logins
After you ensured that your login is available you have to map it to a user/schema. In Order todo so you must:
Select the SQL Server user you want to map
Right click on the user
Select properties
Switch to the User Mapping tab
Choose the database you want to create a mapping for
Select the Database user you want to associate the currently selected SQL Server user with
Done

Related

Unable to access an SQL Server database created via Plesk in SQL Server 2014 Management Studio

In Plesk v12.5.30, I have created a new SQL Server database named ngo_database and a new database user called ngo_databaseuser.
I can connect to this new database via Navicat for SQL Server v12.1.20 (after providing host “xxx” + user name “ngo_databaseuser” + password + initial database “ngo_database”), And I am able to access “ngo_database” database and create new tables and queries.
But when I try to connect via SSMS 2014 (after providing server name “xxx” + login “ngo_databaseuser” + password + connect to database “ngo_database”), I am not able to access “ngo_database” database and the only databases available are master + tempdb. And I am not able to import nor create a new user database.
BTW, I have checked with the hosting company and the “Grant the ALTER DATABASE permission to all Microsoft SQL Server database users” is checked.
What I am doing wrong and why I can’t access the database via SSMS?
Not being a see a database in the object explorer of SSMS does not equate to not being able to access it. When you can only see the databases master and tempdb this very likely means that either you have had a DENY permission for VIEW ANY DATABASE added to your login, or a Server Role it belongs to, or VIEW ANY DATABASE has been revoked from the public role and you haven't been granted it.
SSMS builds the list in the object explorer by using the sys objects, and without VIEW ANY DATABASE, it can't see the databases you have access to to retrieve the relevant objects from it.
You can check if you have access to the database by using USE {Your Database} or trying to query a table (such as SELECT * FROM {Your Database}.sys.objects;).
If you need the VIEW ANY DATABASE permission, you need to speak to your DBA.

SQL Server 2008 R2 : restrict server login from seeing all but 2 databases on server

On my server that is hosting SQL Server 2008 R2, I open SSMS and under Security -> Logins there is a login named "SomeLoginName". When I log in to the server with this login, I am able to see all of the databases on the server.
I would like to restrict this user to only see 2 of the databases that are on the server. I've seen some solutions that say to revoke the VIEW ANY DATABASE permission for the login and then add the login as the db_owner for the databases I want "SomeLoginName" to be able to see. I don't want to have "SomeLoginName" as the db_owner for the databases that it is supposed to see.
Is there a way that I can configure "SomeLoginName" to only see 2 databases on the server without "SomeLoginName" being the db_owner for these 2 databases?
Thanks in advance.
Is there a way that I can configure "SomeLoginName" to only see 2
databases on the server without "SomeLoginName" being the db_owner for
these 2 databases?
No, as you are on SQL Server 2008 R2 there s no such a way.
Starting with SQL Server 2012 new Contained Databases were introduced.
Here is another useful article SQL Server 2012 Contained Database Feature
While looking through the new features and improvements in SQL Server
2012, we found a potentially interesting feature called Contained
Databases. A contained database basically includes all database
settings and the metadata within itself thereby resulting in no
configuration dependencies on the instance of the SQL Server Database
Engine where the database is actually installed. Users will be able to
connect to a contained database without authenticating a login at the
Database Engine level. This feature really helps to isolate the
database from the Database Engine thereby making it possible to easily
move the database from one instance of SQL Server to another. In this
tip we will take a look at how to configure and use this feature of
SQL Server 2012.
When using contained databases you don't need login (security principal at the server level), only user at the database level. It will be a database, not a server, to authenticate your user. And as the consequence, this user will not "see databases" other than the database where it was created.
This user has not to be db_owner, it's an ordinary user with any permissions or even without any permission at all.
Thanks to #sepupic , his/her answer is correct. It turns out that I actually am running MS SQL Server 2012 so I was able to implement the Contained Database concept. The steps listed on the linked pages in #sepupic 's answer didn't work for me though. I found this one and put this script together. Here's what it does:
Changes the 'contained database authentication' to 1 for the MS SQL Server instance
Runs RECONFIGURE
Creates a contained database
Creates a user for the database
Here's the script:
USE master;
GO;
EXEC sp_configure 'contained database authentication', 1;
GO;
RECONFIGURE;
GO;
CREATE DATABASE ContainedDB2
CONTAINMENT = PARTIAL;
GO;
USE ContainedDB2;
GO;
CREATE USER cduser2
WITH PASSWORD = N'Pa$$word',
DEFAULT_SCHEMA = dbo;
GO;
Then you just configure the connection to the contained database in the section that begins with
Login and Verify the User Permissions on a Contained Database
Using the script I put together and configuring the connection under the section I mentioned sets it up so you connect to the server with the user that is created and that user can only see the contained database(s) you want it to. You have to configure the user to have permissions like the db role db_datareader in the contained database but instructions on how to do these types of things are easy to come by if you search for them. Thanks again to #sepupic for getting me started on coming up with an answer.

SQL Server Restrict Access to Database by Windows Authentication Mode

I am facing problem regarding database permissions. I have created my database named FCProject. I created a login for that database in SQL Server Management Studio. My login is working fine but all I want to restrict access to FCProject database through users who can log in to SQL Server through Windows authentication mode.
Because I want only FC login to be able to view or modify data of FC database in SQL Server Management Studio.
I have tried creating a login through Management Studio. Is there any problem in creating login? Or something else? Please help
You are mixing up two things that should be kept separate here:
A login is on the server level - it gives an account (a Windows account, or a SQL Server specific account) the permission to connect to this server
Each database can then define user for its own use - based on those logins.
So in your case, what you need to do is to:
create a number of logins on the server-level
create users in your FCLogin database for just those logins
and then you're fine - only those accounts that you've defined explicitly can access your FCLogin database and use it.
See the Stairway to SQL Server security series of articles on SQL Server Central (very well worth registering for their contents!) which explains all the ins and outs in great detail

How can I manage Azure SQL user/login/credentials

I read this article: https://msdn.microsoft.com/en-us/library/azure/ee336235.aspx
I don't know how to connect to the master database. I don't see it anywhere on the portals.
I want to be able to manage which credentials have access to which db and at which level. Preferably using a GUI.
There are a couple of ways to manage credentials in Azure SQL DB.
The simplest is to use the GUI in the NEW azure portal (https://portal.azure.com/) -- open the SQL Database server of interest and manage access using the "Roles" and "Users" options in the "Access" group at the bottom of your Server pane.
You can also connect to the Server using Visual Studio (SQL Server Data Tools add-in). Open Visual Studio and under VIEW, select SQL Server Object Explorer. You can add the Azure DB server to that tree, you will have an option of connecting to the "Master" database (under System Databases) and running SQL commands to create users, or graphically add new users under Master > Security > Users. Once the user is created, logins can be created and then individual database permissions added.

Limited permissions for a SQL Server user

I have a .NET application which connects to SQL Server 2008 for storing some data. I use SQL Server authenthication providing an sq username and a password to my end-user in app.config file. If something more needs to be changed I give to the end-user some other credentials.
How can I limit the sql user to only have permission to read/write data and executing existing stored procedures and everything else to be forbidden?
What is the best practice for setting permisions for a sql user that an application is using to connect to a database? Can I prevent somehow the user from logging in Management Studio and mess with my data?
I'm not searching for the perfect 100% reliable solution, but the best existing practice to do this. Thank you very much in advance.
Update: I work on a shared hosting SQL Server environment.
You'll need to create a new SQL user, something like 'LimitedUser'. To do this in SSMS, select the Security Folder of the server you are using, right-click, select New, select Login.
Select your authentication type (SQL server authentication is easily managed), and set the Default database to your database.
You'll need to set Server Roles so this new user only maps to your DB, and in the last page (Status), set Login to false so they cannot use these credentials to login to SSMS and 'mess with your data'.
Click OK, and you're done creating your limited user.
Assign it to your database, and then in SSMS, right-click on your db, select Properties, Permissions.
Select your user or role, and in the permission grid below, switch on only what need to be switched on.
As I see, your question is fully concerned with SQL server security.
You can limit user permissions on server, database or object scope, using GRANT statement, server or database roles. For example, you can assign db_datareader role for user, and then grant EXECUTE permission to this user for some stored procedures (or for entire database).
The current practice in my organization is to create the database roles (e.g. application admin, operator, and so on), adding the appropriate permissions to these roles and then assign these roles to database users.
I'm not completelly sure that you can prevent login into SQL Server Managent studio (SSMS), but SSMS wll not display information that must be invisible for user with user current permissions.
Shared SQL Server hosting where a single instance is shared among multiple customers is not compatible with with typical client-server applications. You are expected to perform all operations through a middle tier server such a WCF Data Service and maintain user accounts within your database in a table with Forms Authentication etc.
For your client-server application you need VPS hosting with your own instance of SQL server where you can create server-level logins. Without creating server-level logins there is no method to secure a client-server application. Any workarounds are just pseudo-security.

Resources