[Bug?] COMException calling PublicClientApplication.AcquireTokenSilentAsync

Which version of MSAL.NET are you using? MSAL.NET 4.45.0

Platform .NET 6.0

What authentication flow has the issue? WAM (not broker preview) Authorization code flow

Is this a new or existing app? Existing application. New scenario.

Repro Context: We have test engineer wanting to perform test automation.

User logs into Windows using a non-domain account. The application is then “run-as” a domain account. I’m told it is a service account.

First we call IPublicClientApplication.GetAccountsAsync() which returns a single item which is the service account.

We then call await IPublicClientApplication.AcquireTokenSilent(scopes, account) .ExecuteAsync() .ConfigureAwait(false);

Expected behavior I expected MSAL to throw a MSALUIRequiredException if interactive login was required. But I don’t know what to do with a COMException.

Actual behavior System.Runtime.InteropServices.COMException: 'A specified logon session does not exist. It may have already been terminated. (0x80070520)'

Additional context / logs / screenshots / links to code Checked the local security policy and found “Network access: Do not allow storage of passwords and credentials for network authentication” was disabled. So that isn’t the cause. But I don’t know what else might be.

[Camios]

Also tested with 4.48.0 and the only difference was the Unexpected Error’s value (0xffffffff80070520 vs 0x80070520)

[Camios]

@MSamWils our application needs to run with elevated rights (must be run as an administrator).

Most of our users have local admin, but we have a subset of scenarios where they don’t:

1. some users have a non-admin account to perform regular work and a secondary admin account for limited elevated use - such as our application
2. test automation, similar to above, where there’s a non-admin account used for logging into Windows and an admin service account for running (UI) tests

At the time, we found cases where apps were launched using “run-as” didn’t use the silent (with broker) auth flow, despite being configured to use it. We’d like the application’s login flow (in both cases) to be the same as if the user originally logged into Windows with an admin account.