I'm using Redgate Source Control to changetrack a database. I have a testing database from which I commit, and a production database which is the final target.
I want to have a different Database Role (the setting found of Database->Security->Roles->Database Roles) in the production database because of specific requirements. I have changed one database on my production server, but every time I deploy to the production database, the Database Role resets to the status it was before I changed it (even though the specific role is not synced).
I found a filter on Comparison Options for user roles and checked the Ignore: "User's permissions and role memberships" and deployed the filter, but the Database role still resets every time I deploy any change to production.
Is there a way to ignore Database roles or is there a workaround I could use?
EDIT:
Larnu's answer is correct.
I had a separate issue here which had to do with the role permissions not being defined in the role, but in the schema.sql file. So I had to commit the whole schema to get the role permissions committed.
In SQL Source Control, there is an option for ignoring roles entirely (or using a rule to ignore certain ones).
Select your source controlled database in the Object Explorer, and then click SQL Source Control in your toolbar. Go to the Setup Page, and then select "Edit filter rules".
Then simply untick Role and the Roles won't be source controlled any more, or you can add rules to exclude/include roles that meet said rule(s). Note you may need to remove the Role details from your Source Control repository as well, as otherwise the position of the role when you stopped Source Controlling it may be used (I suggest checking).
Related
I am trying to use a DACPAC database project in Azure Data Studio.
So far, it works fine except for the "publishing" of the project to the actual DB.
When I generate the delta script, I see that all permissions on all schemas are being dropped.
I know that I could exclude certain objects:
SQL Server DACPAC Deployment Dropping Users/Roles/Permissions
However, I would prefer to have also the permissions of DB roles on a schema in the DB project.
Here, of course, the order is important. (Create schema, create user, create DB role, add user to DB role, grant permission for DB role on schema)
How (and to which file) can I add the schema permissions to the project and how can it be ensured that the TSQL statements that are generated are executed in the correct oder?
Thx.
At the linked QA have a look at the XML: there are separate parameters
DropPermissionsNotInSource
DropRoleMembersNotInSource
represented in sqlproj/publish.xml in a reversed way
<DoNotDropRoleMembership>True</DoNotDropRoleMembership>
<DoNotDropPermissions>True</DoNotDropPermissions>
By switching them to "do not drop" state you can avoid excluding permissions from deployment. Thus new permissions (defined in project but missing on target server) would be created but old ones (existing on target server but missing in the project) will not be dropped. Same goes for role membership.
Valid command order in publish script is guaranteed by the SSDT engine.
Still, permissions on target server can be lost if publishing requires object recreation. For example if you alter table-type then referencing procs will be dropped and recreated after type recreation.
I have a free trial account for Snowflake. I am trying to create storage integration. But after running the script I am getting below error :
SQL access control error: Insufficient privileges to operate on account ''
Even for the Account Admin role, above error is coming.
There are two places to set your role in the Snowflake original web UI (not Snowsight). You need to make sure you're changing to the ACCOUNTADMIN role for the right context:
If you're getting the error when running a SQL statement from the web UI, check your current role for the worksheet. You can click on the icon or role text to change it.
In this example, you can see that I've changed my role in the upper right to ACCOUNTADMIN, but that changes only my role for the button bar. I'm still using the SYSADMIN role when running SQL statements in a worksheet.
Also note that each worksheet has its own context, so changing worksheets could change your role if it's set differently on the worksheet you're opening.
In my case, I have faced this issue, but while using Terraform and specifying the provider configuration through environment variables. I was missing the SNOWFLAKE_ROLE to determine the role used while applying the Terraform configuration.
I ran into this error while running a deployment pipeline to an upper environment (code from DEV migrating to UAT). It's one of those weird situations where the logged-in user has to be able to perform multiple SQL actions which may require multiple role membership. In my case, I was running DDL 'Create' statements (as SYSTEMADMIN) and also needed to run some SQL commands which involved interacting with Snowflake Storage Integrations (which require the active role to be ACCOUNTADMIN).
USE SECONDARY ROLES ALL;
Use Secondary Roles -
https://docs.snowflake.com/en/sql-reference/sql/use-secondary-roles.html
Note that the set of roles is reevaluated when each SQL statement executes. If additional roles are granted to the user, and that user executes a new SQL statement, the newly granted roles are active secondary roles for the new SQL statement.
Including this at the top of each deployment script file removed the 'Insufficient Privileges' error and allowed successful execution of SQL scripts in my deployment pipeline.
I have been searching for articles and SQL script examples that would demonstrate how to securely and conveniently solve one of the most common scenarios - connecting from a .Net Core Entity Framework based web application to an SQL database.
But somehow I could not find any coherent step-by-step guide from a reputable source.
Let's assume the following:
I cannot use integrated Windows auth in the connection string and must use username and password based auth (because hosting on a Linux server and the DB is on a different Windows server)
the web service will need your usual minimum set of permissions - connect to the database, read data, write data, delete data, execute stored procedures
While reading many tutorials, I find there are multiple ways to manage the connection permissions. To avoid this question being too broad, I'll list my current choices as I understand them (please correct me if I'm missing something).
Users and logins:
create a login and a user for the database
create a database-only user without a login (not sure if this is applicable to a web app and connection string, but still it's a feature that I've seen being used)
Assigning permissions:
assign the user to some fixed SQL role (db_datareader, db_datawriter AND also will have to grant EXECUTE permission)
grant all fixed permissions
create a custom role (let's say, db_web_apps) with required permissions
Which choices are better (more secure and easier to manage in general) and recommended by SQL DBAs?
I think every database administrator should have a template script handy for quickly adding a new user with minimum required permissions every time when developers ask for a new connection for their shiny new web app.
If you know a good, reliable tutorial or GitHub / Gist example that explains what and why is being done that way or a script that you yourself have used for years without any issues in production environments, I'll really appreciate if you could share it.
Create a role in the database and assign the required privileges to the role. Don't use the fixed database roles. Instead grant permissions directly to objects, schemas, or the entire database if necessary. Like this:
create role trusted_app_role
grant select, insert, update, delete, execute
on schema::dbo to trusted_app_role
That will grant the role full DML permissions on all the objects in the default dbo schema. So if you have any tables or procedures you don't want the app to have access to, just create them in a different schema, say, admin. This way you never have to fiddle with permissions as you add objects. The fixed database roles predate schema-based permissions, and aren't really needed any more.
For your application's identity, add Active Directory or Azure Active Directory (Azure SQL) identities to this role, or, if you can't, add SQL Users to the role.
If you are on Azure SQL, you should normally use a database user without a login. On SQL Server you can only add "contained database users" if you enable Partial Database Containment. Which you can do, but is incompatible with Change Tracking and Change Data Capture, so it's a tradeoff.
So normally for SQL Server you still create a login and map the user to the login. EG:
create login web_service_user with password = '5X+jeuAB6kmhw85R/AxAg'
create user web_service_user for login web_service_user
And then add that user to your role
alter role trusted_app_role add member web_service_user
We use merge replication in one of our programs and I would like to allow our users to force synchronization of their laptops with the publisher on an as-needed basis (we are using push subscriptions). I got this working using REPLMERG.EXE (see my previous question).
However, when the users trid to run the script they received the following error message:
Only members of the sysadmin or db_owner roles can perform this operation.
...
exec sp_MSreplcheck_subscribe
...
If I add the users' group login as a db_owner on their local subscription database then the script works correctly. The problem is that they also end up with full access to every table in their local database, which is not something we can live with.
Allowing users in a merge replication topology to synchronize their local push subscriptions on-demand without giving them full-blown control of the db seems like a pretty straightforward use case, but I can't get it working.
From Replication Agent Security Model:
Merge Agent for a pull subscription
The Windows account under which the
agent runs is used when it makes
connections to the Subscriber. This
account must at minimum be a member of the db_owner fixed database role in
the subscription database.
The account that is used to connect to the Publisher and Distributor must:
Be a member of the PAL.
Be a login associated with a user in the publication database.
Be a login associated with a user in the distribution database. The
user can be the Guest user.
Have read permissions on the snapshot share.
Therefore is a documented requirement of Merge replication that the account running the replication agent (replmerge.exe) be member of db_owner. If you this does not work for you situation, then Merge replication is not the right technology to use, since it has a requirement you cannot fill.
Now int theory an application can do whatever REPLMERGE does from another application, and you can leverage the power of code signing to run a set of wrapper procedures that are granted dbo privileges via code signing, thus not needing the elevated login, but that's just theory since the replication procedures are not exactly easy to use nor are they documented at the level one needs to re-implement the agents...
The suscriber must have the right to replicate data definition instructions sent on the publisher. Some of these instructions might even lead to the reinitialisation of the subscriber, which requires the right to a drop\recreate the corresponding database. In these conditions, security requirements as set by Microsoft sound quite sensible.
As Remus and Philippe have pointed out, db_owner on the subscription db is a hard requirement for synchronizing a merge push subscription. However, we really wanted to allow our users to synchronize their own laptop without giving them full db_owner rights to the database.
Our solution was to enable mixed mode authentication on the subscribers and add a SQL Server user whose sole purpose was to enable our end users to synchronize their laptops. The SQL Server user, 'syncuser', was given the db_owner role on the local subscription database. Then, when we called replmerg.exe from within the program, we specified the following switches:
-SubscriberSecurityMode 0 -SubscriberLogin syncuser -SubscriberPassword 4w3$0m3_P4$$w0Rd
Here is the scenario. I have a SQL Server 2005 production database/server. It currently has developers and supporters who can connect to it. I need to create a security module that gives developers read-only access to all areas of the database. This means that a developer should be able to view all objects as well as scheduled activities/jobs only.
Is it possible to enable security in this way and if so can I be gently guided on how to achieve this. I am learning to be a DBA and creating snapshots of the databases are not an option.
Thank you all in advance.
There is permission to every object.
Create a stored procedure that grant each gruop the exact permission you need on the objects you need to protect.
I'm not quite sure I follow where this "security module" will be in the architecture. Anyhow, here's one possibility that secures it from the database end.
I'm going to assume you already have users created.
Create a new role (yourdb > security > roles > new database role), say "ReadOnlyDevelopers". Make the owner dbo or whatever makes sense. Do not select any schemas to be owned by the role. Populate the "Role Members" with your developers.
Next, open the properties page on your database. Go to the permissions page. Click Add... and add the new role. Under the permissions grid at the bottom, Grant SELECT to the role.
Now assuming your developers already belong to some other role, you'll need to go into the user properties and under Database Role Membership restrict them to just the new role. At this point they should be able to just read
I'm guessing that I'm missing a detail or two (the role may need to be grated a few additional rights to "see" the database, alter passwords, etc.) but I can't get to that level of detail without setting up the entire scenario. Hopefully this pushes you in the right direction.