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.
Related
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.
For my Azure Web Service, under Properties, the FTP/DEPLOYMENT USER seems to be of the form:
websitename\azuresubscriptiondirectoryname
But under Deployment Center, FTP, Dashboard, it is of the form:
websitename\$websitename
Where do I get the password for the first one, ie FTP/DEPLOYMENT USER?
The first one are user-level deployment credentials, they allow you to deploy any app in your account, as opposed to app-level credentials (the second you mentioned).
Assuming that you haven't configured them yet, you have to open the "Deployment center" section of your App Service. If you have multiple App Services, any of them will do).
Refer to this link for a how-to.
I'm having trouble connecting my Azure Web App to my Azure DevOps organization.
I somehow managed to do it for one Web App (by selecting creating a new 'DevOps Project') but now struggle at setting a new WebApp to link to that same DevOps pipeline. (The goal is to have a two stages delivery pipeline, which requires 2 webapps: one for QA, the other for Prod).
When creating a new WebApp, I go to Deployment Center > Azure Repos > Azure Pipelines (Preview) and get the following error message : "You do not have any valid Azure DevOps organization".
Any idea how to make that work? Note: I tried creating WebApps with same resource group and same App Service Plan and doesn't work.
Thanks a lot for any help.
Best
Lucas
UPDATE: The issue here is having Azure Portal "see" the DevOps organization.
Seems to be an account issue: you know how one has two options in account?
Pretty sure it has something to do with the Azure Portal and DevOps being on different account "directories": "Default Directory" VS "Microsoft Account". But still can't explain the behaviour....
I encountered the same "You do not have any valid Azure DevOps organization" message. I solved it by going to the Visual Studio Marketplace and enabling billing for our visualstudio.com repo for Microsoft-hosted CI/CD. Some documentation says DevOps (Azure Pipelines) is free for 5 users, I'm guessing we didn't qualify because we have 6 active users in our Azure Devops (visualstudio.com) repo. (We recently had to break out the credit card to enable a 6th team member.)
Here are the steps I used to get to the marketplace and enable billing:
In the Azure Portal, click "All services" then search for "devops".
Click "Azure DevOps organizations"
Our visualstudio.com (aka Azure DevOps, the service formerly known as VSTS) project repo was displayed in the results. Click on it.
A summary display appeared with "Setings | Remove billing | Set up billing | Connect AAD ..." along the top. In lower right of the summary area, click "All settings =>". An "Organization settings" blade (column) displays on the right.
In the "Organization settings" blade, click "Azure Pipelines". In our case, the display showed "MICROSOFT-HOSTED CI/CD" with "0 Edit" beneath, and SELF-HOSTED CI/CD with "1 Edit" beneath. The Self-Hosting doesn't apply to us, so...
Click "Edit" for the Microsoft hosted CI/CD item.
You will be taken to marketplace.visualstudio.com with "Microsoft-hosted CI/CD" displayed on the left and a screen where you can select the number of "Paid parallel jobs". In our case, we use a 3rd party service for our Microsoft licensing, so I wasn't able to see what the Total cost would be. But I chose 1 parallel job and continued through the process. Once I'd enabled billing, I was then able to go back into the Azure Portal and (after refresh) make it into the process of setting up a build pipeline as per the various videos and documentation.
As is so often the case with Microsoft, the initial "You do not have any valid Azure DevOps organization" message was not helpful, the process nothing like the smoke-and-mirror demos, and wording like "free for 5 users" misleading.
Hopefully the above will work as it did for me and save others some time.
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 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.