Connect-AzAccount : InteractiveBrowserCredential authentication failed: Persistence check failed. Inspect inner exception for details #13691
Comments
msft-jasonparker
added
the
needs-triage
ghost
added
question
|
Thank god, I thought I was the only one. For what it is worth, this is happening on Mac for me. I deleted all the |
|
We were able to confirm that the AzureAD module works using |
|
@msft-jasonparker Thanks for the update. Does it help to let you know that the device code flow does not work either? |
|
Correct, -DeviceCode fails for me also |
|
@APIWT - Can you check your Intermediate CA Store and verify this certificate is not expired: Microsoft Code Signing PCA 2011 |
|
@msft-jasonparker I would be happy to, I just don't know how. If you can guide me in the right direction I can try ASAP |
dingmeng-xue
added
Authentication
and removed
needs-triage
|
Thanks for reporting the issue. @msft-jasonparker, could you please check if %USERPROFILE%\AppData\Local\.IdentityService\msal.cache exists? If yes, probably the file is damaged, please make one copy of this file (we may need your help for further investigation), then delete the original file and restart powershell to try again; if no, probably it is permission issue. Add @bgavrilMS to comment for the error if having any: |
|
@erich-wang We deleted both msal.cache and wiped the keychain with no luck. Also tried sudo. |
|
We are using DP-API to encrypt the tokens at rest on Windows. DP-API requires a user session. Are you connected to the box remotely somehow? |
|
@bgavrilMS Just a quick reminder, we are on Mac and we are also affected by this issue. |
|
@APIWT - are you using the Mac to remotely connect to a Windows box? Is there a Windows machine anywhere involved? The reason I'm asking is that the exception in the strack trace is in a code path that should only execute on Windows. |
|
@bgavrilMS I don't believe so. Here is a stack trace from Mac if that helps: |
|
@APIWT - that is a different exception, I suggest you log a separate bug. |
|
I can do that, but they seem highly related even with slightly different stack traces. |
|
The exception in your case is pointing to a KeyChain access error with code 25293. KeyChain is the Mac credential manager. The original exception points to a DPAPI exception. DPAPI is a Windows encryption mechanism. The stack trace is mostly similar because the library that is responsible for encrypting creds uses one mechanism on Win and a different mechanism on Mac. As a workaround for you, can you try to delete the entry from KeyChain related to PowerShell ? (@erich-wang - where do you folks store it exactly?) |
|
Our repro is from a Windows 10 multi-session VM in Azure WVD. User checked the directory and the file did not exist and the user is not blocked from permissions. |
|
DPAPI requires the user profile to be loaded. This article (the second half) describes similar problems and provides some workarounds, could you please try them out? |
|
Thanks @bgavrilMS for that helpful tip about the user profile having to be loaded. But what do you mean by "This article"? I'm not seeing any link |
@bgavrilMS which article are you referring to? In our specific situation, the user profile is fully loaded. |
|
DPAPI issues sometimes occurs when an Read Write Domain Controller is not accessible. A workaround and more explanation can be found in the Microsoft Article DPAPI MasterKey backup failures when RWDC isn't available |
|
I am facing the same issue in my Mac, did anyone got solution for this authentication issue? |
|
I ran into this issue and, after alot of frustration, was able to solve it by down grading the Az.Accounts package to version 1.6.1. It had upgraded to version 2.2.8 which seems to be broken. |
Same here. Solved downgrading it aswell. Had to uninstall the 2.2.8 version a few times, since for some reason it kept installing.. |
|
Also commented on #14861: The only way I've managed to get it to work is by using Powershell ISE. From ISE a login screen pops up when the command is executed and I can authenticate without issue. From the standard Powershell console (same version, 5.1) I get: The |
|
I have started experiencing the issue on 4/26. I was working properly before that point in time with the same version of all modules AzAccounts 2.2.6, since upgraded to 2.2.8 to no avail. If I:
However, the next time I load up Powershell command I receive the error once again, and have to repeat the aforementioned steps again. I am including debug output to help diagnose the issue... I had not tried using Powershell ISE, as it is not something that I normally do, however, the ISE does work without issue. |
|
To sum up, there seem to several separate issues happening here, looking at the inner exception
It looks like DPAPI is not available on the machine. I've seen this in some virtualized environments, there seem to be several root causes. Please look it up or open support cases directly on Windows.
|
|
@bgavrilMS Some users are using Az.Accounts-module version 2.3.0 in PowerShell 5.1 on Windows Server 2019 in a domain with a Read-Only Domain Controller (no access to Read/Write Domain Controller). How should they get this working for now? Change the registry for DPAPI mentioned here https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/dpapi-masterkey-backup-failures ? |
|
@mbsnl - if possible, try the registry setting first. Some organizations might not be ok with this change, so it needs to be very clearly documented (I don't personally understand it). A Windows or Windows Server support case should be the path forward - if they can provide an alternative encryption solution or a different way to use the encryption APIs, I'm happy to implement it. @erich-wang can provide guidance on downgrading Az.Accounts-module. By the way Erich, what did the old module do? Where did it store its tokens? |
|
If modules from Az 4.* satisfies your daily work, you may downgrade to use Az.Accounts 1.9.5 and Az 4.8:
Install-Module Az.Accounts -RequiredVersion 1.9.5 -Repository PSGallery
Install-Module Az -RequiredVersion 4.8 -Repository PSGallery@bgavrilMS , the old versions of Az.Accounts 1.* are using ADAL instead of MSAL. |
|
@erich-wang - ADAL / MSAL just fetch tokens. I was more curious where the old Az.Accounts module stores them and how. |
@bgavrilMS , Az.Accounts 1.x saves token as plain text under ~/.Azure |
|
This is due TLS version. For a workaround just run this command before: [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 For a definitive solution, set registry: |
|
@flavio-neves, per my understanding the issue has nothing to do with TLS, furthermore TLS 1.2 has been enabled on Windows 10 by default. Are you able to reproduce the issue and solve it by setting SecurityProtocol? If yes, could you please share the debug trace before and after using the fix? You may enable the debug trace by running
|
|
Still not working at all on Ps 5.1. But working as expected switching to 7.1. |
|
Having the same problem on MacOS, with code that had been working for months. After retrying a few times, I deleted all the Update: the error is back, and deleting the .bin file doesn't help anymore :-\
var context = new TokenRequestContext(/* ...string[]....*/);
var options = new InteractiveBrowserCredentialOptions
{
TenantId = /* ... */,
ClientId = /* ... */,
TokenCachePersistenceOptions = new TokenCachePersistenceOptions
{
UnsafeAllowUnencryptedStorage = true,
Name = this.tokenCacheName,
},
DisableAutomaticAuthentication = false,
};
var credential = new InteractiveBrowserCredential(options);
AuthenticationRecord authRecord = await credential.AuthenticateAsync(context); |
Description
Unable to login to Azure (Public or Government) using Az PowerShell module
Steps to reproduce
Environment data
Module versions
Debug output
The text was updated successfully, but these errors were encountered: