Restrict database for only one user - sql-server

i dont know how to ask my question but still i try. I am using SQLServer2008R2. I have created one database say DB1 and also created one SQLServer user say User1. Now I want that only User1 can have access of DB1 database and other user can not access to DB1.

You should look at the security node in management studio for your database.
Check that your user is the only login that associated with your database.
If you want to prevent that user creating another user, revoke his permissions to create users.
For more information on users and roles, see the documentation http://msdn.microsoft.com/en-us/library/aa337552.aspx

Related

Azure SQL Database roles and access

What harm can a user with GRANT SELECT ON database.dbo.view TO User access can do? The user can see Security folder in SSMS, roles and can also see master database, roles, etc.? Is there a way we can restrict the user to not see or modify any security roles/groups but can see only a view?
Many Thanks!
In SSMS, a new user will not see the database tables/views without proper roles/permission provided to them but they can see the database objects like Security Users, schema or Roles etc., however they still cannot perform any actions on them if they don't have proper permissions granted to them. As an example if you created a new user and granted a select for a single view, that user will just be able to Select from the view and not able to do anything else on it like altering/deleting the view. Also same user can see the security objects but cannot make any changes on them as well.
We can hide the databases from user in SSMS by using below statement but this is going to hide all the database(even the database in which user has access to see the view).
DENY VIEW ANY DATABASE TO <login name>

Granting Full SQL Server Permissions for a Database

How can I give a user (who was created WITHOUT LOGIN) full control over a contained database without having to specify that database's name, like GRANT CONTROL ON DATABASE::DatabaseName TO UserName, but without using a database name? I figure it'll include GRANT ALTER ANY SCHEMA TO UserName, but I'm not sure what else I'd need to grant, or if there's a better way. Thanks.
If you literally want them to be able to do anything in that database, you can just add them to the db_owner role:
USE ContainedDatabase;
GO
ALTER ROLE db_owner ADD MEMBER [username];
If you want to be more granular, you can add them to lesser roles, like db_ddladmin, db_securityadmin, etc. You can see the list of built-in roles here:
Database-Level Roles
The permissions inherent in each of those roles:
Permissions of Fixed Database Roles
And if those don't suit, you can create your own roles, add your user to that role, and grant specific permissions to that role you created (and/or add them to other roles). The difference between applying the permissions to the role instead of directly to the user is simply reuse - if you add five more users that you want to apply the same permissions, you just add them to the custom role, rather than apply those granular permissions or roles to all 5 of the users.
Open SQL Server Management Studio and connect to your server.
In the Object Explorer, expand the "Security" folder under the server.
Right click on the "Logins" folder and choose "New Login..."
Add the users name in the format "Domain\UserName". You can also add domain groups by just changing it to "Domain\GroupName".
5.If you would like this user to have full access to the SQL Server instance, you can choose the "Server Roles" tab. Adding the role "sysadmin" will give them full access to the server to do actions like update the database, backup the database, delete the database.
Click ok and your user will be created and have access to your database.
Choose the "User Mapping" tab. In the top half of this screen, check the box next to the database name. Once you highlight the database and check the box to map the user to it, you can add role memberships to the user. For access to the database.
Click ok and your user will be created and have access to your database.

How can I grant only READ access to a Single table in Sql Server Database

I want to provide only READ access to a single table in SQL Server Database for a given user - xyz
Have gone through these questions:
How do I grant read access for a user to a database in SQL Server?
Granting a SQL Server Login Access to a Database - SQL Server
best way to grant read only access to 2 tables in SQL Server 2005?
But it raises some fundamental questions for me, what is the difference in giving the access through role and user name?
Kindly provide a efficient way to do this
I have gotten around this problem in this manner:
CREATE LOGIN XYZ
WITH PASSWORD = 'PASSWORD'
After the login for XYZ is created, then create a user for the above login created
CREATE USER xyz FOR LOGIN xyz
Then grant the select, update permission, in my case it is just select on a particular table
GRANT SELECT ON DBNAME.TABLE_NAME TO USERNAME
The sources I have referred for this are
http://technet.microsoft.com/en-us/library/aa337545.aspx (refer the bottom code part titled create a database user)
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/959f9307-0494-4883-9d17-fad684705864/grant-select-permission-on-a-table?forum=sqldatabaseengine
Granting access through user name is specific only for that user.
But granting access through role is applicable to all the users who belong to that role.
Role is used for assigning permissions to a group of users.

SQL server Login and User

