I have posted previously about az login using a Service Principal failing with the error No subscriptions found and I have run across others that have had similar issues. Capability seems shaky for some reason. What I am seeing now that has me scratching my head is when I run a script I have that does an az login with a service principal from my desktop computer it works fine...no issues. When I run the same script from my laptop, the login fails with the No subscriptions found error. What I have tried on the laptop:
Checked AZ CLI version...same as desktop
Ran az account clear to make sure everything was cleared out
Deleted Service Principal from AAD and recreated from laptop
I even ran az account clear on my desktop to make sure it was not working simply because it was cached and even after the clear, the az login worked fine.
Any thoughts on what might be causing this?
You need to assign a Role to the Service Principle, or add the flag --allow-no-subscriptions.
I have posted resolution for this under following thread.
https://stackoverflow.com/a/66108965/1712969
you might want to try command with this flag "--allow-no-subscriptions"
Related
I added a variable to the configuration settings area of my application and I need to delete it now because I do not need it or want that setting anymore. It's called WEBSITE_TIME_ZONE. I would like to get rid of the setting but I can't.
I have clicked on the delete button but it does not work. As soon as I refresh the page or log back in, the setting/variable (WEBSITE_TIME_ZONE) is there once again.
I have tried multiple browsers and clearing cache but none of that works.
I have clicked on Advanced Edit and tried to delete it from there as well but that does not work either. It just comes back after refreshing the page, (after saving the changes).
I have tried to edited the name and the value to bogus data which I then try and delete but that does not work either. I can't even actually edit the name of the setting, WEBSITE_TIME_ZONE. After an edit I save it and as soon as I come back to the page, the variable name WEBSITE_TIME_ZONE is there again.
I have stopped the app and tried to delete the entry and then start the app again but still does not work.
I tried running this command in command prompt on the SCM back end and that does not work either. It says 'az' is not recognized as an internal or external command, operable program or batch file.
az webapp config appsettings delete --name MyWebApp --resource-group MyResourceGroup --setting-names {setting-names}
I read about typing that in the Azure CLI by using the Azure Cloud Shell, but that seems to not be included in the subscription($200 USD / month) I am already paying for see image below. I thought this would work with PowerShell or the CMD on the KUDU console SCM area but I guess not. Looks like it has to be with Azure Cloud Shell which you have have to pay for on top of the normal costs...
Is there any way to delete this app setting without having to pay for yet another service? I have searched everywhere on the internet for this and every post that I see ends in the same, "I can't delete it".
Any suggestions?
Thank you!
I am able to delete the AppSetting WEBSITE_TIME_ZONE from Application Settings without any issues.
After refreshing, I can see the AppSetting is deleted.
I thought this would work with PowerShell or the CMD on the KUDU console SCM area but I guess not.
This command has to be run from Cloud Shell.
Open the Cloud Shell.
Tried to delete with the below command in Azure cloushell - Bash.
az webapp config appsettings delete --name YourWebAppName --resource-group YourRGName --setting-names {WEBSITE_TIME_ZONE}
It says 'az' is not recognized as an internal or external command, operable program or batch file.
As you are running the cloud shell for the first, you will get this error.
We need to set the Subscription and create storage account to run commands in Cloud shell.
Follow the steps mentioned in the MSDOC - Quickstart for Bash in Azure Cloud Shell
az account list
az account set --subscription 'YourSubscriptionName'
I have a Docker volume from ${USERPROFILE}/.azure to /root/.azure:rw. In my Dockerfile, I'm installing az-cli and then using DefaultAzureCredentials class in .NET (https://learn.microsoft.com/en-us/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet) to load the credentials.
It worked fine until a month ago, I had to az login on my machine and then it worked fine in Docker. However, about a month ago, when az-cli switched from ADAL to MSAL, it throws an exception saying I'm not logged in.
My guess is that az-cli stores the tokens somewhere else now, other than the .azure directory, or something else, I'm not sure. Anyone has any idea?
Earlier, Azure CLI save ADAL tokens and service principal entries to ~/.azure/accessToken.json
Later when Azure CLI use MSAL, it no longer generate accessTokens.json file.
Any existing workflow depending on accessTokens.json no longer works
So instead of DefaultAzureCredentials class, you can use AzureCliCredential class
AzureCliCredential class uses subprocess to call az account get-access-token to get an access token for the current logged-in account
Reference: MSAL-based Azure CLI | Microsoft Docs
For now you can use a pre-2.30 az-cli version both on your host system and inside your container. Instructions are here to install a specific version: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli
I am unable to run docker image dpage/pgadmin4 on azure web app (Linux) which is available on docker hub.
I have installed Docker in my Linux machine and was able to run that docker image locally. Then I created Web app in Azure with options as given below:
OS: Linux
Publish: Docker Image
App service plan: Linux app service
After creating web app, I added two env variables in App Settings section:
PGADMIN_DEFAULT_EMAIL : user#domain.com
PGADMIN_DEFAULT_PASSWORD : SuperSecret
Finally login screen is visible but when I enter above credentials, it doesn't work and keeps redirecting to login page.
Update: If login is working properly, screen appears as shown below.
!(pgadmin initial screen)
After several retries i once got an message (CSRF token invalid) displayed in the right-top corner of the login screen.
For CSRF to properly work there must be some serverside state? So I activated the "ARR affinity" in the "General Settings" on the azure "Configuration".
I also noticed in the explamples on documentation the two environment-variables PGADMIN_CONFIG_CONSOLE_LOG_LEVEL (which is in the example set to '10') and PGADMIN_CONFIG_ENHANCED_COOKIE_PROTECTION (which is in the example set to 'True').
After enabling "ARR" and setting PGADMIN_CONFIG_ENHANCED_COOKIE_PROTECTION to False the login started to work. I have no idea what PGADMIN_CONFIG_ENHANCED_COOKIE_PROTECTION is actually doing, so please take that with caution.
If thats not working for you, maybe setting PGADMIN_CONFIG_CONSOLE_LOG_LEVEL to 10 and enabling console debug logging can give you a clue whats happening.
For your issue, I do the test and find that it's really a strange thing. When I deploy the docker image dpage/pgadmin4 in Azure service Web App for Container through Azure CLI and set the app settings, there is no problem to log in with the user and password. But when I deploy it through the Azure portal, then I meet the same thing with you.
Not sure what is the reason, but the solution is that set the environment variables PGADMIN_DEFAULT_EMAIL and PGADMIN_DEFAULT_PASSWORD through the Azure CLI like below:
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PGADMIN_DEFAULT_EMAIL="user#domain.com" PGADMIN_DEFAULT_PASSWORD="SuperSecret"
If you really want to know the reason, then you can make feedback to Microsoft. Maybe it's a bug or some special settings.
Update
The screenshot of the test on my side here:
If I used Get-AzAutomationSchedule for my automation account, I get nothing in return because I used Remove-AzAutomationSchedule for all of them. But if I look in the portal, every schedule I've deployed is there present. If I select a schedule that I've removed using Powershell and then attempt to update the schedule in the portal, I get the crying rain cloud and it says
NewScheduleBladeV2
MICROSOFT_AZURE_AUTOMATION
NewScheduleBladeV2
The reacurrance is also listed as unknown in the list.
This is a problem not only for clarity when viewing in the portal, but if I attempt to run my ARM template again with the schedules there, I get an "Internal Server Error" code 500. I can't redeploy them if I delete them with Powershell.
Is there anyway to send something to Azure to update these? Not sure if I need to do some API call or some form of Set-Az cmdlet
Thanks
I have tried to reproduce the issue you are facing but all worked good for me when i used cmdlets Get-AzAutomationSchedule and Remove-AzAutomationSchedule of Az.Automation module versioned 1.2.1.
Is this still an issue at your end ? If yes, can you restart the browser after clearing the cache and deleting the cookies ?
I have tried three installs through the portal and finally one completely through Azure CLI (with Ubuntu on Windows). Each time the deployment completes but remotely run commands because they fail with "resource temporarily unavailable". I can SSH into the master server. When I do I find the kubectl commands all come up empty (nodes, pods, namespace, version). Service --status-all does not list a single Kubernete service (I would expect to see the API service at least).
When creating through the portal I manually created the SPN and verified I could login to Azure with it. During the CLI setup I let the install create the SPN.
I have tried restarting the master but nothing changes.
What am I missing? It is probably something easy but I am spinning my tires.