Multiple MFA and Sign-In Prompts in VDI with FSLogix

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

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

The repeated MFA prompts and intermittent failures in a non‑persistent Windows 11 VDI with FSLogix are consistent with how Microsoft Entra ID authentication and FSLogix profile roaming interact.

Key points from the documented behavior:

1. PRT (Primary Refresh Token) and device join state
   • For the best SSO and MFA experience, VMs should be Microsoft Entra joined or Hybrid Microsoft Entra joined.
   • When the VM is Entra joined/Hybrid joined, a PRT is created at sign‑in and is then used by Outlook, Teams, OneDrive, and other Microsoft 365 apps to authenticate silently.
   • Standard domain‑joined VMs rely on the Microsoft Entra ID plug‑in instead of a PRT, which leads to repeated authentication prompts at every sign‑in for Microsoft 365 apps.
2. FSLogix and Entra broker data
   • Starting with FSLogix 2210 (2.9.8361.52326) and later, FSLogix no longer roams the following locations as part of the user profile:
     • %USERPROFILE%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
     • %USERPROFILE%\AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
     • %USERPROFILE%\AppData\Local\Microsoft\TokenBroker
   • These locations are directly related to Microsoft Entra ID broker and token data. If they are not handled correctly in a non‑persistent environment, users can be forced to re‑authenticate frequently and may see failures when tokens are refreshed after long sessions.
3. Recommended FSLogix configuration
   • Install the latest FSLogix version.
   • Configure the RoamIdentity setting (via registry or Group Policy) and set it to 1 so that identity‑related data is roamed correctly with the FSLogix profile.
   • This is the supported way to handle Entra ID broker/token data; manually including or excluding those folders in redirections.xml is not required and can be unreliable.
4. Session lifetime and re‑authentication
   • Microsoft Entra ID uses a default rolling 90‑day sign‑in frequency and separate controls for MFA re‑authentication.
   • When policy or token conditions require a fresh sign‑in (for example, after a long‑running session, device state changes, or policy evaluation), users will be prompted again, which is expected.
   • However, with non‑persistent VDI and missing/incorrect roaming of identity data, these prompts can occur more often and may fail, as seen in the error dialog.

Practical remediation steps based on the above:

1. Ensure the VDI VMs are Microsoft Entra joined or Hybrid Entra joined, not only domain‑joined, so that users obtain a PRT at sign‑in.
2. Upgrade FSLogix to the latest release.
3. Enable RoamIdentity=1 (registry or Group Policy) instead of relying on custom redirections.xml entries for the AAD Broker and TokenBroker paths.
4. After applying these changes, test with a new user session to confirm that Outlook and Teams no longer prompt for MFA on every sign‑in and that long‑running sessions can refresh authentication without error.

References:

• Known Issues
• Reauthentication prompts and session lifetime for Microsoft Entra multifactor authentication