Multiple MFA and Sign-In Prompts in VDI with FSLogix

Hi Andrew Sammut,

The recurring authentication failures you are seeing point to a cryptographic mismatch with the Windows Web Account Manager. The error code -894893981 means a required cryptographic keyset does not exist on the current machine. The authentication tokens stored inside the AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy and AppData\Local\Microsoft\TokenBroker directories are encrypted using DPAPI, which binds them specifically to the hardware of the virtual machine where they were initially generated. When an FSLogix profile roams to a new virtual machine in your non-persistent pool, the system cannot decrypt these roamed tokens because the new hardware does not match the original DPAPI encryption key, resulting in the failure.

Simply removing these paths from the inclusions section of your redirections.xml file does not resolve the issue because FSLogix captures the entire AppData\Local directory by default. To successfully stop these folders from roaming and breaking the authentication flow, you must explicitly define both the BrokerPlugin and TokenBroker paths inside the excludes section of your XML configuration. Furthermore, because the corrupted, hardware-mismatched token directories are already permanently embedded inside your users' existing FSLogix profile containers, this XML change will not retroactively fix them. You will need to manually delete those specific AppData paths from the affected users' virtual disks while they are logged off or completely reset their FSLogix profiles so they can generate fresh tokens upon their next login.

To address the initial double MFA prompts for Outlook and Teams, you must ensure your non-persistent virtual machines are correctly configured as Microsoft Entra Joined or Hybrid Microsoft Entra Joined. When device identity is properly established, Windows negotiates a Primary Refresh Token during the initial desktop login sequence. This token acts as a master key that silently and natively authenticates the user to all Microsoft 365 applications, thereby eliminating the need for secondary prompts and stabilizing the entire authentication pipeline across newly provisioned sessions.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

Andrew Sammut Thanks for the update and confirming the Hybrid Entra Join status of your non-persistent virtual desktops. The reason your users are still experiencing double authentication prompts for Outlook and Teams comes down to how the Primary Refresh Token interacts with your organization's Conditional Access policies. When a user logs into a Hybrid Entra Joined machine using just a standard Active Directory username and password, Windows successfully negotiates a Primary Refresh Token in the background. However, that specific token only carries a single-factor authentication claim because only a password was used to access the desktop.

When Outlook and Teams automatically launch, they silently present this single-factor token to Entra ID to access Exchange Online and SharePoint. Your Conditional Access policies intercept this request, recognize that the mandatory multi-factor authentication claim is missing from the token, and immediately force the interactive prompts to satisfy your security baseline. You can verify this exact state by opening a command prompt on an affected virtual desktop as the user and running the command dsregcmd /status to review the User State section. You will likely see that the Primary Refresh Token is present, but the MFA property is explicitly set to NO.

To eliminate these application-level prompts and achieve seamless single sign-on, the multi-factor authentication requirement must be satisfied at the very beginning of the session. You must inject an MFA claim into the Primary Refresh Token during the initial Windows desktop logon sequence. This is typically accomplished by implementing strong authentication methods at the lock screen, such as Windows Hello for Business or FIDO2 security keys. Alternatively, if you are using a federated environment, you can configure your infrastructure like Active Directory Federation Services to pass a valid MFA claim directly to Entra ID when the desktop session is first established.

VP

Hi Andrew Sammut,

How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VP