I am confused with Login and User. I found following in articles :
A "Login" grants the principal entry into the SERVER.
A "User" grants a login entry into a single DATABASE.
One "Login" can be associated with many users (one per database).
I can understand it theoretically. But, I think I might not have understood this practically.
I created a Login in my SQL server 2008 management studio by right clicking SERVERNAME=>SECURITY=>LOGIN. The default database was "master". Now, I can log into sql server with this login name and password. I noticed that if I change the default database in Login properties to a specific database, I cannot login again with this credential. I reverted back to "master" and it works. What happened here?
Also, why do we need users? I created a user by right clicking DATABASENAME=>SECURITY=>USERS. I cannot relogin with this user credential. So, what is the purpose we need this for. I can understand the theory of this answer but I need little more explanations to make sense.
Also, I am a .net developer, so I would like to know, what are the credentials provided in sql connection strings. Are they login or user or can be any of these?
The simplest explanation is that the SQL Server login gets you into the server, and the settings on that login control how it works in each database.
Don't worry about the database logins for the moment. You already went to SERVERNAME=>SECURITY=>LOGIN. Let's look at what you do with this login - right click and go into properties if you already created the login. Look under Roles - there are a number of different ones with different purposes on the server. But for an app, generally speaking, the average user should only have the Public role.
As far as the Database login, you go to the Mapping section to point your login to whichever databases it needs access to. When you map the login to the database, this CREATES the database login you saw under DATABASENAME=>SECURITY=>USERS if it does not already exist. The mapping is the most important part though, it's what literally gives the login the ability to see data in the database.
For applications, you're using the server login. If you set up the links to the databases you need in mapping, you don't really need to think about the database level login info.
The login only exists at the server level, which is why it maps automatically to the master database.
Users control access to individual databases. When you create a user, you can map it to a login (see Create User on MSDN for the syntax). If you create a user mapped to the login in the database, you can set it as the default and log in.
One reason this is done is to allow multi-tenant environments where a single server hosts many databases that not everyone who can access the server should be able to access. For example, say we provide services to Company A and Company B, and we host the database for each on the same server. We don't want someone from Company A (or, more importantly, someone who has compromised the credentials of someone from Company A) to be able to access the data for Company B, so we only create a user for the Company A login in the Company A database. Here's a brief code setup for you to experiment with:
-- This script assumes whoever is running it has sysadmin permissions on the instance of
-- SQL Server on which it is running. Do not run this on a production instance.
-- Create a database for each company on the server instance.
create database CompanyA;
create database CompanyB;
go
-- Create a login for each company on the server instance.
-- SQL Server integrated security has it's issues, but it's useful for an example like this.
create login CompanyA_Login with password = 'pa55wOrd1', default_database = CompanyA;
create login CompanyB_Login with password = 'pa55wOrd2', default_database = CompanyB;
go
-- Create a user in the appropriate database for each login.
-- We need to tell the server that we want to use a specific database
use CompanyA;
create user CompanyA_User for login CompanyA_Login;
-- We're granting it dbo for the purposes of our example here;
-- a broad permission set like that is a bad practice.
alter role db_owner add member CompanyA_User;
go
-- Repeat the process...
use CompanyB;
create user CompanyB_User for login CompanyB_Login;
alter role db_owner add member CompanyB_User;
go
-- Create a table in each database and populate it with some data.
use CompanyA;
create table dbo.sensitiveInformation
(
sensitiveInformation NVARCHAR(50) NOT NULL
);
insert dbo.sensitiveInformation (sensitiveInformation)
values ('Oh man, it would be bad if this got out!');
go
use CompanyB;
create table dbo.sensitiveInformation
(
sensitiveInformation NVARCHAR(50) NOT NULL
);
insert dbo.sensitiveInformation (sensitiveInformation)
values ('Oh man, it would be even worse if THIS got out!');
go
-- Now, feel free to log in as either user and see what you can and can't do.
-- You will find that the CompanyA_Login will never be able to access CompanyB's
-- data and vice versa. This allows for secure multi-tenant environments.
-- Once you're done playing around, we'll clean up our samples.
use CompanyB;
drop table dbo.sensitiveInformation;
drop user CompanyB_User;
go
use CompanyA;
drop table dbo.sensitiveInformation;
drop user CompanyA_User;
go
use master;
drop login CompanyB_Login;
drop login CompanyA_Login;
drop database CompanyB;
drop database CompanyA;
If you need separate, discrete security/permission sets, and you need one user to have more than one of these sets, you want to use database roles. This article from Tech Republic gives a decent gloss of the benefits of roles, though I'd recommend checking MSDN for the most current ways of creating them.

Best way to create SQL user with read only permissions?

What is the best-practice to create a read-only user for a specific database?
I created a new user and granted the db_datareader role, however, this user still has access to the master db and other system databases. is that ok? or should i deny access on some system tables/databases as well to make it more secure?
Thanks.
Ok, so if i create a new user, will he have any more default permissions i have to deny?
if i do
~create login
~create user for login..
~grant EXECUTE for user
will the user only have EXECUTE permissions or will he have additional permissions as well for the active database?
Hi I believe the user can view other database in the object explorer too.
CREATE LOGIN me with password = 'me', check_policy = off
sp_changedbowner 'me'
GO
USE MASTER
GO
DENY VIEW ANY DATABASE TO me
GO
Well you can use denywrite as an role option. The user has to "see" the master, because the master contains the list of databases that he will enventually connect to, but he will only have guest privalages there. You can then deny access to other specific databases. AFAIK he does not need to see tempdb or msdb as its the SQL engine that accesses these

Resources