JamfAAD (Intune) on Macs - getting weird pop-ups

I get something similar. It looks like yours is using a custom page. Unless I'm mistaking this for something else. It pops up constantly and signing in doesn't make it go away. Registration works. We haven't rolled it out to all Macs yet thankfully. This would be really annoying for users. No solution yet for my issue.

we already discussed this topic in this thread.
btw. after the support told me that they haven't seen this pop-up I opened a CSM ticket with jamf and told them about the missing documentation from jamf side. There is in fact a Microsoft documentation about this topic the referenced to, but in my opinion there needs to be a jamf documentation also!

Is this a symptom of the iOS Conditional Access being added? I have a user that keeps getting this pop up, but I have not seen it myself. This thread popped up while I was submitting a ticket

@hdsreid it does not have anything to do with iOS Device Compliance. That is a separate set of Enterprise Apps that do the server side (Graph API) and client side (Authenticator app) call outs.

@whitebeer is correct that the reason this is taking place is due to the change in the MSAL library that is used for authentication. In Jamf Pro v10.24 and up the library was updated to v1.1.2. On Jamf Pro v10.21 - v10.23 MSAL v1.0.7 was in use and it did not require the ASWebAuthenticationSession to be launched (the prompt that macOS is giving to redirect to Microsoft for login).

The pop ups ARE expected in the case of say a new registration where a token does not already exist for authentication, and they would be expected in the case of a password change or session expiration (Global default from AAD is 14 days out of box but can be changed). In all other scenarios (EX: Monday the 4th to Tuesday the 4th where the Mac was on and the user used it both days and did not change their password and the session was not expired) it should not prompt.

What I am working to determine is why for some macOS clients does the silent token auth. that MSAL does on daily checks (that the jamfAAD Launch Agent does (more on that here)) fail to stay silent when it should be.

In a number of logs I have been looking over we can see examples of this.

A good auth. that stays silent:

info    2020-10-22 18:08:56.880139 -0400    JamfAAD TID=2884467 MSAL 1.1.2 Mac 10.15.7 [2020-10-22 22:08:56 - REDACTED ID] [MSAL] Beginning silent flow.
info    2020-10-22 18:08:57.394046 -0400    JamfAAD TID=2884479 MSAL 1.1.2 Mac 10.15.7 [2020-10-22 22:08:57 - REDACTED ID] [MSAL] Silent flow finished. Result (not-null), error: 0 error domain: (null)
default 2020-10-22 18:08:57.394774 -0400    JamfAAD AAD ID acquired for macOS user account bob.lutz
info    2020-10-22 18:08:57.394824 -0400    JamfAAD Sending AAD ID to jamf daemon

A bad auth. that then gets in your face:

info    2020-10-22 20:09:02.570714 -0400    JamfAAD TID=3027791 MSAL 1.1.2 Mac 10.15.7 [2020-10-23 00:09:02 - REDACTED ID] [MSAL] Silent flow finished. Result (null), error: -1200 error domain: NSURLErrorDomain
info    2020-10-22 20:09:02.654443 -0400    JamfAAD TID=3027778 MSAL 1.1.2 Mac 10.15.7 [2020-10-23 00:09:02 - REDACTED ID] [MSAL] Beginning interactive flow.

@mcantwell , @hdsreid , and @dnorman if you have examples that you can pull a full sudo sysdiagnose -f ~/Desktop archive from if you want to open a Support case and upload the logs with a rough time (to speed up Console filtering) of when the prompt came up they could be helpful in the investigation.

An update for anyone following this thread. We have been working with Microsoft's MSAL team on these errors we are seeing.

The large majority are NSURL error of network failures ranging from timeout to DNS name resolution. When the MSAL silent token authentication in the background fails jamfAAD is taking that MSAL exit error and falling back to an interactive authentication the same as it would for a missing token or expired session before. The catch being that now with the new ASWebAuthenticationSession that has to be launched (the prompt that macOS is giving to redirect to Microsoft for login) and is very in the users face.

