I just created a new web application that accepts some form based input from the user and inserts it in into the database. To go along with this I created a new user in the database and initially assigned the user to two roles and schemas ...
db_datareader
db_datawriter
After thinking things over I realized the user did not need to be part of the db_datareader role because the user only inserted data into the database and never read any. So I went back and removed the role of db_datareader and noticed that the schema options were grayed out. I could not remove the user from schema ownership of db_datareader.
How does one go about removing a user from ownership of a specific schema? Should I have even assigned schema ownership in the first place?
I am logged in as administrator of the SQL Server and of the Windows 7 OS.
I had same issue today and found a way to remove user as owner of schema. Open Schema node below Security in database and change the owner for the user that you mistakenly used with the default owner. For example if some oddball user name is listed as schema owner for db_datareader, change it to dbo (the default) and so on.
No, you shouldn't have assigned ownership of the schema to the user. You should have just made the user a member of the schema. Revert ownership to dbo and check that the user account is not still a member of the schema.
Related
Does the SYSADMIN role have the ability to access and change data in a database. For example can this role directly access the file and change a record from $1 to $10,000? Or could it create or escalate the permissions of a database user to then modify the amount? I am asking because I am trying to assess risk for a SOX significant system where there is a security issue with an account with that role but which only has the db_datareader role. Thank you in advance.
Does the SYSADMIN role have the ability to access and change data in a database.
A member of the sysadmin fixed server role has full control over the instance, and is exempt from all permissions checking. Also a sysadmin will always connect to user databases as dbo, who has full control over the database and is exempt from all database permissions checking.
The only way to protect data from a sysadmin is with AlwaysEncrypted which encrypts the data in one or more columns with a client-provided key.
I really need some advice about adding roles at the server level and apply some permissions that will be applicable to each database on my server.
Basically I need to two roles read only and read write.
The read will have permissions to select and see any object
The write will have permissions to select/insert/delete and execute any object
I want to create a server role, then a login associated to this role (which can be a AD group) and after that for each database create a user that will inherits all permissions from the server role.
So on each database, I will have each user that belongs to the server role created, the problem is to clearly define the permissions, is not straight forward in my opinion.
What I can see, I cannot assign read or write to a role and then use it on each db, on the contrary on the General tab of the server role I have a bunch of permissions that is not clear which one to use for this purpose.
Maybe I'm doing it wrong but I want to have something at the server level and not define the same role on each db for that purpose. I'm using SQL server 2014.
The short answer is you can't.
Generally, server-level permissions are not propagated down to individual objects within databases. The only exception is a sysadmin role, which I would strongly encourage you not to use for this purpose, as you would essentially give up the control of the entire server instance to every member of it.
As a kind of a shorthand, you can use built-in database roles to save yourself a bit of trouble. For read-only access, a membership in db_datareader role is usually enough, unless you have stored procedures that return datasets which this role is supposed to be able to execute. There is also a similar role for modification, db_datawriter, but it doesn't cover the execute permission. So you will have to create a custom role for that:
create role [DataChanger] authorization [dbo];
go
alter role [db_datareader] add member [DataChanger];
go
alter role [db_datawriter] add member [DataChanger];
go
grant execute to [DataChanger];
go
-- Now you can add your members. Here is a reader
create user [Domain\MyUser1] from login [Domain\MyUser1];
go
alter role [db_datareader] add member [Domain\MyUser1];
go
-- Writer
create user [Domain\MyUser2] from login [Domain\MyUser2];
go
alter role [DataChanger] add member [Domain\MyUser2];
go
These permissions will automatically pick up newly created objects, without you having to explicitly add new permissions after every schema modification.
You will have to do this in the context of every user database that you want to manage in this way. You can probably create a SQL Agent job which will run periodically and introduce these changes in any user databases which don't have them already (for example, if a database has been restored from earlier backup, or brought from another server, or a new one was created). Also, since you can't loop through databases in static code, you will need to wrap it into a dynamic SQL and loop through sys.databases, or maybe via an undocumented sp_MSforeachdb system stored procedure. Oh, and don't forget to remove all these go statements from dynamic code, as they are not part of SQL, and are only recognised by SSMS and sqlcmd.
P.S. All that being said, I hope you are not going to manage any production databases in this manner. I don't even know where to start on how insecure this approach is.
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.
I accidentally changed the DB owner to SA. Is there logging that would show what the previous DB owner was?
Thanks.
The database owner is stored in the master database (sysdatabases or sys.databases table; please always mention your version of SQL Server). So you could restore a backup of the master database to a new instance of SQL Server, query the old owner and set it back on your production instance.
It would also be interesting to know why the database owner is important to you. In most environments I've seen, all databases are owned by sa and users who need database owner permissions are added to the db_owner role explicitly. This is a better way to handle permissions, because only one login can be the database owner, but multiple users can have database owner permissions. Therefore, using the db_owner role is more flexible.
Using SQL Server (2008), is it possible to grant a specific user full control of the objects under a specific schema? This includes create/drop/alert table. Its important that this user isn't not given db_ddladmin role because that would give him access to other tables.
You can create a role in the database, assign all appropriate permissions(SELECT, UPDATE, DELETE, EXECUTE, etc.) to the role, and then assign the user to that role.