Intune Primary Users - M365 Apps/Edge/OneDrive sign in issues

[CHiLL]

We noticed that all of our SCCM co-managed devices appearing in Intune had primary users associated and had issues communicating with Intune, which is problematic since Intune is managing updates via WufB. Company Portal also work correctly if the user logged is not the primary user.

 

I have removed the primary user from a bunch of machines to convert them to shared devices, which is what we did with our DFE Intune only (not SCCM) laptops, used at home by students and that worked for those devices.

 

However, we started getting reports shortly afterwards that users were being signed out of their apps, specifically their Microsoft apps, such as Word, PowerPoint, Excel, Edge, OneDrive, etc. So it seems that removing the primary user has reset the device's settings, including authentication information, even if the user logged in was not the primary user.

 

Users are having to manually sign into the apps and go through the enrol device dialogue box within Word/PowerPoint in order to access the app's features. We have had necessary GPOs in place that should do this automatically and silently (and have had for years, without anything being changed in those), so it must have something to do with the primary user change.

 

What are the necessary GPO settings to get this working as desired or am I missing something?

[georgeescott]

We’ve encountered something slightly similar, where if you delete a cached user (assuming this is the first time they’ve used the device) on Windows 11, the next time they sign in, none of the SSO policies work. So users have to manually sign in to OneDrive/Edge/M365 apps etc.

 

I wonder if some shared device policies have cleaned up cached logins or something? Or it’s a similar type of bug perhaps.

[CHiLL]

It appears that we had an issue with our Entra Connect Sync (Azure AD Connect), where it had lost it's entire configuration and needed setting up again from scratch. That has been done and it is syncing correctly.

 

However, office apps are not signing in users automatically. I can see that it is, kind of, but the apps aren't licensed and the users are prompted to sign in. At the top right of an app, such as Word, it will display the user's login details that it's pulled from Windows. For example, it will show "[email protected]", which is the local domain name. Whereas students log in with their M365 domain credentials, such as [email protected].

 

Seamless SSO is enabled in Entra Connect Sync and I've confirmed it's enabled within Entra Admin Center.

 

I can see that and confirm by a gpresult that the following settings are set and being applied:

 

Location: User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List
Value name: https://autologon.microsoftazuread-sso.com
Value (data): 1

Location: User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone
Value name: Allow updates to status bar via script
Value (data): Enabled

HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, “BlockAADWorkplaceJoin”=dword:00000001

 

I just don't know why it won't auto-sign in the user.

[5tu]

In your local AD, what is the primary suffix of your users set to? "@school.local" or "@school.council.sch.uk"

[CHiLL]

In your local AD, what is the primary suffix of your users set to? @school.local" or @school.council.sch.uk"

Of course of all the test users we have, I picked the only one that has @school.local set as the primary suffix! I changed that and it signed in automatically.

 

Since our users were signed out due to the original issue, it appears that despite the configuration for SSO being enabled, it doesn't apply at the first log on, but does from subsequent logons after the profile is cached, which is pretty much what @georgeescott described.