Allow a server role to have database specific permissions in sql2016 - sql-server

Problem
We have a server with multiple databases and we would like a way of allowing a single group of users the ability to access or execute a restricted set of objects in each database on a single server.
Context
This used to be managed via AD groups however we are trying to move away from AD groups to using a mix of server and DB roles. However, I don't want to have to add or remove a user from a db_role in each database or have to try to keep them all in sync. Is there a way to tie database permissions to a server role so I only need to maintain the users in the server role?

Related

Access multiple database in Azure SQL

I have created 2 azure security groups (Read-SQL and the second is Write-SQL) in order for them to login into multiple Azure SQL servers via SSMS using their Azure AD identity based on their group membership in order to access multiple databases on those services.
First of all I have configured an admin group on the SQL Server in our Azure tenant.
I have connected to the SQL via SSMS using my credentials and so far so good.
After that I opened a query and typed in master database
CREATE USER [SQL-READ] FROM external provider
ALTER ROLE db_datareader ADD MEMBER [SQL-READ];
(Did the same thing for Write-SQL)
only the user is created and no permission given with an error saying the user does not exist or I don't have permission.
I have Azure global administrator permission in Azure and I don't know why I get this error.
In the bottom line I would like that Read-SQL and Write-SQL will be able to login in to the SQL Server and have access to all databases within it as well as giving Read-SQL reading permissions and to Write-SQL writing permission.
I read a few Microsoft articles but I got even more confused since I don't know if I need to create a login or create a user or a contained user.
Please help
Thank you
Here are few screenshots for better understanding
enter image description here
enter image description here
Read the following articles but only partial success.
https://www.mssqltips.com/sqlservertip/6751/azure-ad-authentication-azure-sql-databases/
https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure?view=azuresql&tabs=azure-powershell#create-contained-users-mapped-to-azure-ad-identities
https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-overview?view=azuresql
https://learn.microsoft.com/en-us/sql/relational-databases/security/contained-database-users-making-your-database-portable?view=sql-server-ver16
Whether you should create a login, user or contained user will depend on your access and security requirements. However, in Azure SQL Database, users are created per database. So, you can create the login in the master database and then you need to create the associated user in each database on that SQL Server.
This documentation gives more information on creating logins, users and contained users for Azure SQL Database.

Visual Basic App Connect to SQL Server as Computer User

I have made a Simple CRUD application made in VB with the data stored in SQL Server on my local machine.
Within the Database security I have made Database Roles and assigned permissions accordingly, and added my (Domain) Computer user account into the Role.
My connection string is;
Data Source=(LocalDB)\MSSQLLocalDB;Initial Catalog=Assets;Integrated Security=SSPI
Now when I run my application it assumes the dbo role instead of the user who is running the application. As this is intended to run on a central machine and have multiple users connecting to it, with different permissions, what changes do I need to make so that I connect using my domain user account?
When I run commands in SSMS with the EXECUTE AS USER command the permissions apply.
If you want users to connect via their Windows login, your connection string is fine. However, you need to recongifure your security model. Ideally, you'll want to create one Active Directory group per application role. Then, you'd add users' Windows accounts to the appropriate AD group. Now, on SQL Server, you'd add the AD groups to the appropriate database roles.
For example, you create a database role "db_read_only". You'd create an AD group "MyApp.ReadOnly", using your company's AD group naming convention of course. You'd then add MyApp.ReadOnly to your database's db_read_only DB role. Then, John Doe wants read-only access to your app, so he'd request to be added to AD group MyApp.ReadOnly.
Your app roles define how many AD groups and DB roles you'd need. You might have MyApp.Admin, MyApp.DataEntry, MyApp.Approver... whatever.

What are good practices for granting database permissions to a web service connection?

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

How to create a read-only server role on SQL Server 2012?

I am granting the "View any database" permission when creating a new server role, but realized this permission only allows the user to view the system databases.
I am trying to create a server role that is read-only and can read any database.
Is there a way to create a user-defined server role to read user databases? Or do I have to do this through user mapping per user?
So, no is the answer, you can't assign database level permissions to server level roles, you can't even add a server role to a database role, which I find really frustrating as I've tried to do the same thing as you.
The way I ended up doing this was not by using a server role at all, I did the following:
Created an AD group for each server that I wanted read only access for
Created a login on the server for the group
Assigned the login to the db_datareader role on the model database
Assigned the login to the db_datareader role on all the pre-existing databases
Added my windows users into the AD group
This way, you can simply assign (or train your servicedesk folks to assign) users who need read only access to all databases on a server to the AD group, plus, as the role is set in the model database, they will have access to all newly created databases on the server too.

Handle sql-server permissions gracefully with Navision

Background
I am in the process of creating an application (referred to as MyApp) which must read data out from a SQL Server database handled by Navision. Navision users should to be able to use my application, without modifying permissions in the database.
Navision's handling of permissions seems to be on the application layer. It performs the checking of permissions without storing them in the database.
Problem
Navision overwrites users, permissions, and other related objects in the database when synchronizing with the database, so the normal approach of creating a DB user and just using that won't work.
Possible Solution
What I think would be the most appropriate solution is to create a MyApp role in Active-Directory, which grants the necessary permissions on the DB, and add this role to all users.
I do not know how to do this, or even if it's possible. Other solutions, or proposals, are welcome, but please only suggest solutions with can be managed from within ActiveDirectory or Navision.
The server is an SQL Server 2008 server running Navison 5, and the client is Navision 6. I'm using Active Directory for Windows Server 2K8.
EDIT:
My app is a crate creating and designing application. It needs to read out the customers' names and IDs, and a few items in the items table, and that is why I need this functionality
If you use the enhanced security model in NAV, user permissions are synchronized to SQL Server. However, these SQL permissions are mapped to an app role in SQL Server, rather than the user's login. If you use the standard security model, all users map to a single SQL app role which is a super user (less secure).
If you want to access the data in SQL Server using the NAV security model (i.e. through the SQL App roles NAV creates), you should use the CFront API (installed via the SDK option). If you are using NAV 2009 web services are also an option.
If you want to access SQL Server directly, then you will have to manage the permissions yourself using SQL Server. If you create a SQL script to grant permission it is easy to restore anything which NAV might delete during Synchronize Logins.
You can't grant SQL permission from Active Directory exactly as you described. Instead you must map Active Directory groups to either SQL Server logins or NAV Windows Logins (depending on whether you decide to access SQL directly or go through a supported NAV API). Note: the permissions associated with the role are managed in SQL or NAV respectively; not in AD.
From an administration perspective, you can simply add and remove users from this Active Directory group. If you use the NAV enhanced security model each user in the AD group must also have an entry in Windows Logins, and whenever you make changes you must Synchronize Logins. This slight inconvenience is a hangover from the native database.
In general, skipping the NAV layer and reading/writing directly to the DB is not recommended at all as you're bypassing all of NAVs business logic which is stored in the table and report objects in NAV.
What does your app intend to do (broad strokes if you can't get specific) and would using a NAV add-in or dataport be feasible?

Resources