Azure App Services trusted connection to SQL Azure - azure

I have a web application hosted in Azure App Services (allowing anonymous access) that I need to connect to a SQL Azure DB through a TRUSTED CONNECTION. My business will not allow me to store a password in the web.config (hence the "trusted connection" requirement). Can someone please point me in the right direction?
UPDATE:
We are using Azure AD. I have looked into running the app under an AD account (can't figure out how to do this). I have also tried to find what account the app is running under so I can add that to the DB (can't figure this out either)

Active Directory IS the answer you're looking for- you'll want to do Token Authentication.
The short explanation is that your application needs to be registered with Azure Active Directory (AAD), and that you need to create a SQL login for the application that maps to the AAD principal; the application using the token (certificate) is able to authenticate as the AAD principal and will be able to connect to the database.
We created a tutorial that covers the ability to connect without putting a password in your config- you'll need to use a certificate. This demo covers how to do it with a self-signed/self-created cert.

Related

Error when trying to consent Azure VPN application

I am trying to setup a p2s VPN using Azure Active Directory authentication. I am following the steps described here https://learn.microsoft.com/en-us/azure/vpn-gateway/openvpn-azure-ad-tenant. In the section Authorize the application, it's mentioned that we need to grant admin consent, so that Azure VPN application can sign in and read user profiles. I am logged in as GlobalAdmin, but when I paste the required URL (https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent) I am redirected to the portal with url:
https://portal.azure.com/?error=access_denied&error_description=AADSTS650054:+The+application+'api://41b23e61-6c1e-4545-b367-cd054e0ed4b4/api'+asked+for+permissions+to+access+a+resource+that+has+been+removed+or+is+no+longer+available.+Contact+the+app+vendor.
What am I doing incorrectly ?
The above behavior was a code bug which was fixed by the Azure VPN and Azure AD Product Groups team and below is the RCA (Root Cause Analysis) for same:
Issue: When setting up a P2S VPN using Azure Active Directory authentication following the steps described in our public doc tutorial and trying to grant admin consent to the Azure VPN application using GlobalAdmin account, the public URL redirects to "https://portal.azure.com/?error=access_denied&error_description=AADSTS650054:+The+application+'api://41b23e61-6c1e-4545-b367-cd054e0ed4b4/api'+asked+for+permissions+to+access+a+resource+that+has+been+removed+or+is+no+longer+available.+Contact+the+app+vendor" and doesn't give the prompt to accept the requested permissions.
Root Cause:
Admin Consent was failing for new customers as Azure VPN was trying to get access to Azure AD Graph and this is deprecated.
Refer : https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-configure-permissions?tabs=http%2Cupdatepermissions-azureadgraph-powershell
This impacted only new Tenants who want to onboard to VPN and not existing customers. Some code was updated in the backend which broke the admin consent flow. The app access has been changed to Microsoft Graph now and the newly added code was removed from the Azure VPN client app from the backend which has fixed the issue.
Solution:
Now if you follow the documentation/guide Configure Azure AD tenant and settings for P2S VPN connections: Azure AD authentication: OpenVPN - Azure VPN Gateway | Microsoft Learn, the public URL at Step 2 should work without any issues.

Trusted Connection to SQL Managed Instance from Azure Active Directory Domain Services

When connecting a .net application to a local database we have always used a trusted connection connection string.
We are porting our platform over to Azure with:
Apps on Virtual Machines
Azure Domain Services
Sql Managed Instance
We have multiple Apps each run as a specific domain user and use trusted connection to the corresponding database on SQL Managed instance.
Attempting to use trusted connection from a domain joined virtual machine however (for example via SSMS results in the erro 'Azure Active Directory - Integrated' gives the error:
'Integrated Windows authentication supported only in federation flow.'
Looking at the Microsoft documentation it suggests it is possible to have trusted connections to SQL Managed Instance with 'seamless single sign-on' however the documentation only talks about an on premise domain connecting to Azure Active Directory.
Can anyone steer me in the right direction? are trusted connections possible in this setup? If not what is 'best practice' around connection strings to a SQL Managed Instance?
Thanks in advance
The best practice for Azure-native applications is to use Managed Identities to connect to Managed Instance. See eg: Connecting from your application to resources without handling credentials
Each Azure Virtual Machine, App Service App, Function App, etc can be provisioned with an AAD identity. Code running then can generate access tokens for resources (like Managed Instance) without ever touching a password or client secret.
Several Authentication strategies have been added to the SQL Client libraries to facilitate this. Or you can use Azure.Identity, or the local managed identity token endpoint library to fetch your own access token, and leverage that in the SQL Server client.
An alternative for lift-and-shift apps is to use Domain-joined VMs and use Windows Authentication for Managed Instance. This lets you continue to use traditional "Trusted Connection=true" from your VMs running in Azure to Managed Instance.

Provide App service security in Azure solutions

I have a click once windows application which already has authentication n Authorization built in. Earlier i used to deploy it on physical server n share the location with users so that they can install it n use it. But now we have decided to deploy it on azure PAAS service (App service ). But currently url is geting access by anyone which i want to restrict. Currently my organization AD is not synced with Azure AD. So not able to use Azure AD for authentication.
Kindly provide some better solutions other than restricting users based on IP.
If it's a file download you can put it on Azure Blob storage for download and generate short-time SAS tokens.
While IP address restrictions and Azure AD authentication would be one-efficient approach for your scenario. Since you do not want to go that route (due to environment limitations), If you wish you could authenticate users with the specified provider (Microsoft Account, Facebook, Google, Twitter or Any OpenID Connect provider). App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code.
App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. You can also use multiple sign-in providers.
So the simple process could be:
The option is Log in with . App Service redirects all anonymous requests to /.auth/login/<provider> for the provider you choose. If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized.
Kindly checkout step-step instructions on the process/workflow:
Configure your App Service or Azure Functions app to use Microsoft Account login
If your WebApp is on VNet, you can have service endpoints enabled for Microsoft.Web, through access restrictions.
See- Advanced usage of authentication and authorization in Azure App Service

Is it possible to connect to on-prem API through Azure AD Application Proxy without interactive user login?

I'd like to connect to an On-Prem API from an external cloud service using the Azure AD Application Proxy. I can connect and use the API by logging in with my Azure AD User in a browser, but would like a code-based-like login to use from my external service.
I've been digging through various articles the last couple of days, and it seems not possible without an Azure AD User interactive login. I am able to create an AD user for this service only if needed, but handling the interactive login from code or even through Postman seems troublesome.
Can someone point me in the right direction to solve this cloud-service to on-prem app solution? (unfortunately, I can't move the on-prem app to Azure).
EDIT: I'll be looking at using the pass-through option in the App registration, which means i need to handle the authentication and security in my API.
Perhaps you could consider using an on-premises data gateway instead, but it depends on where your external cloud service is hosted.
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-install
Essentially, if your external cloud service is completely outside your environment and your control, the data gateway can still be used, then you can expose a Logic App as a facade that can integrate with the on-premises data gateway. The external cloud service can then call the logic app to trigger the request, which can be secured by other means e.g. SAS key.

How to integrate On-Premweb application with Web app hosted on Azure (AAD authentication)?

What could be the ways to integrate a web application ( on-prem) to another web application (Azure) using azure AD authentication( happening in the background), with out the user being prompted for credentials.
It depends on how your on-premise application authenticated. Based on the description, you want to implement the single sign-on for the on-premise application with the application which protected by Azure AD.
In this scenario, you can deploy ADFS on-premise and make the on-premise web application authenticate by the ADFS. Then we need to enable the trust from the ADFS to Azure AD. After build the federated trust, when the users try to access the web application which protect by Azure AD will redirect to the ADFS, and if the users already authenticate the on-premise application they will not required to enter their credential again. Here is a figure to demonstrate this progress and you can refer more detail about it from this link.
And now, we can use Azure AD connect to integrate your on-premises directories with Azure Active Directory easily. You can refer the video on this link about different settings for this tool.

Resources