MO688912 - Jamf Reset SSO iOS 17 not signing out

[SteveS]

"We've detected a recent WebKit update which may impact Enterprise Single Sign On (SSO) for Microsoft 365 services" - Microsoft

I think we are running into an issue related to this and wondering if others are as well. We have iphones setup as shared devices using jamf setup and jamf reset. We do a soft reset between users since you still have to register the device between full resets (unless someone has a way to skip that requirement)

When a user resets it is keeping the prior login active on Epic rover. Before it was clearing the token, but we are seeing sessions remaining I think on iOS 17 devices.

[mikegetchell]

We are getting to integrate single sign-on with epic Rover. Sounds like you have the same set up in mind that we intend to use. About to engage with epic, any additional tips?

[SteveS]

There is a property you need to set in the epic application to tie the sam account name to the user record for epic. This was a challenge for as I think the number of people that understood it at the time was low and the directions were non-existant.  

[Nate-Nielsen]

Same as @mikegetchell, we are actively testing this solution in our environment (Jamf Setup + Reset Single Login w/ Epic Rover and Haiku) but haven't had any feedback regarding stuck sessions just yet. Will keep my eye out and respond here if I can identify anything.

[mikegetchell]

I think we are even looking at Return to Service as a better option than Jamf Reset (soft reset) at this moment.

[Nate-Nielsen]

@mikegetchell - I'll have to look into that as a potential alternative. We already have some apps that we won't (or can't) set up SSO with so I have to have those apps uninstall and then reinstall from reset to setup. Not sure if I like that option best or not.

[SteveS]

So one challenge is that we are using entra for authentication and that requires the device be registered in entra. This requires a user with cloud device administrator rights to log onto the device microsoft authenticator to register. This is not as of yet automated for MDM's other than intune as last I knew. So a full device wipe will break that process for now.

[mikegetchell]

The cloud device admin is no longer a requirement, I thought.  We just put Authenticator into Shared Device Mode in the Jamf deployment of Authenticator.  
<dict>
<key>sharedDeviceMode</key>
<true/>
</dict>

We use Setup for role selection in Azure for the initial login. We are still working with out other teams to establish how we are setting up the Epic side for the integration.

[SteveS]

That dict config is required already. But I still cannot bypass the cloud device admin registration step unless there is further config I am missing?

[Nate-Nielsen]

@SteveS + @mikegetchell -

I've actually noticed this stored credential behavior now. I was able to replicate it.

During the Jamf Setup login step it sometimes asks us a second time to enter credentials (not consistent), at which point it will first ask you to select the account you just attempted to login with once OR you can choose "Use another account".  In an odd scenario where someone attempts to login once, but stops when prompted a second time and hands off, or leaves the phone, someone else can come along and select "User another account" and proceed to complete the Jamf Setup login process.

What happens is that the person who logged in at the second prompt suddenly has their credentials stored on the device (and yes in Epic Rover if using SSO). At this point, when resetting the phone using Jamf Reset it does NOT clear the credentials for the person that logged in at the second prompt, but only for the person who first attempted to login. This means that unless the person who logged in at the second prompt, logs in AGAIN on that phone and initiates another reset AFTER a fresh reset, their credentials will be remembered in Epic Rover (at the very least) if not other apps that remember SSO indefinitely. We had at least one scenario where a nurse's credentials were stored in Epic Rover for over a month and only because they never used the phone in that span. This same phone went through Setup / Resets with about 32 other users before someone finally called it out as something they noticed.

I could only ever replicate this behavior when using a completely different user account when encountering the second credentials prompt during Jamf Setup login. When selecting "User another account" and entering the same credentials, it did not store that accounts credentials, likely because that's the account I began logging in with in the first place.

Suffice to say, we aren't moving forward with this solution and likely looking at Jamf Return To Service and not leveraging SSO at all