WAM + RunAs issue - COMException calling PublicClientApplication.AcquireTokenSilentAsync

[Camios]

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.

[bgavrilMS]

Can you please try broker preview version?

[Camios]

@bgavrilMS using preview broker (Microsoft.Identity.Client.Broker version 4.45.0-preview) gives a different error

Microsoft.Identity.Client.MsalServiceException: 'Unknown Status: Unexpected Error: 0x80070520 Context: Winrt exception was thrown during GetTokenSilently '(pii)'. Tag: 0x2339e502 (error code -2147023584) (internal error code 590996738)'

[Camios]

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

[bgavrilMS]

Ok, thanks @Camios , we will need to investigate this. The Windows error code you mention is:

I'm a little confused when you say IPublicClientApplication.GetAccountsAsync() returns 1 account. Normally this returns just the accounts in the cache. Do you mean that you interactively login with the domain account and this works fine, but then the silent auth fails?

[Camios]

I don't know the history of the machine, I'm coming to it at this point in time where the cache does appear to have one entry.

I could back up the token cache and delete it an try a "fresh" login if you like?

On Wed, 9 Nov 2022 at 23:16, Bogdan Gavril @.***> wrote:

Ok, thanks @Camios https://github.com/Camios , we will need to investigate this. The Windows error code you mention is:

[image: image] https://user-images.githubusercontent.com/12273384/200839992-fbfb457b-8078-4cc1-bafb-7a2a63310168.png

I'm a little confused when you say IPublicClientApplication.GetAccountsAsync() returns 1 account. Normally this returns just the accounts in the cache. Do you mean that you interactively login with the domain account and this works fine, but then the silent auth fails?

— Reply to this email directly, view it on GitHub https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3792#issuecomment-1308738809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVOHUZ2X5ALX4LYFDPSI6LWHOP2VANCNFSM6AAAAAARZZ6SQM . You are receiving this because you were mentioned.Message ID: <AzureAD/microsoft-authentication-library-for-dotnet/issues/3792/1308738809 @github.com>

[Camios]

I checked and there is an existing token cache file for the service account. I backed it up, then removed the token cache and started the app (still under non-domain windows account while using runas the service account).

GetAccountsAsync is returning empty and the fallback is to use the current OS account. Which we pass to AcquireTokenSilent(scopes, account) and it gives the same MsalServiceException:

Microsoft.Identity.Client.MsalServiceException: 'Unknown Status: Unexpected
Error: 0xffffffff80070520
Context: Winrt exception was thrown during GetTokenSilently '(pii)'.
Tag: 0x2339e502 (error code -2147023584) (internal error code 590996738)'

Restarting the app and the account cache is still empty (expected) and I get the same exception. Suggesting the error isn't anything to do with the token cache.

So I tried logging in to windows as the service account and I can see that the account is also listed under "Emails & accounts" "Accounts used by other apps" and under "Access work or school" accounts. Makes me wonder if "Workplace Join" is a contributor.

I was able to successfully acquire a token logging by into windows using the service account and running the application. I ran the application from the service account window session, it used the OS account and it was able to silently acquire a token.

I then renamed the token cache folder again and went back to the non-domain account windows session, ran as the application as the service account, there's nothing in the account cache and now it is working !?!?!

I'm now trying to find ways to get it back to a broken state for replication.

[Camios]

So I went back to MSAL v4.45 (and token cache Microsoft.Identity.Client.Extensions.Msal v2.22), with the old WAM broker and logging into windows from the non-domain account and I'm getting the COMException again. Note: token account cache is empty so the account is OS account was used in the attempt.

[Camios]

Upgrading to MSAL v4.48 (and Microsoft.Identity.Client.Extensions.Msal v2.25) with old WAM broker still has the COMException

[bgavrilMS]

It is most likely a limitation of WAM, but I am happy to escalate it to the WAM folks. Would be good to understand the exact repro steps, perhaps using the current OS account.

1. What is the state of the windows machine ? You can get this via cmd dsregcmd /status
2. What accounts do you have on the machine?
3. What account are you logged into when you get the error?

