-
Notifications
You must be signed in to change notification settings - Fork 344
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
[Bug] Wam returned default account that doesn't match the account passed in (508065737) #4945
Comments
Do the MSA and AAD account have the same UPN ? |
@50Wliu, in general this behavior looks by design GetAccountsAsync() returns all accounts that are available on the system not only the accounts that application previously sign-ed in with. |
Thanks. This isn't clear from the docs - https://aka.ms/msal-net-wam says "Try to use the previously signed-in account from the cache" which implies that they have previously successfully signed in to the app, and https://learn.microsoft.com/en-us/dotnet/api/microsoft.identity.client.iclientapplicationbase.getaccountsasync?view=msal-dotnet-latest says "Returns all the available accounts in the user token cache for the application", which again seems to point to an app-specific cache, not a global cache. As far as UPN, are you asking about the <username>@email part of the account? If so, the usernames are different between the MSA & the AAD. |
The second link is MSAL .Net's documentation. MSAL .Net (and many other MSALs, for that matter) manages tokens for the current app, so, that "Returns all the available accounts in the user token cache for the application" wording was accurate. WAM, on the other hand, manages tokens/accounts on the device. So, both docs are technically correct. Perhaps a better question to ask is why the code snippet above would end up with "Wam returned default account that doesn't match the account passed in". Semantically, |
Can you share the code for |
@rayluo, Error corresponding to tag "tag_4sh5j - Wam returned default account that doesn't match the account passed in" is an t optimization effort where account MSAL.net passes is not found in WAM cache we try to see if the default account matches the passed in account. This is an understood path which can be particularly confusing when WAM per app accounts are in the mix. |
So, was that MSA account established via native MSAL .Net, rather than via WAM? If that would be the case, perhaps the AcquireTokenSilent() would work if it also bypasses WAM. There was a recent concept of |
GetBrokerPublicClientApplication: BrokerOptions options = new(BrokerOptions.OperatingSystems.Windows)
{
Title = "[App Title Here]",
ListOperatingSystemAccounts = true, // We want work accounts
};
return PublicClientApplicationBuilder
.Create(this.ClientId)
.WithAuthority(AzureCloudInstance.AzurePublic, AadAuthorityAudience.AzureAdMyOrg)
.WithTenantId(this.TenantId)
.WithLegacyCacheCompatibility(false)
.WithParentActivityOrWindow(GetConsoleOrTerminalWindow)
.WithDefaultRedirectUri()
.WithLogging(new MSALLogger(), true)
.WithBroker(options)
.Build(); EDIT: This code changed slightly recently. On the versions currently in production and hitting this issue, WithAuthority used to be: .WithAuthority(Authority, validateAuthority: false)
.WithInstanceDiscoveryMetadata(LoadInstanceDiscoveryMetadata(authenticationMethod, telemetry))
// No .WithTenantId
If this is a question for me, how would I check? I would be very surprised if AcquireTokenSilent would work with the MSA, as we have our app set to "Accounts in this organizational directory only (Microsoft only - Single tenant)". |
I don't think you should use this feature. SSO with Windows can be achieved through @iulico-1 - maybe you should deprecate this API? Or at least hide it from Visual Studio intellisense? |
Woah! That's extremely confusing. My IntelliSense for that currently says "Allows the Windows broker to list Work and School accounts as part of the ClientApplicationBase.GetAccountsAsync()" - it doesn't mention MSAs! |
I got the same issue when i have default account |
Library version used
4.61.3
.NET version
.NET Framework 4.8
Scenario
PublicClient - desktop app
Is this a new or an existing app?
The app is in production, I haven't upgraded MSAL, but started seeing this issue
Issue description and reproduction steps
We have an internal-only PCA that has WAM enabled. We are seeing a high number of WAM Silent failures due to
Wam returned default account that doesn't match the account passed in
.After enabling verbose logs, we see that WAM returns two accounts from
app.GetAccountsAsync()
:My reading of
app.GetAccountsAsync
is that this method should only return accounts that have successfully logged into the app previously. How is it returning an MSA when our app is single-tenant Entra-only? (And the MSA is not a guest in the tenant)Relevant code snippets
Expected behavior
GetAccountsAsync to only return accounts that can sign in.
Identity provider
Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)
Regression
No response
Solution and workarounds
No response
The text was updated successfully, but these errors were encountered: