Mac users experience JAMFAAD Sign-in Errors within O365

wangl2
Contributor

Dear Forum Members,

I have been getting Sign-in errors for Mac users and I have no clue where to start for the troubleshooting. The configuration on the JAMF side looks solid. We use NoMAD and the error is not occurring at the OS sign-in.

Below are the errors I have been getting from AAD Sign-in section on Intune, and they are for the same user. Those errors all point to the JAMF Native MacOS Connector. The user experience is that they are constantly getting prompted to sign in to Microsoft when using O365 Apps on the Mac. The Microsoft Sign-in windows will just stuck on the page saying "Help us keep your device secure" with no errors. The App ID on this page also points to the same MacOS Connector, but Device State shows as: Unregistered. The same Mac device in Intune actually shows up as enrolled and compliant. Does that mean we need to re-register the device with Intune?

Thank you all very much!

Status
Interrupted
Sign-in error code
50097
Device Authentication Required - DeviceId -DeviceAltSecId claims are null OR no device corresponding to the device identifier exists.

Status
Interrupted
Sign-in error code
50058
Failure reason
The application tried to perform a silent sign in and the user could not be silently signed in. The application needs to start an interactive flow giving users an option to sign in. Contact app owner.

1 ACCEPTED SOLUTION

bwoods
Valued Contributor

@KRIECCO to fix this issue I usually have to remove the device from Azure/Intune Completely, completely remove/reinstall company portal, then re-register the device.

View solution in original post

9 REPLIES 9

bwoods
Valued Contributor

@wangl2 I'm seeing this behavior in my environment as well. It usually occurs after a password reset...other times it's just random. Has Jamf given you any more information about this issue?

KRIECCO
Contributor

What if you look up the computer in jamf and check user accounts and scroll to the right. Can you see the azure is active - or anther state ?

Stevie
Contributor

Microsoft did have an issue and posted this health status message.

https://admin.microsoft.com/adminportal/home#/servicehealth?message=IT217562

bwoods
Valued Contributor

@KRIECCO to fix this issue I usually have to remove the device from Azure/Intune Completely, completely remove/reinstall company portal, then re-register the device.

@bwoods how to uninstall company portal? is there any way you know or remove .app from /Applications folder to trash. Please let me know.

wangl2
Contributor

Thanks Guys. In the end, I delete the device object from both Intune and Azure. User would have to enroll again using Company Portal and it fixes the problem. I still don't understand why it happens in the first place. It always happen when user are forced to change the password at the login screen, when the password is already expired. Then once user updated the password, signed to the desktop, and tried to change the password again from NoMAD. This part is where it wouldn't work, and NoMAD can't change or update the password. This is how it started for every single problem I have seen so far.

bwoods
Valued Contributor

@wangl2 I opened a case with Microsoft and Jamf. The issue seems to stem from AD bound macs and the Jamf AAD keychain. For some reason, AD bound macs can't seem to update this keychain properly, causing the link to Intune to break. I've noticed that this issue has stopped happening on machines that use local accounts and Jamf Connect. The Jamf AAD keychain can now update properly.

I think NoMAD should be able to properly update the keychain as long as the machine is getting kerberos tickets and the sync preference is turned on. With everyone on quarantine, I suggest that your users only reset through NoMad while connected to the VPN as it ensures a connection to your on prem AD server.

Hope this helps.

bwoods
Valued Contributor

Upvote this: JamfAAD should use web view instead of | Jamf Nation Feature Requests. Complain to your customer success reps as well.

dvasquez
Valued Contributor

That information is key. Thank you for sharing! I have moved into testing to deploying the new 

"useWKWebView" .plist in a configuration profile.

I really hope this helps with the need to re-authenticate from time to time.