[Camios]

I'll need to get back to you next week on this one

[Camios]

1. dsregcmd_clean.txt Taken from an elevated command prompt for the domain account..
2. Under "Email & Accounts": nothing. Under "Access work or school": "Connected to *** AD domain". Under Local Users: there some accounts
3. I'm using a non-admin, local user account to login into windows. I run a command prompt using "Run as administrator" which shows a dialog asking for an admin account. I supply a domain account (which is also an AAD account) which is in the local PC Administrators' group. I then run VS from that elevated command prompt, then debug the application. The command prompt, VS and the application under test are all running elevated as the domain account.

[Camios]

I tried a new local account for windows and a different domain account to "run-as" the elevated application and I'm getting the error in all versions MSAL and even with and without the broker preview. A difference with the WAM preview is it gives MSALServiceException vs the COMException from the "old" WAM broker.

Some out of the box testing: I tried logging into and out of windows with the domain account for once, then switching back to the local account to run the app to see if the domain account login puts a policy on the PC to make a difference but when I logged back in using the local account then "run-as" the app using domain account it still fails.

Next I tried logging in as the domain account and running the application - this (perhaps unsurprisingly) works and creates a token cache file.

I deleted the domain account msal token cache file and logged back in as the local account, tried to the app run as the domain account, but it fails again.

I logged into windows using the domain account, ran the application and left the msal cache file on the file systems. Logged in using the local account, ran the app as the domain account and this time the token was acquired silently (Based on cache rather than WAM I assume). This is unsurprising.

I can't seem to replicate a previous one-off success of using a local account to login to windows to run the app as the domain account without a pre-existing token cache file (makes me question if I'd actually ever done it).

[Camios]

@bgavrilMS can you please escalate to the WAM team if you haven't already?

[bgavrilMS]

I will follow up again, but they have suggested that some of the "run-as" operations don't work. I recommend you find another solution to test (this is for a test scenario no?), such as using AcquireTokenByUsernamePassword

[bgavrilMS]

@alextok - could you take a look at this WAM issue please?

[Camios]

@bgavrilMS FYI this wasn't for an auth test scenario. It just happened to be observed during the flow. Our application needs to run elevated so we can hit this issue in normal (non-test) scenarios.

[Camios]

@bgavrilMS you marked this as a duplicate of itself

[Camios]

@bgavrilMS trying again, why was this ticket closed as a duplicate of itself? I see it was also closed as "not planned", but without an explanation and I never heard from @alextok

[bgavrilMS]

Just to confirm - the same issue exists with new broker, right?

[bgavrilMS]

@MSamWils - can you confirm if "run as" scenarios are supported by MSAL C++ / msal_rutime / WAM?

[Camios]

Just to confirm - the same issue exists with new broker, right?

Yes although exception message is different https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3792#issuecomment-1308191007

[bgavrilMS]

@gladjohn, @MSamWils - is msal_runtime expected to fix this?

[MSamWils]

Hi @Camios, Apologize for the inconvenience. Unfortunately, "run as" is not supported in the broker flow. It's not related to MSAL but the issue is on the windows operating system itself.

[MSamWils]

Hi @Camios, can you please help explain in detail on your scenario why using "run as" is required? We would like to understand about the scenario better in order to prioritize the work to support "run as".

[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.

[gustavoaca1997]

Jumping in for sharing that my team is also having the WinRT-related error message while acquiring a token silently:

Unknown Status: Unexpected
Error: 0xffffffff80070520
Context: Winrt exception was thrown during GetTokenSilently '(pii)'.
Tag: 0x2339e502 (error code -2147023584) (internal error code 590996738)

[gustavoaca1997]

It seems the users having this exception are using type-5 sessions. Before using MSAL, we were passing Prompt.Never in this scenario. What's the equivalent options for this scenario? AcquireTokenSilent and Interactive are failing with the above error.

[bgavrilMS]

Run-As admin works. Run-As other users is not expected to work. Recommend moving this to the backlog for WAMv2.