From the several dozen sets of logs from devices I have looked at ~85% of the time it is down to a network failure. The new WebKit based authentication must just be more temperamental than the previous style in old MSAL and ADAL. Also, as we found some end user clients that are work from home on high latency networks (satellite internet) seem more affected.

Examples:

info    2020-10-22 20:09:02.570714 -0400   JamfAAD  TID=3027791 MSAL 1.1.2 Mac 10.15.7 [2020-10-23 00:09:02 - REDACTED] [MSAL] Silent flow finished. Result (null), error: -1200 error domain: NSURLErrorDomain

error 2020-11-01 22:52:44.806296 +0530 JamfAAD TID=546691 MSAL 1.1.2 Mac 10.15.7 [2020-11-01 17:22:44 - REDACTED] [MSAL] acquireTokenSilent returning with error: (NSURLErrorDomain, -1001) Masked(not-null)
fault 2020-11-01 22:52:44.806324 +0530 JamfAAD Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={NSLocalizedDescription=The request timed out., NSErrorFailingURLStringKey=https://login.microsoftonline.com/REDACTED/oauth2/v2.0/token, NSErrorFailingURLKey=https://login.microsoftonline.com/REDACTED/oauth2/v2.0/token, _kCFStreamErrorDomainKey=4, _kCFStreamErrorCodeKey=-2102, NSUnderlyingError=0x7fd1d2a0c6b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}}

info 2020-10-30 07:51:39.153058 -0400 JamfAAD TID=5795 MSAL 1.1.2 Mac 10.15.7 [2020-10-30 11:51:39 - REDACTED] [MSAL] Silent flow finished. Result (null), error: -1009 error domain: NSURLErrorDomain
fault 2020-10-30 07:51:39.153078 -0400 JamfAAD The Internet connection appears to be offline.

We have seen some cases where the token is missing. That is more concerning as there is not a reason for that. Note: MSAL will not jettison a token after that failed auth. or dismissed auth. per Microsoft. Being more rare ~15% or less of the cases it has been hard to get logs (where we have known good then the token disappearing; they all start well after that point so far). So root cause investigation on that is still on going with Jamf and Microsoft.

Examples:

info 2020-10-29 11:43:07.723875 -0500 JamfAAD TID=6332128 MSAL 1.1.2 Mac 10.15.7 [2020-10-29 16:43:07 - REDACTED] [MSAL] Silent flow finished. Result (null), error: -51115 error domain: MSIDErrorDomain

error 2020-10-29 11:43:07.723922 -0500 JamfAAD TID=6332128 MSAL 1.1.2 Mac 10.15.7 [2020-10-29 16:43:07 - REDACTED] [MSAL] acquireTokenSilent returning with error: (MSALErrorDomain, -50002) Masked(not-null)

For the network issues we are working on a fix that we think should help resolve the NSURL errors by building in logic for a retry via a configurable flag in jamfAAD so that we do not need MSAL to start the retry after it gets the failure jamfAAD can just force another since newer MSAL is not behaving like MSAL v1.0.7 and older. Work on that is ongoing, but the thinking is if we can give MSAL several attempts at reaching out we might have better luck.

Any update on this? Some of our users, including myself, is getting the JamfAAD popup quite often. We are on stable, high speed, networks. Macos 10.15.7, Jamf Pro 25

@bouvet do you have a case open? If not could you open one and send in logs? I would like to look at a full sysdiagnose from an affected Mac like that. We are still working with Microsoft on the missing token situation that we see on Macs with a strong network. The missing token causes the same end user impact but we think has a very different cause within MSAL itself possibly. Getting examples has been hard as it is much less pervasive, and or we get the example after the token is gone so we just know it is missing not what caused it.
Thanks!

I just opened a case with two logs from two different computers. Thank you for taking the time to look into this!

Ho @bryce , any updates? We created a case and have 10 days left until rollout... Any workaround, recommendation what to do when the popup appears? Can we just cancel the popup or do the user have to login?
Thanks!!!

Great work so far from your end!!!!
I see this behaviour on my Macs in different environments too. That's especially the case, when i close my MacBook in the evening and opening it at the morning. Then i have almost every day this annoying popup.

@as_devops so right now we are working on testing the change in the retry logic to get it out production after that is finalized.

The user could cancel the pop-up, but keep in mind the jamfAAD agent will just ask again in 2 hours when the agent gets called and reads the last token gather time. Now if the network is stable then the SilentAuth. might just work.

I would verify in your logs @as_devops that the silent failure and subsequent interactive prompt was due to a network, and not MSALErrorDomain, -50002 like in the examples I posted above. If that is the case the token is missing and the silent pull will never work, and the user has to do the prompt at least once. We have yet to see a scenario where the failure (outside of network (that the retry logic should help with)) comes back after that.

@LangStefan I would 98% bet that your network at wake is part of that. We have seen that and the retry logic should help with that. If you have logs I would look for some of the examples above to verify that.

@bryce Sounds like you has a lot of knowledge on this. I have for really long time and actually close to always since we started used conditional access, that clients very random a failing conditional access even the client in jamf/intune looks compliant. Only in Azure the device typical has not have any activity for long time, that is how I nearly always can guess when the next will fail if it has been several weeks since last activity, even the client in jamf and intune is looking fine. But according to microsoft, the lack of activity in azure, has nothing to do with the issue as conditional access does not look at any activity but only on compliance. But the device looks compliant in intune, so why it fails is the question.

I don´t know if that describe the issue you also are working on

We are also having this issue, running on JSS 10.24.2, here is the ticket JAMF-1873417 that has a Sysdiagnose from a machine that running 11.x that is getting the popup.

@jameson So that is a separate issue that I have been working on. The thing I would look for in that case is Azure AD side in the sign-in logs. Find the point of the failed authentication that tips you off to the issue. If we look before the failures we can see a Interrupted message. This is the first evidence of this issue. The TL;DR is that the Device ID is not provided at the point of sign in. It will have the Sign-in error code of 50097. The reason for that being again that the Device Info is blank, and if that is blank the CA engine can not assess what device it is and compare that with the data the Jamf Pro had sent as part of the integration as that is its record ID. If we look further on the actual Failure that follows that we have another Sign-in error code of 530003.

It does not seem to be down to any action with jamfAAD like we are talking about at the root of this thread, or the server side data post or compliance engine within Azure/MEM. But for some reason either the login.keychain is invalidating the WPJ key ACLs used by the device side apps to say This is my ID this is who I am please give me access if this device is compliant in your records. That fails if the ID is not given. It seems to be either that or the request for the sign-in does not ask for that. It is not clear and I have not been able to replicate this on demand ever. If you have a device that falls into that state we need to look into that with AppleCare Enterprise and Microsoft as a team since the data is across all three.

Just an FYI the Jamf Pro version with the new MSAL above is out now:
https://docs.jamf.com/10.26.1/jamf-pro/release-notes/What's_New_in_This_Release.html

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

@bryce Have you ever resolved this in your organization?  Seems like you have the most knowledge on this topic.

Here is a script that I whipped up. It gets around the PI bug with the blank Safari page. All of the Macs in my environment have Chrome set as their default browser during DEP and use Chrome for Azure Device Registration. Only 6 out of 353 Macs have had this issue in my environment. 62 other Macs that were migrated from another organization work fine, just those 6 had a problem. Those 68 Macs were done via User Initiated Enrollment, as we did not have their serial numbers absorbed into Apple Business Manager prior to the migration. 

These Keychain keys were mentioned somewhere in another thread. 

Sadly 10.26 was only good for so long.  We have since upgrade to 10.32 and are facing the problem more often than not now and it seems to impact our executive office more than anyone.  I have a case open with JAMF support and hope to have a resolution. 
Example of errors which match very close to @bryce 

This article from Travelling Tech Guy might help