Goal:
Assign appropriate Azure SQL database privileges to App Service Web Site's system service principal (or better yet) the user assigned service principal.
Background:
After having followed along with Alexandre's tutorial on creating Azure SQL administrators I created a simple Blazor Server App that can insert entries into a simple Azure SQL resident table because the system assigned service principal of the Azure App Service Web site is an administrator for the Azure SQL database.
Problem:
Database administrator privileges are not appropriate or necessary for the Azure App Service Web site. I need to endow the Azure App Service Web site with minimal privileges (such as db_datawriter) to be consistent with Microsoft's recommend best practices.
What is Working (Updated):
I've been following along with Jesse's tutorial where he endows his account as the Azure SQL administrator and creates new accounts with limited roles like db_datareader and dt_datawriter and db_ddladmin. This was not working previously (when I first posted).
Tue May 24 2022 Update:
I started over again (with a new azure SQL database) following Jesse's tutorial and I can now
log into the Query Explorer
create a user
grant access to that user to update, select and insert into a table
Connect with SSMS with no password and access the database tables as that user
Run my blazor app and insert into the table as well (with no password!)
New Questions (Tue May 24 2022):
When I deploy my blazor app to Azure AppService Web app, it cannot connect.
How do I write bicep code to grant my azure app service resident blazor app access to my azure SQL database? I think I need to use the system assigned service principal for the web app (does this have a password?) and use SQLCMD.EXE to execute those CREATE USER and ALTER ROLE commands. How do I do that? The problem is that the system assigned service principal of the web app is not an active directory object. Conversely, "az ad user show" does not have a principalId I can use as a user assigned service principal that I could assign to the web app.
So when I am running on my desktop dev machine, DefaultAzureCredential is detecting that I am logged to Azure with the Microsoft account and I can debug my blazor app on my dev machine...
How do I configure Azure SQL to allow access from the Azure App Service web app as well as access from my desktop dev machine? This is easy to do with cosmos SQL and I'm thinking it should be possible with Azure SQL as well.
Thanks
Siegfried
This article I recently published should be able to help you: https://dev.to/azure/create-and-connect-to-an-azure-sql-db-9k0. And yes, this sentences you mentioned "it looks like this is the way to conform to the Microsoft recommend Best Practices of abandoning passwords in favor of service principals and managed identities", is definitely correct.
Related
I've got an Azure App Service that needs access to a classic SQL Server (non-Azure SQL, not SQL Managed Instance) and I'd prefer to do this via System Managed Identity. This is enabled on the App Service and a corresponding Enterprise Application is created on Azure AD.
The SQL Server is also connected to this Azure AD and User accounts on the AD already have access to the database. However I can't find how to create a login for the Enterprise Application. If this was an Azure SQL database I could do it with CREATE LOGIN [AZUREAD\app] FROM EXTERNAL PROVIDER but this does not work on a classic SQL Server, only on Azure SQL/MI.
A solution would be to use SQL accounts and reference the login/password in the connection strings, but as mentioned I'd much rather use Azure AD for authentication.
To answer my own question: SQL Server 2022 includes Azure AD authentication Link
Using integrated security or an access token it will be possible to authenticate with an App Registration.
This is currently in preview with no RTM date specified.
We are using the ADFS activity report to migrate our applications to AAD. Everything shows as Ready and when we click on the Ready link, the text says "We've detected on-premises settings for this relying party that can be migrated to a new Azure AD enterprise application. We'll map the fields and create the new application, but users won't be redirected to it until you say so." By the last statement, it seems like the application is automatically created now. Is that the case? If so, how long does it take to create the application and does it keep the same name as in ADFS?
• The message that you encountered “We've detected on-premises settings for this relying party that can be migrated to a new Azure AD enterprise application. We'll map the fields and create the new application, but users won't be redirected to it until you say so.” Means that the application is a SaaS application available in Enterprise application gallery in Azure AD. This does not in anyway mean that the application has been created automatically, it just means that the application is ready to be migrated to Azure AD and is fully available as a SaaS application in Azure AD gallery and doesn’t need any further relying party configuration migration from the on-premises ADFS server.
• Since the message is displayed only for SaaS apps readily available in Azure AD gallery and are equally configured as a relying party trust in ADFS, its configuration information is readily migrated through the ADFS Connect health application to Azure AD and it can be configured in the cloud itself with admin account access needed for the SaaS application’s account for SSO and SAML authentication configuration required through Azure AD.
You can find the image below for your reference, it shows the ‘Dropbox’ application as ready for migration from ADFS to Azure AD: -
Through the above option enabled, you can easily configure your application’s SSO configuration in Azure AD. If all the configurations are up and running, it will happen instantaneously within a few minutes of time.
Kindly refer to this link for more information on migrating federated apps from ADFS to Azure AD: -
https://github.com/AzureAD/Deployment-Plans/tree/master/ADFS%20to%20AzureAD%20App%20Migration
I think the report is still in preview and it is missing a create application button.
All the documentation only shows the reports & not the create process.
Also this migration tool, is a repackage of the powershell test commands:
https://github.com/AzureAD/Deployment-Plans/tree/master/ADFS%20to%20AzureAD%20App%20Migration
So I assume you need to create the application manually based on the report.
I am required to migrate an on-prem ASP.Net web application with its SQL Server 2019 backend to Azure.
The Web application initial migration must be IaaS (Windows VMs running IIS).
The SQL 2019 has to be Azure SQL PaaS (Not Azure SQL Managed instance).
The existing on-prem Web application has several virtual directories, and each application in a virtual directory, is in a separate IIS app pool.
Each app pool is run under the context of a different domain service account.
Connection to the SQL databases is via integrated security.
In the current on-prem solution, the domain service accounts are added as logins to the SQL Server and each has permissions to one or more of the databases (Execute / Connect permissions; addition to datareader role etc).
I believe there will have a domain join to Azure AD, so the on-prem AD service accounts will be accessible in azure (as far as I can understand).
SQL Azure does not support CREATE LOGIN [MYDOMAIN\MYSVCACCOUNT] FROM WINDOWS;
Is there a way I can setup the existing on-prem domain accounts with the access, permissions and roles in the SQL PaaS solution, to mirror the current on-prem setup?
Alternatively, could someone could help me identify resources for best practice for the architecture described.
Thank you
I found a a few good posts that assisted me to understand all available options:
https://www.mssqltips.com/sqlservertip/5242/adding-users-to-azure-sql-databases/
https://learn.microsoft.com/en-gb/azure/azure-sql/database/logins-create-manage
How can I limit the permissions of an Azure SQL database when accessed from an Azure web app?
Details - I am working with an Azure SQL database and creating an ASP.NET Core web app. In the web app I have put a connection string that points to the Azure SQL database. The connection string includes the server admin username and password of the Azure SQL server. The web app successfully communicates with the database and can read and write data. Now, as a safety precaution, I would like to prevent the web app from ever deleting a database table (whether this be due to a mistake in the code, or a malicious SQL injection performed on the web app). How can I set permissions on the Azure SQL database to disallow table deletions from the web app?
I have heard of Azure Active Directory; I have never used it but I gather that it is an approach to manage identities and permissions of database users. Is there something similar to manage the permission of a web app rather than a user. Or is it possible to treat the web app as a user and assign user permissions/roles to it? If so, what would be the correct approach to implement this?
(Also, while we are on the subject, aside from preventing table deletions are there some other CRUD operations that you would recommend preventing from a security perspective as a best practice?)
As Dbro said, we suggest you create a new login and user to limit the permissions of an Azure SQL database when accessed from an Azure web app.
Replace the app connection string with the new Non-administrator username and password.
And we all know, no matter which way we access or connect to the Azure SQL database, we must through the SQL account, Server administrator or new Non-administrator.
Different Azure SQL account has different permission on database operation CURD.
Fore more details, please reference Azure document Controlling and granting database access to SQL Database and SQL Data Warehouse.
When a new user you created, you can decided which database permissions to grant for the user. Please see: GRANT Database Permissions (Transact-SQL)
For security, Azure also provides the Azure Key Vault for you. To see: Always Encrypted: Protect sensitive data and store encryption keys in Azure Key Vault:
Summary:
Always Encrypted is a new data encryption technology in Azure SQL Database and SQL Server that helps protect sensitive data at rest on the server, during movement between client and server, and while the data is in use. Always Encrypted ensures that sensitive data never appears as plaintext inside the database system. After you configure data encryption, only client applications or app servers that have access to the keys can access plaintext data.
Hope this helps.
Is there something similar to manage the permission of a web app rather than a user.
Yes. It's called Managed Identities. Azure will provision an identity in your Azure Active Directory, and ensure that only code running in your Application can generate tokens for that identity. This gives you the ability to authenticate and connect to SQL Server (and other Azure Resources) without having a username/password or a client secret in your code or configuration.
See:
Azure AD managed identities for Azure resources
Managed identities for Azure resources provides Azure services with an
automatically managed identity in Azure Active Directory (Azure AD).
You can use this identity to authenticate to any service that supports
Azure AD authentication without having any credentials in your code.
Learn how to create and manage managed identities for Azure resources
with our quickstarts and tutorials.
And: Tutorial: Secure Azure SQL Database connection from App Service using a managed identity
are there some other CRUD operations that you would recommend preventing from a security perspective as a best practice
You should create a database role that has the minimal permissions required to run the application, and add your application user(s) to that role. The permissions needed will, of course, depend on what your application does, but the role might look something like this:
create role ApplicationUser
grant select,insert,update,delete,execute on schema::dbo to ApplicationUser
deny delete on AuditLog to ApplicationUser
(In SQL Server a DENY overrides any GRANTs and so you can grant permissions at the schema-level, and selectively DENY permissions at the object level)
I need to connect my web app on Azure to our on site SQL Server instance via Windows authentication (not via SQL Server account authentication). Active Directory is already integrated with the on-site AD and therefore all of the users are available there.
My question is, is it possible to hook up an azure web app to an on-site SQL Server via Windows authentication.
is it possible to hook up an azure web app to an on-site SQL Server via Windows authentication.
Base on my option, it maybe that we couldn’t do that. As we have been limited to do that operation for azure WebApp. There is also another SO thread mentioned that.
If we want to connect to on premise SQL Server, we can use hybrid connections to access on-premises SQL server database in Azure WebApp, more info please refer to the document.
If we want to authenticate the WebApp with local Active Directory, and we have an on-premises secure token service (STS) like Active Directory Federation Services (AD FS), we could use that to federate authentication for our Azure WebApp. More info please refer to the document.
Hybrid connections at this time does not support AD accounts due to
because you cannot domain join an App Service worker