I have an Azure WebApp and have activated the "Active Directory Authentication" in the Azure Preview Potal. Let's call it https://mysite.azurewebsites.net (not a real URL) Whis works as expected. However, when we add a deployment slot, we can't get authentication to work properly. When accessing the staged WebApp, e.g. https://mysite-staging.azurewebsites.net (not a real URL), we get redirected to
https://login.microsoftonline.com/<our-directory-guid>/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fmysite-staging.azurewebsites.net/....
But the login portal gives us an error message:
AADSTS50011: The reply address 'https://mysite-staging.azurewebsites.net/<our-appliction-guid>/login' does not match the reply addresses configured for the application: .
The problem is, the WebApp does not show up as an application in our directory, so we can't set up alternate reploy URLs for it.
Is there any way to specify alternate addresses for WebApps, so that Azure AD login will work for deployment slots?
When you create the deployment slot, you need to re-setup the authentication for it, as if it's a new application. (From an app-service perspective, it is.)
The steps are roughly:
In the portal, go to your deployment slot under your app-service.
go to authentication/authorization
Go through all the steps to setup your authentication/authorization the same as for your production app. (Authenticate via AzureAD, Choose the provider, etc.)
Under "Manage App" in the staging environment, go to settings, and add new reply URL's for your staging environment. You should have your regular reply URL, and then the staging version:
https://myapp.azurewebsites.net/signin-oidc
https://myapp-staging.azurewebsites.net/signin-oidc
You should then be able to get in.
One weird thing that happened to me, is this didn't work, then I went into the staging authentication, and turned it off. That made everything work, and it correctly authenticated and didn't let me in if I wasn't signed in.
(I realize I'm posting this answer years after the original question, but after spending the better part of a week figuring it out, and this question repeatedly came up on searched, I wanted to document what I ended up doing in case someone else has a problem.)
I sure this will not fix the deployment slot is still pointing to live app but this fix this error as it is very silly.
AADSTS50011: The reply address 'https://mysite-staging.azurewebsites.net//login' does not match the reply addresses configured for the application: .
When you configure your URL under the application settings in Azure AD, you forgot… a trailing slash! That’s it! Can you believe that?
In other words, change this:
http://yoururlforyourapp
to this:
http://yoururlforyourapp/
Done! You’re welcome.
From http://www.matvelloso.com/2015/01/30/troubleshooting-common-azure-active-directory-errors/
Unfortunately it looks like you ran into some bugs in that version of the preview portal.
The Reply URL issue is likely because you created the staging slot after you configured auth on the production slot. In that version, we cloned the auth settings so your staging slot ended up pointing to the existing AAD application without adding the new Reply URL. This issue has been fixed by not auto-cloning auth settings when a new slot is created.
In any case, you should be able to find your application in the AAD management portal. If you're not able to see it, it could be because you need to change the "Show" dropdown filter from "Applications my company uses" to "Applications my company owns". Locating it and adding the staging Reply URL would have also worked around the issue mentioned above.
The error message you saw when trying to re-configure auth on your staging slot was likely another bug in the management portal if you were only seeing it on that staging slot.
The Authentication / Authorization blade has been radically updated since your question was asked, and all of these issues should be fixed now. Sorry for the inconvenience. I hope you were able to make progress in spite of these issues.
Related
I deleted azure webapp through azure portal. It seems it is deleted because when I run:
az webapp list
my deleted web app is not showing. But I can still access it oldwebapp.azurewebsites.net.
And it's showing in google search as well. Is there any cache I need to clear or other places I can check to fully remove it?
Also checked other places if there is any connection to this old web app, but didn't find any or don't know where to look.
I have also encountered a similar situation and found that the resource has been deleted after checking in portal. Sometimes visit it using InPrivate window also succeed.
It seems that this is a bug, and you don't need to care about it, or if necessary, you can also submit a bug in a GitHub Issue.
If you need to use the url again by creating a new webapp with the same name, try deploy a new project and access it, it should be refresh to the new one.
I can't see all my Github organization repositories in the dropdown of Azure deployment center. Azure was already authorized long time ago and the dropdown was showing all the repos correctly until last week when I was playing arround in the DevOps and had to authorize again but I think it broke something. Now in the DevOps, I can see all the repos of the organization but not in the deployment center of my web apps where I only see 3, which are not the ones I want...
Since it's already authorized I can't see the "Authorize" button it asked the first time. I can "Change account" but it does nothing.
On Github I reinstalled Azure Pipelines in "Installed GitHub Apps" thinking it would fix the problem but it doesn't.
Azure App Service is also Approved in the "Third party access" tab. I tried to "Deny access/Grant access" whit no result.
Is there a way to remove the authorization on Azure and then re-authorize ? Or maybe I need to add something in the Github organization settings ?
Yes, this need you to re-authorization.
This is how to do that:
First, remove the old authorization.
Second, go to your web app and start a new authorization.
Third, The reason you ca n’t see it in the deployment is because you do n’t have access rights. You need to mark all the organizations that you need access to in this step.
I mistakenly deleted the Azure AD application linked to my WebApp. Then I wanted to link it to a new one but the Azure AD Settings page keeps loading and looks stuck.
I tried to turn the authentication Off and then On again to see if it would restore the Azure AD to "Not Configured", but it doesn't work.
Here is a picture of my Auth Config:
Here is a picture of my Azure AD Config (nothing is clickable):
For now the only solution I have is to either disable the Auth completely or make a new WebApp. Is this a known bug?
So,
I deleted the application in Azure AD on Friday. Then I noticed the login didn't work anymore the following Monday. And today (Tuesday) it works again. The Auth settings page isn't stuck anymore and I could easily go in the "Advanced" tab and switch the ClienId to a valid one.
Not sure what the issue was, but it's fixed now.
I have been able to work in Azure APIM with no problems until yesterday. Another member on my team can edit and save with no problems; but my save to an Inbound Processing rule always fails with:
Could not save policy for "Access API 1.2" API. Please try again
later.
Thoughts?
Of Note:
Our companies security access team verifies that I am a contributor to APIM
I login in through the companies' two factor authentication system into Azure.
Same results on Edge/Chrome.
I can update individual endpoint api policies.
Our company opened a Microsoft Support ticket on this and their response was
You are running into a known issue with APIM integration with ARM. The
dev team is working on a fix for this issue now and we are told it
will get deployed by this evening.
The following day it was working for me
The APIM dev team fixed the issue late yesterday and you should now
see the ability to update policies for the API scope too.
Note to anyone running into this situation in the future the secondary advice given revolved around the browser which was
Make sure you’ll not pulling down cached files. Try loading an
in-private session or press CTRL+F5 to refresh the page and pull down
new files.
I cannot get x-ms-routing-name to do anything when I explicitly specify it in the URL or in a cookie. I am sure I have had it working in the past.
I have a Web App with the default (production) and a deployment slot called "prerelease", which I want to route some customers to as an early access version.
I have gone into 'Testing in Production' configuration and set the "prerelease" slot to 0%. I've tried it both with and without Traffic Manager, and over both HTTP and HTTPS.
I've been through this post and can't see anything else to help me: https://learn.microsoft.com/en-in/azure/app-service-web/app-service-web-test-in-production-get-start
Why might this not be working?
It turns out that this is an intermittent Microsoft Azure bug. The x-ms-routing-name cookie occasionally stops after you swap slots. We have an active support request open with Microsoft. It seems that they fix the problem, but it re-occurs after some time.
Edit: workaround is to go into the app => Testing in Production, make a change to activate the Save button and click save. This will trigger routing to start working again.