-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azcontext.TokenCache is null with Az.Accounts > v1.9.5 and breaks Azure Login scenarios #13337
Comments
The issues seems to be in the new version of Az.Accounts - 2.1.0. Downgrading to 1.9.5 fixes the issue. On the other hand, it also doesn't work in PS 7 with Az.Accounts 2.1.0. So the version of PS does not seem relevant. |
Although there is a work-around (for now) to delete Az.Accounts > 1.9.5 (and reinstall 1.9.5), it will be painful to deal with an incoming stream of support issues from folks who will be broken (with a basic login scenario) and told to use the work-around. Possible to have someone look at this as soon as possible since it impacts azure login? Thanks! |
We are using TokenCache.ReadItems() after Connect-AZAccount to read token cache, which is working fine in version1.9.5. From 2.1.0, reading from token cache fails with below error. [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureTokenCache] does not contain a method named 'ReadItems' In our case, we use it to register on-premises Azure Stack HCI |
Thanks for reporting the issue. Since Az.Accounts 2.x, the authentication library is changed from ADAL to MSAL, MSAL library and extension is responsible for token cache encryption. We don't expose token cache object because of security concern. However, we also realize that get access token is valid scenario, we plan to add one additional cmdlet Get-AzAccessToken to serve such purpose, and plan to release it in next sprint. |
Great to hear that finally that Get-AzAccessToken will exist. Wondering if there are details on what it will support. Also it is nice that this is coming but the current release breaks all existing usage of the TokenCache back to Az 4.3 which is going to cause a bunch of nasty support issues. Also dont see any release notice to 2.1 with any breaking change notifications. Not sure how to deal with a well documented workaround for the missing Get-AzAccessToken being broken without providing a replacement solution. |
In our case the work around of using 1.9.5 is not working. We use both Az.Resources and Az.Accounts modules. Az.Resources module(even the older version) seems to be installing and using the latest version of Az.Accounts module by default and version 2.1.0 of Az.Accounts is being picked up in PS Session. Can you suggest a workaround that works with using this along with Az.Resources module? |
Tried to downgrade to Az.StackHCI 0.2.0 instead of 0.3.0 and surprise! It gets the latest Az.Accounts 2.1.0. I've been trying to evaluate Azure Stack HCI and no luck at the latest step: PS C:\Windows\system32> Register-AzStackHCI `
>> -SubscriptionId "my-subscription-id" `
>> -ResourceName "azshciclus" `
>> -ResourceGroupName "AzureStackHCIRegistration" `
>> -Region "EastUS" `
>> -ComputerName "AZSHCINODE01.azshci.local" `
>> -Credential $azshciNodeCreds
Method invocation failed because [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureTokenCache] does
not contain a method named 'ReadItems'.
At C:\Program Files\WindowsPowerShell\Modules\Az.StackHCI\0.3.0\Az.StackHCI.psm1:200 char:5
+ $graphTokenItem = [Microsoft.Azure.Commands.Common.Authentication ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : MethodNotFound And this happens right after you set 4 or 5 VMs and like I said, it's the latest step to see the thing working! |
@ramirezalfredo , could you please try the following steps to use 0.2.0:
Install-Module Az.Accounts -RequiredVersion 1.9.5 -Repository PSGallery -Force
Import-Module Az.Accounts -RequiredVersion 1.9.5 |
I was using the (Get-AzContext).TokenCache.ReadItems() to then test the ExpiresOn to determine if the token is now expired and then force the user to log back in. Is there a better way from Get-AzContext to know if we need to sign back in again? |
Different way to get token after Connect-AzAccount, even with newest versions of Az.Account. $AzContext = Get-AzContext
$ArmToken = [Microsoft.Azure.Commands.Common.Authentication.AzureSession]::Instance.AuthenticationFactory.Authenticate(
$AzContext.'Account',
$AzContext.'Environment',
$AzContext.'Tenant'.'Id',
$null,
[Microsoft.Azure.Commands.Common.Authentication.ShowDialog]::Never,
$null,
'https://management.azure.com/'
) Resources
|
In addition to what was mentioned above, this update has not only impacted token cache retrieval in my PowerShell environment but also basic commands such as Get-AzSubscription. I have access to over 70 subs across 3 tenants and none of them are returned. Get-AzSubscription
WARNING: Unable to acquire token for tenant '########-####-####-####-###########1'
WARNING: Unable to acquire token for tenant '########-####-####-####-###########2'
WARNING: Unable to acquire token for tenant '########-####-####-####-###########3'
In addition, since we are changing the way we are doing things in 2.x version "the authentication library is changed from ADAL to MSAL, MSAL library and extension is responsible for token cache encryption" are we not going to have a deprecation path or is the path to move back? This is going to in fact hit a lot of customers / Azure DevOps pipelines, etc. There is no indication on resolution when this cmdlet us updated and things break. |
Update here - I had to do a "logout-azAccount" about 3 times (likely for each tenant I was attached to) to clear any cached logins and now the subscription listing returns and also the workaround specified for obtaining a token by @o-l-a-v . I will continue testing this workaround through Azure DevOps, Mac/Linux/Windows to ensure auth is functioning for token access. Will watch this issue for updates. |
Try "Clear-AzContext -Force" instead next time. Instead of Diconnect-AcAccount, which will not remove all AzContexts in one go. Try "Get-AzContext -ListAvailable" to see all the tenants/subs you have access to by using "Set-AzContext". Auth with the Az.Accounts module is very different from AzureAD or MsOnline. |
Actually my bad - great point. Thanks for your code example btw. Testing now. Seems to work nicely from PS - will test in other avenues. https://aka.ms/AzPolicyScripts is the source of my current auth woes as I heavily use REST AUTH Tokens - this will help. Need to try backwards compat as well with older cmdlets in Az.Accounts but hoping for good news. |
This is due to changes in the Az.Accounts module where the TokenCache is no longer popoulated. Ref: Azure/azure-powershell#13337
Versions of the Az.Accounts module >1.9.5 no longer populate AzContext's TokenCache property, which we relied on when performing Graph API operations. (ref: Azure/azure-powershell#13337) This change alters the way we test for graph API access and uses the azure-cli `az rest` command to handle authenticating and calling the Graph API. A future Az PowerShell release may extend the Invoke-AzRestMethod cmdlet to support more endpoints than just AzureRM, which should allow us to switch back to a pure PowerShell solution.
Close the issue as |
This issue is still happening as of July 2021 |
@mgreenegit , azcontext.TokenCache is set as null on purpose after Az.Accounts 2.x because of MSAL migration, user could use Get-AzAccessToken to get token instead. Could you please let us know why do you reopen the issue? |
Ah I see. This issue is similar to what I repro here, but not the same. |
Hi, is there any methods to retrieve RefreshToken? Previously it will store within TokenCache, but it is set as null on purpose now and there is no something similar as Get-AzAccessToken, anybody have a workaround for this? Thank you. |
Description
azcontext.TokenCache is null when using Az.Accounts > v1.9.5. When someone installs Az PowerShell since 10/27, login scenarios appear to be broken. Downgrading Az.Accounts to 1.9.5 seems to work but is a major issue with Partners who we have install Az PowerShell and asking them to delete Az.Accounts (say v2.1.0) and reinstall v1.9.5.
Steps to reproduce
Environment data
Module versions
Debug output
Error output
The text was updated successfully, but these errors were encountered: