[Bug] WAM interactive dialog (the Account Picker) is immediately canceled when shown in an elevated app
See original GitHub issueWhich Version of MSAL are you using ? MSAL 4.29.0
Platform .NET 5
What authentication flow has the issue? Desktop / Mobile: Interactive
Is this a new or existing app? This is a new app or experiment
Repro
C# console app, .NET 5, target framework net5-windows10.0.17763.0
.
static async Task Main()
{
IPublicClientApplication app = PublicClientApplicationBuilder
.Create("my-client-id")
.WithAuthority("https://login.microsoftonline.com/my-tenant-id")
.WithExperimentalFeatures()
.WithBroker()
.Build();
await app.AcquireTokenInteractive(new string[] { "my-resource-id/.default" })
.ExecuteAsync();
}
Expected behavior The WAM interactive dialog (account picker) should be shown.
Actual behavior
If the console app is run elevated, the WAM dialog briefly flashes and is immediately canceled (MSAL returns authentication_canceled
). If the console app is run non-elevated, the WAM dialog is shown as expected.
Additional context/ Logs / Screenshots I see this issue on .NET framework, .NET Core 3.1, and .NET 5.
In case this is a bug in WAM itself, I am reproing this on Win10 20H2.
Issue Analytics
- State:
- Created 2 years ago
- Comments:12 (6 by maintainers)
Top Results From Across the Web
Desktop app that calls web APIs: Acquire a token by using ...
The "WAM Account Picker did not return an account" message indicates that either the application user closed the dialog that displays accounts, ...
Read more >MsalError Class (Microsoft.Identity.Client)
This error code comes back from AcquireTokenSilent(IEnumerable<String>, IAccount) calls when the OperatingSystemAccount user is passed as the account parameter.
Read more >Edit the action button | Websites + Marketing
Action buttons allow customers to contact you, pay you, schedule an appointment, or jump straight to any section of any page.
Read more >How do I resolve Duo user login issues in Office 365 ...
How do I resolve Duo user login issues in Office 365 caused by Microsoft's Web Account Manager (WAM)?.
Read more >BIG-IP 15.1.2 Fixes and Known Issues - MyF5 | Support
Cumulative fix details for BIG-IP v15.1.2 that are included in this release. 957337-1 : Mgmt in tmsh broken. Component: TMOS. Symptoms:
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
One possible interesting solution may be to set the COM security settings on the specific proxy/interface for the WAM account control, rather than try and change the COM security settings for the entire process via the registry or
CoInitializeSecurity
.Source: https://docs.microsoft.com/en-us/windows/win32/com/setting-processwide-security-with-coinitializesecurity
Source: https://docs.microsoft.com/en-us/windows/win32/com/setting-security-at-the-interface-proxy-level
This sounds like what’s happening, no?
Not sure if you’ve explored this possibility? @bgavrilMS @pmaytak
The root cause, as I understand it, is that MSAL makes a COM call to AccountsSettigsPane and sets a callback. When the user is done clicking around in the AccountsSettingsPane control, it needs to get back to MSAL via that callback. It looks like calling an elevated process from a COM component is contrary to the security settings of COM.
A workaround has been provided by the Windows team:
This is one of the native APIs that is historically known to have problems calling from .Net. The issue is that this needs to be called before COM remoting is initialized in a process or it will happen implicitly, and there are things CLR may do early in the process lifetime that cause this. This is mentioned (with some details inaccurate) on the pinvoke.net page: You shouldn’t call CoInitializeSecurity from managed code. http://pinvoke.net/default.aspx/ole32/CoInitializeSecurity.html
Most of what you can do with CoInitializeSecurity, including access permissions as needed here, can also be done with an AppID key for the exe (see here and here). Note that for COM to read this from an elevated process it must be in HKLM.