2

Question

Is there a way to purge locally cached files and/or registry entries on Windows 10 that assist with making the single sign-on modern authentication experience with Outlook M365 work, where once this data is purged, the app will have to prompt for the modern authentication again? (I know it'll store this data locally again)

Or

What options are available to assist with keeping M365 modern authentication enabled at the Exchange Online/Azure AD level, but force basic authentication on specific devices regardless of the user that signs onto it with Outlook M365 desktop app?

Ultimate Goal: Need for Outlook M365 desktop app to prompt for password for whatever profile is picked at launch time on specific computers regardless of the Outlook user profile picked and even if that profile account authenticated successfully with modern authentication on a previous launch (even if 3 minutes ago for example).

Things tried

  • Both disabling Cached Exchange Mode, wiping all local cache files and enabling it too (separate times)

  • Toggling the User identification | Always prompt for login credentials options via registry settings in all cached mode enabled or disable scenarios to all applicable values possible with each configuration

    enter image description here

  • Purging all credentials from Credential Manager

  • Slews of Googling with a few posts that haven't helped either

    • Can't disable saved passwords Outlook

    • How do I make Outlook prompt for a password

    • There an Office GPO setting "Prevent saving credentials for Basic Authentication policy", but setting it won't apply since modern authentication is always used. I'm not finding any equivalent options here for modern authentication though.

      enter image description here

    • Read about Primary Refresh Token and thought about figuring out where this token is located on the local machine and a solution at that level to wipe, prevent saving, etc. to see if that'd help but seems a bit brute force to start

    • Read about conditional access policies using Common identity and device access policies but not sure if this could handle it or if there's a simpler way before diving into this

Requirements/Issues

  • To use Outlook M365 desktop app and not be required to use Outlook on the web \ OWA

  • To have any Outlook M365 desktop app profile selected and always have it prompt to authenticate

    • If user1 profile previously authenticated using the modern auth, user2 can walk up even after a PC reboot and pick user1 profile, and it allows them access without a password prompt

  • Need to keep modern authentication enabled Azure AD/Exchange Online wise regardless so users on their own machines signed on with their own Windows profiles still works for Seamless Single Sign-on.

  • Prefer to not enable MFA\2FA on the Azure AD accounts to as a solution and just have it use modern authentication or basic authentication.

  • Using Basic Authentication on these machines for Outlook to prompt for credential is NOT a requirement if there's a way to do this with modern authentication.

Environment specifics

  • Windows 10 Enterprise (20H2)
    • The Windows user account auto logs onto Windows with an on premise AD account that does not have an Azure AD license assigned to it but it does Azure AD sync. When the user walks up, they do not need to log into Windows and just pick their Outlook profile to access their email.
  • Azure AD M365 licensed accounts do not log into Windows on these machines
  • Outlook M365 (M365 Apps for Enterprise)
    • Azure AD account will connect to Exchange Online mailbox by building a profile and authenticate when selected
    • Could be 5 different Azure AD accounts/Exchange Online mailboxes that need to connect at different times in a day
  • Exchange Online (mailbox connections)
  • Azure AD sync'd from on premise AD via Azure AD Connect
    • Pass the hash sync configuration
Improve this question
0

2 Answers 2

Reset to default
1
+50

The following is the summary of the above discussion.

Outlook M365 desktop app prompts for password and the classical methods for Outlook do not work for stopping it.

Further research has shown that while Outlook is accepting the password, it's updating a .tbres file in the profile directory AppData\Local\Microsoft\Token Broker\Cache.

Token Broker is a Windows process that helps manage permissions for apps and the Windows Store. It is implemented by the Windows service of Web Account Manager, described as:

This service is used by Web Account Manager to provide single-sign-on to apps and services.

This means that Outlook M365 desktop app uses the Token Broker process to store its credentials, which explains why the usual remedies do not work. The .tbres files are usually cited as containing (among others) credential information.

Outlook prompted for password when the poster purged <User>\AppData\Local\Microsoft\TokenBroker\Cache, although this stopped working after a reboot.

My last recommendation was to to automate deleting the .tbres file that was modified by Outlook, best done just before launching Outlook.

Improve this answer
0

Important: This applies only in a case where the logged in Windows User account does not have an M365 license, SSO doesn't work implicitly, and all M365 licensed users log onto their M365 accounts via the M365 Desktop Apps' Sign in functionality.

  1. Sign onto Windows with a user account profile that does not have an M365 license assigned to it so it cannot authenticate if it tried.

  2. Completely disable Outlook M365 Cached Exchange Mode for the logged on Windows user account profile.

    • Use Registry Editor to add a DWORD type named NoOST under HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\16.0\Outlook\OST with a value of 2

  3. Now enable a shared computer activation for Microsoft 365 Apps configuration on the machine(s).

    • Use Registry Editor to add a String value (Reg_SZ) of SharedComputerLicensing with a setting of 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration.

  4. To ensure an M365 account is not accessible without a password, the M365 account must always log out of the M365 Office desktop app account before walking away.

    Outlook: File | Office Account | Sign Out

    Word\Excel: File | Account | Sign Out

  5. Logging out of the M365 account using Word, Excel, or Outlook also logs out of all other M365 Office desktop apps.

Bonus findings

  1. Authenticating to Teams is independent from the other M365 Desktop Apps that are logged on, so log out of and into Teams explicitly, and in conjunction with, the other M365 Desktop Apps.

  2. Chrome and Edge web browsers will also need to be signed onto and out of once for each of those browsers independently and as individual entities in this configuration.

So based on all the language as per Microsoft on the Overview of shared computer activation for Microsoft 365 Apps post regarding the licensing token and activation, I'll sum up and quote few key points that apply.

In some cases, Microsoft 365 Apps prompts the user to provide the information. For example, the user might see the Activate Office dialog box.

I believe in this specific scenario this applies and it's in all cases rather than some here.

If the user is licensed for Microsoft 365 Apps, a licensing token is stored on the computer in the user's profile folder, and Microsoft 365 Apps is activated

This also seems to be true in this scenario however that token is not retain in this scenario to allow subsequent authentication to M365 to authenticate without a password once logged out.

These steps are repeated for each user who logs on to the shared computer. Each user gets a unique licensing token. Just because one user activates Microsoft 365 Apps on the computer doesn't mean Microsoft 365 Apps is activated for all other users who log on to the computer.

When you log onto only the M365 desktop apps in this configuration, this applies per app or M365 web authenticated session without retaining the token after logging out and thus always requiring a password for subsequent authentication attempts.

Supporting Resources

Improve this answer
2
  • In case this helps someone looking for a solution, this is what I have. I don't think I'm leaving anything else relevant out but I'll update if I determine otherwise later or figure out anything new or different.
    – Vomit IT - Chunky Mess Style
    Commented Oct 19, 2021 at 2:33
  • Final solution was to not use this configuration and just have the person sign onto the workstation as themselves. No auto login computer configurations with the way it works with M365 and Azure AD. The whole user-experience process changed with this specific workstation configuration ultimately to not do this, it was buggy too back then with the non-Outlook Office cache overlap, etc. iirc.
    – Vomit IT - Chunky Mess Style
    Commented Sep 15, 2023 at 18:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .