I have a database Mydatabase with a view in it, MyView.
I want any user who is a member of the Public role to be able to select from the view.
I've done GRANT SELECT ON MyView TO [Public], created a test login on the sql server called Test and made it a member of the Public role, but still can't select the View.
What am I doing wrong?
USE MyDB
GO
CREATE USER Test FROM LOGIN Test
GO
GRANT CONNECT TO Test
GO
The login "Test" needs set up in the database as a "User".
By default, all users are a member of the database public role.
See Principals in BOL
If you want to give everyone or Public connect access to a database, go into the databases properties, goto the permissions page, add "guest" to the "users or roles" list, then select it, and in the lower half, find the "Connect" row, select "Grant", tuning it on, then click OK. This gives all Server Logins connect accss to that database.
A Login and a user are different in nature. A login is at the server level, and a user is at a database level. Every user has a corresponding login. At the same time, not every login has a corresponding user account.
Related
I have a huge problem with rights of new users of my SQL Server database. The new user cannot see any tables but is still able to drop them or create new tables.
Code to create the user:
--Code Start
--This is how I instantiate the new user:
CREATE LOGIN userName WITH PASSWORD 'password';
CREATE USER userName FOR LOGIN userName;
--Furthermore, the user get some roles. So that the user can do at least something:
CREATE ROLE roleExample;
GRANT DELETE, INSERT, SELECT, UPDATE ON dbo.exampleTable TO roleExample;
SP_ADDROLEMEMBER roleExample, userName;
--Code End
In my opinion, the new User should only be able to operate on the exampleTable now. But as I said, the user is also able to create and drop tables.
That's why, I added some constraints to the role, the new user gets:
DENY CREATE TABLE TO roleExample AS dbo;
This did not help either. The User is still able to create tables in dbo.
This problem is btw. not related to a specific schema. The new user can create and drop tables in any schema.
I guess that new users are allowed to create or drop tables by default. Sadly, I do not know how to change it.
I hope you guys can help me.
Attached is an example, where you can see that the user does not know the schema, where a new table should be created. Nevertheless, the schema exists and after executing this statement, the table is created. The error-message just says that this table is already created, because I executed this statement twice. Still, the user is not able to see its own created table in SQL Server Management Studio.
User does not know schema, but still can create tables in it
OK, so there's several things that it might be, but by far the most likely is that someone has granted some database permission(s) to the public role or to some AD group that your users are all in. (Also possible, but less likely is that something similar has been done to the server permissions).
To check for database permissions open SSMS (SQL Server Management Studio), right-click on your database in the Object Explorer pane and select "Properties". Then in the Database Properties window click the "Permissions" page from the list on the upper-left.
If there are any database permissions granted to any Users or Roles, they should appear in the upper listbox. If Public is in there click it to see if has been granted any database-wide permissions. All users have the Public role, so anything granted here is automatically granted to all users.
If that isn't it, then check any other roles listed in the upper listbox. Also check any users that look like they might be AD Groups because these work like DB roles except that SQL Server cannot administer them, nor tell who's in a specific group from these interfaces.
If you don't find anything here, then repeat this for the Server Permissions also.
Suppose I have a login metamanager\test which shows when I execute T-SQL, but it is not there when when I expand Security -> Login in SSMS.
Same with a database user.
I try to replicate but failed
use master
select * from sys.syslogins is used for login
use DB
select * from sys.sysusers is used for database user
A LOGIN and a USER are completely different objects.
A LOGIN is a server object, and appear in sys.syslogins, as you see.
A USER is a database object, and for a LOGIN to have access to a database, it needs to have a USER mapped to the LOGIN in that database. A LOGIN with no mapped logins in any databases, and without any server level roles, will be unable to access any of the database on the instance, apart from those that the public roles has in tempdb and master.
It appears, here, you need to create the user in the database, and then give it the appropriate permissions. You can create the USER with the following:
USE {YourDatabase};
GO
CREATE USER 'metamanager\test' FOR LOGIN 'metamanager\test';
You'll need to give it the appropriate permissions afterwards.
Also, after you have created the user, ensure you have refreshed your object explorer. Object explorer doesn't automatically refresh after you create an object.
Not sure if you explaining it correctly, but syslogins and server_principals are about the same. Only the difference that server_principals include "Roles".
As far as I know it is impossible to have something in syslogins, which does not exist in server_principals.
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 its possible to see 'sa' login in connection with login which have only granted to read some views? Probably cant to edit anything, but can see. And also can see list of databases, but cant to open. All in SQL Management Studio. Login just created by:
create login YourTpvLogin with password = 'enter new password here'
go
create user YourTpvUser for login YourTpvLogin
go
grant select on YourView to YourTpvUser
Thank you for explanation or way how to fix it.
Ok... First of all Every SQL Server login belongs to the public server role. Next - The public server role is granted VIEW ANY DATABASE permission which means that a login that is granted this permission can see metadata that describes all databases including master database which in turn records all the system-level information for a SQL Server system including information about SQl server logins and sa login of course is not an exception.
So... any new login can see all databases and logins but can't modify them.
Possible "solution" for hiding databases is to deny a login the VIEW ANY DATABASE permission.
To limit visibility to database metadata, deny a login the VIEW ANY
DATABASE permission. After this permission is denied, a login can see
only metadata for master, tempdb, and databases that the login owns.
And... you can't completely hide the sa login because every login must be able to read server's metadata from the master database.
I am trying to grant a domain user to SQL Server 2008. This user should be able to login to the DB using server management studio, and run PowerShell scripts doing SELECT queries to a database. My problem is my settings does not persist.
In server management studio, I right click on Security->Logins->right click on ->Properties->User mappings-> tick my database which happens to be the first one, granted 'db_datareader' and 'public'.
Click OK.
No error pops up.
But when I check the user mappings again, my database is no longer ticked! What have I missed? Really puzzled... must be something very simple...
--update--:
soved: deleted the login+user, added them back,and the rest.. now ok. many thx!
It happens sometimes when user has no connect permission or the permission has been revoked.
Grant connect to [user]
use master;
GO
create login [<domain\user>] from windows;
GO
use [<yourdb>];
GO
create user [<domain\user>] for login [<domain\user>];
GO
ALTER ROLE db_datareader ADD MEMBER [<domain\user>];
GO