I won’t take credit for discovering this, one of my colleagues found this out. 🙂 But I had no idea this settings has such a side effect, so I’ll blog about it.
We are switching to Intune at work for managing iOS and Android devices (the first six months of my life this year was about setting up things in Intune, laying the framework for things). One of the issues we discovered is that when using multi-identity apps such as Edge, Outlook, etc. the app protection policies we apply to disable copy-paste apply when the user is in their personal identity too.
That shouldn’t be happening. According to the docs (highlight mine):
Multi-identity support allows an app to support multiple audiences. These audiences are both “corporate” users and “personal” users. Work and school accounts are used by “corporate” audiences, whereas personal accounts would be used for consumer audiences, such as Microsoft 365 (Office) users. An app that supports multi-identity can be released publicly, where app protection policies apply only when the app is used in the work and school (“corporate”) context. Multi-identity support uses the Intune SDK to only apply app protection policies to the work or school account signed into the app. If a personal account is signed into the app, the data is untouched. App protection policies can be used to prevent the transfer of work or school account data to personal accounts within the multi-identity app, personal accounts within other apps, or personal apps.
So if an app is written properly, when you switch from a work to personal account on that app, the app protection policies shouldn’t apply. And since Edge, Outlook, etc. are written by Microsoft it stands to reason they would have written it properly to support this feature?
But it wasn’t happening in our experience. Once a user signed in to the app, it was protected even when they switched accounts.
There’s a bunch of documents – this and this – but neither helped us. Turns out the setting that made a different was a Device Configuration setting “Allow copy/paste to be affected by managed open-in”.
So…. if this is set to Yes (which it is in our case), apparently it only makes a difference if “Block viewing non-corporate documents in corporate apps” and/or “Block viewing corporate documents in unmanaged apps” are set to Yes. In our case “Block viewing corporate documents in unmanaged apps” was set to Yes… which doh, is what you want! I don’t want my corporate documents being opened in unmanaged apps.
And yet, “Allow copy/paste to be affected by managed open-in” has a side effect. If we have an app protection policy applying to the apps, and that has “Restrict cut, copy, and paste between other apps” enabled (set to “Policy managed apps with paste in” in our case – which basically means you can copy out to app protection managed apps only, but you can copy in from any app) -and you’d expect this app protection policy to only apply to the app when the signed-in identity is the work identity – the mix of that setting plus “Allow copy/paste to be affected by managed open-in” means that the app protection policy copy-paste restriction applies even when signed in with a personal account.
My colleague discovered this by turning off “Allow copy/paste to be affected by managed open-in” and realizing that the issue is now gone.
Update (29th Nov 2024): Re-reading this post today, I realized something.
The “Block viewing corporate documents in unmanaged apps” is an app level setting. It doesn’t know anything about the user who is signed into the app, it only looks at whether the app is managed or not. And what defines a managed app – it comes down to whether it is pushed out via Intune or not. So, for instance, Chrome pushed out via Intune is considered a managed app, irrespective of whether I have any app protection policies applying to Chrome or not.
In this context, “Allow copy/paste to be affected by managed open-in” basically translates to “Should we allow copy/paste between managed and unmanaged app” – irrespective of who’s signed into the app, because we don’t care about that. And that’s why when this setting is on copy paste is blocked always.
The correct approach to take is to keep this setting off, and depend upon app protection instead as that only applies when a user is signed into the work profile. Solely depending on app protection has a limitation in that the app must support it, else copy paste will be allowed. For instance, we use Mimecast, and it doesn’t support app protection policies; so by setting “Allow copy/paste to be affected by managed open-in” to off we indirectly allow someone to copy a work email from Mimecast to their personal notes.