I've an azure application gateway-WAF. I would like to have a web app and a function app as the backend pools.
I need to have the requests reaching the corresponding applications.
The functions are called by the web app only.
I did try from my side - based on my understanding.
I created a backend pool for the function app - web app was already a backend pool and has the listener with port 443 and associated a rule.
For function app, I've created a Multi-site listener - Function app URL as the host name with HTTPS protocol and created a path-based rule (as the basic one is for the web app). The path is defined as /*path*/*
When I hit the URL - https://<*gatewayDNSname*>/apiroot/<*function*>
I'm getting the resource has been removed or temporarily down
It seems like the replica of this thread. Please follow up the mentioned thread for updates.
Related
I'm trying to configured an Azure Application Gateway in front of a web app. The web app is empty for now, only a single page to verify its running. I've added a custom domain and dns settings, verified in the network settings of the webapp. I've setup the AG following a few different links as I couldn't get a working example from a single source. I'm at the point now where my health checks are returning a 301. The lister is using port 80 as I have not setup the ssl yet. The app custom domain has no ssl binding either. The network security group has the default settings. I've checked the webapp before adding the private ip and it was fine, its just an empty page. So i'm wondering what could be causing the 301. Anyone have an idea what could be causing that or some further links I can check?
Thanks.
Resolved. The webApp had Https Only turned on in the settings, that was the cause of the 301. Doh!
We have a .Net MVC application that has a controller with a HttpPost Method type and the application is hosted in Azure.
When the application is Idle for 30 minutes and we click on submit button we could see the request being sent to server as HttpGet and there is an exception as unknown method.
I tried looking at app insights traces and there is no issue from the Azure end.
Controller class doesn’t have any method with type HttpGet for the save method.
Where am going wrong here?
May there be not any wrong with you, just use a low tier of Azure WebApp without enable the feature Always on like F1 Free Tier, as the figure below, to enable the Always on feature to avoid your webapp asleep and awake up by a request after idle.
If you can not enable it, please first follow the tips on Azure portal to scale up the tier of your app service plan, then to do it again.
According to the offical document Configure an App Service app in the Azure portal, as the quote and figure below, because Azure will idle your app without Always on enabled to reduce the infrastructure resource cost for no traffic.
Always On: Keep the app loaded even when there's no traffic. It's
required for continuous WebJobs or for WebJobs that are triggered
using a CRON expression.
I am trying build up a Staging Environment for an ASP.NET MVC Web App, but am stumbling from problem to problem, the last one having been this one: HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App
Currently I am getting a HTTP 403 - Forbidden, "You do not have permission to view this directory or page." error when trying to access the page.
Authentication-wise the App uses Azure Active Directory as Authentication Provider, which is working fine in local testing (using a Test-AAD) and in production. The local and productive apps are not using Azure Web Apps. I noticed on the Azure App Service page that there is a possibility to specify authentication right within Azure, but I don't really want / need to use that, as everything is specified within the app resp. configured in the web.config (ClientID, ClientSecret and Tenant). Anyway, when I tried filling in the Authentication on Azure directly it did not work either, so I removed it again.
What happens now is that the redirect to the Login page on login.microsoftonline.com works, and according to the AAD Admin the login attempt is being successful, or at least shows no pecularities. However, when being redirected back to my page, I get a generic 403, without any additional information that could help pin the problem down.
I did check all sorts of logs for further details, and the only pecularity I found is that for some very odd reason, all requests are made to a completely gibberish URL:
Requested URL / specified Reply URL: https:\\skillmanagementtest.azurewebsites.net
Actually requested URL according to logs: https:\\Skillmanagementtest:80
I have absolutely no clue where this URL originates from, however, "Skillmanagementtest" with that capitalization seems to be the name I specified for the Azure Web App:
Screenshot resource group items
The web.config is being transformed properly during the CI/CD pipeline and I double-checked the auth settings there (tenant, clientID, clientSecret), and I am really out of ideas what may be causing this problem.
One hint I found on other problems was to check the IIS logs, but when I attempted accessing the directory these logs were said to be placed in I was rejected access, even though I have owner permissions on the App Service...
UPDATE
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
Check to ensure that what you have in your web.config and app settings matches what you have in the reply URLs for your app registration in the portal. There may be some reference somewhere where the reply URL does not match.
Are you using the openid sample? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Also ensure that you are logging in with a user who has the right permissions under the tenant and to the app itself. My colleague and I made a short video that includes the right configurations that may be helpful for this use case. https://www.youtube.com/watch?v=MohaxN6fsDs
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
I successfully registered my ASP.NET MVC application to work with Azure AD. Currently the Sign-on URL parameter (Azure Active Directory->App registrations->New Application Registration) looks like https://localhost:44302/
But for production it apparently will be another (say, https://mycoolapp.com)
How should set up the application so that I could use Azure AD locally (for ex. for debugging) and in production.
Changing the Sign-on URL parameter every time doesn't seem to be a good option.
Firstly, you can make it work easily without changing sign-on URL every time. You just need to make sure that both URLs.. i.e. https://localhost:44302/ as well as https://mycoolapp.com are available in the Reply URLs for this application.
The value for Sign-on URL that you give at the time of creating app registration goes into two places. It becomes the Home Page URL under Properties for your web application and it also gets added as the first URL in the Reply URLs collection for your web application. Just make sure to add a the second URL to the Reply URLs collection after your app is registered and that's all.
On a side note, even though you can make things work with a single app registration for both production and localhost debugging, you may want to think about having two separate application registrations for production v/s local development and give permissions to production application only for administrators/dev ops if it makes sense.
Imagine any sensitive settings, like if you are using a secret key for your web application, you may not want your development team to have access to secret key for your production app registration even while debugging code. You can always change which app registration gets used in dev v/s production code based on configurations.
It's some of the headaches like these where Managed Service Identities are very appropriate, but whether that makes sense or not is a little different discussion than this one.
I would specify the production URL as the Sign-on URL and the production + localhost as the redirect-URL (since you can add multiple redirect-urls!).
See: Register a new application using the Azure portal
I'm certain I've done this a dozen times before, and I can't think what's causing this to fail now, but, I have an MVC web app with its app pool running as a domain account. It connects to a WebAPI app on the same domain which has Windows auth enabled.
I'd like to be able to read the MVC app pool account name using controller.User.Identity.Name on the WebAPI side, but it's coming back empty. I've tried just about everything, including explicitly setting the MVC app to "connect as specific user".
The MVC app is using HttpClient to connect to the API. I've tried passing an HttpClientHandler with UseDefaultCredentials set to true, but that had no effect.
Connecting to the WebAPI methods from my local machine correctly identifies my domain account. Is there something obvious I'm missing?
This was fixed by adding the BackConnectionHostNames key mentioned here:
https://stackoverflow.com/a/10311823/2179408
It wasn't necessary for me to make the legacyImpersonationPolicy and alwaysFlowImpersonationPolicy aspnet.config changes though.
The 401 responses I was receiving threw me off and led me to believe it was an IIS authentication issue.