Closed FonsecaSergio closed 6 years ago
We experience the same issue with the version Seems like TokenCache.CacheData is not deserialized/set correctly when importing context from file
I experience the same problem. Same versions (AzureRM 6.8.1 and AzureRM.Profile 5.5.1) like Sergio. By running "Import-AzureRmContext -Path …. -Debug", I got the following messages
DEBUG: 08/31/2018 19:20:22: - TokenCache: Deserialized 0 items to token cache.
DEBUG: Microsoft.IdentityModel.Clients.ActiveDirectory Verbose: 1 :
DEBUG: 08/31/2018 19:20:22: df2ff16b-2a1a-4af6-8b6a-d7379609e04e - TokenCache: Looking up cache for a token...
DEBUG: Microsoft.IdentityModel.Clients.ActiveDirectory Information: 2 :
DEBUG: 08/31/2018 19:20:22: df2ff16b-2a1a-4af6-8b6a-d7379609e04e - TokenCache: No matching token was found in the cache
DEBUG: Microsoft.IdentityModel.Clients.ActiveDirectory Verbose: 1 :
DEBUG: 08/31/2018 19:20:22: df2ff16b-2a1a-4af6-8b6a-d7379609e04e - AcquireTokenSilentHandler: No token matching
arguments found in the cache
DEBUG: Microsoft.IdentityModel.Clients.ActiveDirectory Error: 4 :
DEBUG: 08/31/2018 19:20:22: df2ff16b-2a1a-4af6-8b6a-d7379609e04e -
@FonsecaSergio @leowumsft @OShevnin-Quest Is there a reason why you are not using automatic context persistence? If you just use Enable-AzureRmContextAutsave -Scope CurrentUser
your context will always be active whenever you open a PowerShell window.
@markcowl this is for a job that will run unattended using Windows scheduled task
@markcowl, please correct me if I am wrong. That autosave feature only keep the last context but I keep flipping between multiple accounts (commercial and gov) so that feature is not helpful for me.
@markcowl in our scenario, we may have several activities running in parallel using different credentials (i.e. different default contexts). And each of those activities can spawn several parallel workloads. Please suggest a better solution if exists, instead of saving/restoring the context.
Thank you
Just want to chime in and say that we're also experiencing this, or at least a similar issue, especially when we have multiple processes running in parallel. Even if we run Connect-AzureRmAccount first, specifying a credential and subscription id the subsequent cmdlet intermittently fails with the "credentials have expired" error (it's quite rare though, but it does happen often enough to be real issue).
We've tried to set "Scope" to Process and specify the "SkipContextPopulation" for the Connect-AzureRmAccount cmdlet and actually thought it helped for some time, but today we started to get the same error again, it usually happens when using PowerShell jobs that run simultaneously (the Connect-AzureRmAccount is ran inside each job).
We use this in Azure Automation on Hybrid Workers and have added the AzureRmContextAutoSave environment variable (set to false).
We target hundreds of different subscriptions so the context autosave feature is really not for us.
Not sure if it's the same problem or if I should add another issue regarding this?
Hi all,
I think I was facing a similar problem and can probably provide a solution or workaround, at least something you can test in 10 minutes.
My app connects to different Azure subscriptions for different users, one after another, and I began to face the Token/Expired Credentials since approx AzureRM 6.7.0. Now running 6.8.1, workaround is :
Clear-AzureRmContext # Thanks to Mark
Disable-AzureRmContextAutosave -Scope Process # Thanks to Mark, but my scope is Process
Import-AzureRmContext -Path $File # Where File is an EMPTY JSON FILE (saved when no context)
Dir "$($Env:Appdata)\Windows Azure Powershell" -Filter "Azure*.json" | Remove-Item -Force
Now you can Import-AzureRMContext yourjsonfile.json
and 4. are only needed for JSON logon, Connect-AzureRMAccount does not need them. probably only one of them is needed. Investigating further.
HTH, jc
Update. Step 3 is needed, Step 4 is NOT needed. The file contains { "DefaultContextKey": "Default", "EnvironmentTable": {}, "Contexts": {}, "ExtendedProperties": {} } I don't know if Clear-AzureRMContext or some similar cmdlet could do the same trick...
jc
Hi all,
I think I was facing a similar problem and can probably provide a solution or workaround, at least something you can test in 10 minutes.
My app connects to different Azure subscriptions for different users, one after another, and I began to face the Token/Expired Credentials since approx AzureRM 6.7.0. Now running 6.8.1, workaround is :
- Clear-AzureRmContext # Thanks to Mark
- Disable-AzureRmContextAutosave -Scope Process # Thanks to Mark, but my scope is Process
- Import-AzureRmContext -Path $File # Where File is an EMPTY JSON FILE (saved when no context)
- Dir "$($Env:Appdata)\Windows Azure Powershell" -Filter "Azure*.json" | Remove-Item -Force
- Now you can Import-AzureRMContext yourjsonfile.json
- and 4. are only needed for JSON logon, Connect-AzureRMAccount does not need them. probably only one of them is needed. Investigating further.
HTH, jc
+1 👍 currently scratching my head for 3 days now! Thanks a lot man! For me only steps 1 & 2 were needed. I was able to import the saved context again. Will inform after a few days of observation.
Happy to know it works ! Now let's hope Microsoft documents better all the Context idea, as promised. jc
Update: Sadly, reusing the saved context via Import and then Save still gives out errors. In order to renew it I had to manually login and save it again, as a work around we decided to use cred manager and just call it for automation purposes as a temporary fix.
Hi all, I think I was facing a similar problem and can probably provide a solution or workaround, at least something you can test in 10 minutes. My app connects to different Azure subscriptions for different users, one after another, and I began to face the Token/Expired Credentials since approx AzureRM 6.7.0. Now running 6.8.1, workaround is :
- Clear-AzureRmContext # Thanks to Mark
- Disable-AzureRmContextAutosave -Scope Process # Thanks to Mark, but my scope is Process
- Import-AzureRmContext -Path $File # Where File is an EMPTY JSON FILE (saved when no context)
- Dir "$($Env:Appdata)\Windows Azure Powershell" -Filter "Azure*.json" | Remove-Item -Force
- Now you can Import-AzureRMContext yourjsonfile.json
- and 4. are only needed for JSON logon, Connect-AzureRMAccount does not need them. probably only one of them is needed. Investigating further.
HTH, jc
+1 👍 currently scratching my head for 3 days now! Thanks a lot man! For me only steps 1 & 2 were needed. I was able to import the saved context again. Will inform after a few days of observation.
This works for me on build 6.8.1
@etfong have you checked again after a few days if the saved context is still reusable?
@etfong have you checked again after a few days if the saved context is still reusable?
Yes it works repeatedly
@etfong The issue is that, when importing a context, there is no way to merge tokens from any existing context and the context you are importing. The Import should simply overwrite any existing tokens.
@etfong @OShevnin-Quest @FonsecaSergio @leowumsft @AWahlqvist Also, for everyone on the thread, if you are using azure powershell in an environment where multiple scripts are running with different credentials, here are some recommended practices:
(1) Turn off context autosave, as this will make all authentication occur in memory, and isolate each session from the context changes in other sessions (Disable-AzureRContextAutosave -Scope Process
). If you are not also executing interactive cmdlets, then you can turn context autosave off for all sessions (Disable-AzureRMContextAutosave -Scope CurrentUser
)
(2) Authenticate at the beginning of your script, rather than relying on previous / imported contexts - Azure Automation provides default service principal authentication that should be easy to use at the beginning of scripts
(3) Use service principal authentication, as this allows granular control over authorization
Opened issue: #7456 which identifies the actual bug. If you are seeing a separate issue with authentication, please file another issue.
Closing this issue in favor of #7456 which should resolve the underlyign issue. Meanwhile, please follow the advice above, and please file issue if you are having specific problems, or need specific advice on your authentication scenario.
Hi all, I think I was facing a similar problem and can probably provide a solution or workaround, at least something you can test in 10 minutes. My app connects to different Azure subscriptions for different users, one after another, and I began to face the Token/Expired Credentials since approx AzureRM 6.7.0. Now running 6.8.1, workaround is :
- Clear-AzureRmContext # Thanks to Mark
- Disable-AzureRmContextAutosave -Scope Process # Thanks to Mark, but my scope is Process
- Import-AzureRmContext -Path $File # Where File is an EMPTY JSON FILE (saved when no context)
- Dir "$($Env:Appdata)\Windows Azure Powershell" -Filter "Azure*.json" | Remove-Item -Force
- Now you can Import-AzureRMContext yourjsonfile.json
- and 4. are only needed for JSON logon, Connect-AzureRMAccount does not need them. probably only one of them is needed. Investigating further.
HTH, jc
+1 👍 currently scratching my head for 3 days now! Thanks a lot man! For me only steps 1 & 2 were needed. I was able to import the saved context again. Will inform after a few days of observation.
This works for me on build 6.8.1
This works for me on AzureRM 6.10.0. But I should execute these clear context scripts after each Import-AzureRmContext.
Turn off context autosave for all session (Disable-AzureRMContextAutosave -Scope CurrentUser) is not effective my environment.
@juancrl I cannot get this to work, I am not sure what i am doing wrong.
Our scripts run jobs, prior to starting the job we run Save-AzureRmContext and save the file locally, then we run Import-AzureRmContext and we get the error message.
If we run Clear-AzureRmContext in our script then we cannot save the profile as it is out the window.. would love some explanation here, thanks a lot in advance.
Each job runs in a separate runspace... so probably the AzureRM context has to be separated per job. I don't know what you're trying to achieve, but if each job has to run under a different user, try to do all the context clearing inside each of the job's code, not outside of it... I don't understand the "it is out the window" part. Which window are you referring to ?
Each job runs in a separate runspace... so probably the AzureRM context has to be separated per job. I don't know what you're trying to achieve, but if each job has to run under a different user, try to do all the context clearing inside each of the job's code, not outside of it... I don't understand the "it is out the window" part. Which window are you referring to ?
Hey Juan, I am basically trying to run async processes, for this we have to save the profile else the job will be out of context, "out the window" i meant that the account is getting cleared 😆 I will try to clear the context inside the job and see what is going on
@pixelicious Please file a separate issue if the advice above does not work for you. We need to ensure that we have captured the details of your particular scenario. If you file an issue, the issue template will guide you to providing the correct information for us to diagnose your particular issue. Further comments on this issue make it difficult to track where there is still an active issue, and what the active issue is.
What was the solution ? I am facing the same issue in Azure Automation Runbook.
When I run the same commands locally in a PS it works fine. But when it runs via the Automation Runbook it fails.
Get-AzureRmADUser : Your Azure credentials have not been set up or have expired, please run Connect-AzureRmAccount to set up your Azure credentials. At line:23 char:18
Description
Script/Steps for Reproduction
Module Version
Environment Data
Debug Output