JamfAAD - Issue

[asidhu]

Hi All,

One of my user is getting the below pop up and after clicking on Get App it is redirecting to a weird broken link. This user is already registered in Intune/Azure AD and it just randomly started to happen. I am mostly curious about the link. Any ideas where this is coming from?

[blockcham]

@asidhu , @Levi_ all my eyes are on v92 of Chrome right now which is slated for July 20
https://www.chromestatus.com/features/schedule
we'll see how it goes once that is released.

[bryce]

@asidhu sorry I have been eye watering-ly busy, but yes @blockcham has it right. Keep your eye peeled for the July 20 drop. The fact that it work in Chrome and Edge Canary this early point to a good next step but I would not recommend pushing that the devices in production now per Google and MSFTs guidance on that.

[bwoods]

Fun stuff.

[FritzsCorner]

So we have been instructing our users to have Safari set as the default browser during enrollment which seemed to have worked for awhile. However, many of these users have switched back to Chrome or Edge after the process and just recently started seeing the prompts again after changing their password.  Once they switched back to Safari as the default they weren't getting the prompts any longer.   Is this in line with what several of you are seeing as well?  

[ravisgupta]

yesterday MS released 91.0.864.71 version for Edge, works fine, but is this the latest version that supports setting the keys? I am asking for scoping purposes, creating a smart group  for this version and above as previous versions of Edge crashed if Info.plist was edited. 

[blockcham]

@bryce @FritzsCorner @asidhu @Levi_  I just updated to Chrome v92 and was able to successfully register with Intune perfect as intended.  Could others give it a try and let me know how it goes?  I'd like to report the results back to Google, thanks.

[blockcham]

@Cayde-6 Looks like the Edge release schedule is a few days behind Chrome's, it appears slated for the "Week of 22-Jul-2021"
https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-release-schedule

[Levi_]

Hey Blockcham,

I've run this on both my test machines and it appeared to have gone through, I am still giving Azure some time to update if the registration was successful, as you know Azure takes time..I'll post back with what I get. I haven't made any modifications to the .plists either. 

One strange thing that I always see happen though no matter the browser is that when you complete the sign-in through the company portal two login windows will launch for Chrome, Safari, Edge. Am I the only one seeing the two login windows launch every time?

Edit: Fastest update here, it did register successfully with the latest version of Chrome.

[blockcham]

Azure can take some time, we’re experiencing that for a few users as well. 

As for the two windows showing up I’m experiencing that as well. This only happens if Chrome is not opened. If you have Chrome opened and then attempt a registration only one window will show. I’ll report this up to Google. 

[ravisgupta]

Chromev91  and  v92 both are breaking after a reboot if Info.plist is edited with ASWebAuth IsSupported key set to False (No), have to set it back to Yes.

Also on setting the value to False, Desktop firewall prompts!!.

            

I have to set the key back to Yes to make chrome work again, same has been the experience with Edge v91.

just running these:

#Set Chrome to not take over ASWebAuth:

/usr/libexec/PlistBuddy -c "set :ASWebAuthenticationSessionWebBrowserSupportCapabilities:IsSupported false" /Applications/Google\ Chrome.app/Contents/Info.plist
#Set Edge to not take over ASWebAuth:

/usr/libexec/PlistBuddy -c "set :ASWebAuthenticationSessionWebBrowserSupportCapabilities:IsSupported false" /Applications/Microsoft\ Edge.app/Contents/Info.plist

[blockcham]

For others that have experienced the three windows that show up if Chrome is closed like @Levi_ and I, the Google team has filed it as a bug and should be resolved in v93.  @bryce simply put, v92 should resolve this thread and v93 should resolve the issue with the three windows showing up.

[bryce]

Yep! Thanks for that @blockcham . Also, a sidebar on that for anyone trying to make sense of that. It boils down to the two separate tickets opened with Google...

• 1218552 for the ASWebAuth. not completing the authentication and hanging on a blank screen
• 1220215 for the multiple session windows at times of auth.

1220215 for the multiple session windows at times of auth. will be fixed in v93 of Chrome at this point (it is in the Canary build last I checked). That did not make the cut for v92. 

[jonn1e]

@bryce Just for clarification, with Chrome v93 everything should be fine again and our users will not be forced to reauthenticate with JamfAAD popups in the future? 

[bryce]

@jonn1e so to be clear the v92 release of Google Chrome fixes 1218552 for the ASWebAuth. not completing the authentication and hanging on a blank screen an not authenticating. v93 will fix 1220215 for the multiple session windows at times of authentication. However; that will not stop the need for authentication and pop-ups in the scenario of a new registration, password change, or expiration of session (14 days is the global default if I recall).

[jonn1e]

Hey @bryce ,thanks again for clarification. 

Sure we need the authentication with a new registration and a password change but what do you mean with "expiration of session" and 14 days? 
From my understanding and our experience before the trouble with Chromium has started, users authenticated once with AzureAD / Conditional Access via Self Service Policy to reach compliance with their device. After that the compliance status will be automatically updated via Jamf to Intune / Endpoint Manager. 

The documentation for Conditional Access let me assume, that users has not to authenticate every X days.

"Compliance can be completely enforced by Jamf Pro. As a result, Mac computers are never out of compliance as long as the computer is managed by Jamf Pro."  

https://docs.jamf.com/technical-papers/jamf-pro/microsoft-intune/10.17.0/Best_Practices_for_Keeping_...

Or do you mean that if a device doesn't report it's status it will be removed from compliant devices at AzureAD? 

Best regards,

Jonny

[jonn1e]

Hey @bryce, Sorry if I have to push, but this is an important point for us. 

[bryce]

Hey @jonn1e sorry for the delay I was OOO and am catching up.

So what I mean by  "expiration of session" in 14 days is that the global AAD session by default ((I THINK) is 14 days in the testing I have seen with my tenants). This value is configured and detailed more here (Note: This page talks about 90 days, and I do not have a Persistent browser session set for my AAD tenant).

@jonn1e :

From my understanding and our experience before the trouble with Chromium has started, users authenticated once with AzureAD / Conditional Access via Self Service Policy to reach compliance with their device. After that the compliance status will be automatically updated via Jamf to Intune / Endpoint Manager. 

The documentation for Conditional Access let me assume, that users has not to authenticate every X days.

---

That is correct, but what I am saying is outside of a password change if the end users AAD session is revoked either by a session time out rule, or manual revocation by an admin or even the end user themselves. To do that as the end user navigate to https://mysignins.microsoft.com/security-info and pick the "Lost device? Sign out everywhere" option at the bottom of the frame page. This will kill your AAD session. That would cause the next run of the jamfAAD agent to prompt and ask for authentication after the fact.

[jonn1e]

Hey @bryce ,

Thanks again for clarification. So under "normal" conditions the users device won't get out of compliance if they don't change / lost their password or use the "Sign out everywhere" button. 

When you talk about the global AAD session timeout with 14 days, do you mean the MFA prompt timeout which can be adjusted via the MFA settings (sorry for german description).

or the "Primary Refresh Token"? Regarding the documentation it seems like the PRT is hardcoded to 14 days ad AAD.

Our actual settings are set to 90 days for MFA saving and we excluded the "Jamf Connect" App at AAD MFA conditional access enforcement, because we noticed that the App tries to authenticate the user every X minutes and fails if MFA is enforced. 

What I'm trying to archive is that our users don't have the reauthenticate Jamf Connect after two weeks of vacation or that the device will get out of compliance because of any other session timeout. 

Best regards,

Jonny

[bryce]

Hey @jonn1e ,

Not a problem!

I am talking about the PRT specially for the entire session validity.

In my testing I have had that timeout with and without MFA set on my tenant (have one of each).

Thanks!

-Bryce

[jonn1e]

Hey @bryce 

If I understand correctly our users have to register again for device compliance after a vacation of 14 days? 

[bryce_carlson]

@jonn1e sorry about the delay. I no longer have the @Bryce Jamf Nation account as my last day at Jamf was August 27th. Had to resurrect my old account from when I was a Jamf customer pre 2016.

They would NOT have to re-register. Simply they would have to re-sign in when MSAL and JamfAAD prompt for the new session and that would flip the device back to active.

[pueo]

This is causing havoc one of our users only.  They had already switched browsers to Safari then back to Chrome and the issue is still present.  The Jamf AAD pops up every 15mins. Drives the end user crazy.

[IamGroot]

What version of Jamf are you running?

[pueo]

10.31.  We are Jamf Cloud so always the latest and greatest.  Only one user has reported this, so thankful for this right now.

The Service Desk will get the user to update to Chrome v93 and re register.

[pueo]

Just to be clear. User is receiving Jamf AAD prompts in both Safari and Chrome every 15mins, just like @asidhu describes.

[Levi_]

I'm now having a problem where the Jamf AAD login is only launched in the Safari Browser. I have both Chrome and Edge installed and if I set either to the default browser it will only still launch in Safari. Before Chrome and Edge v92 I was able to successfully change the default browser and it would launch accordingly. Has anyone else here encountered this?

[bryce]

@Levi_ for Edge v92 that is expected. If you look at the file:

/Applications/Microsoft Edge.app/Contents/Info.plist

 You will see that ASWebAuthenticationSessionWebBrowserSupportCapabilities is not set to be active. The change was made with Edge v92 to revert back to the way it was in v90 and relinquish all ASWebAuth. to Safari for now. In v93 of Edge that is slated to change to be supported like v92 Chrome does now.

As for why Chrome is not doing the auth. I would verify you are on v92 and the Info.plist for Chrome is set to support ASWebAuth. In addition I would reboot the macOS device after the browser is set (or at least log out and in) I have seen that reload the browser defaults to take effect.

[Levi_]

@bryce Thanks for that info. I raised a support case with Jamf earlier today and can now confirm just this. After reloading Chrome to the newest version 92.0.4515.159 I was able to get it to launch instead of Safari. The Jamf agent advised me they are aware that Edge and Chrome still have an open problem with handling the AAD web authentication, which chrome seems fine. They also have an open problem with Safari launching two browser windows and failing registration on the first registration. I'm relieved to find out it's not something I was doing wrong, but a little frustrating that Safari has to fail at least once before you can successfully complete the registration. 

[pueo]

Hey All

This is a known product issue with Apple. I submitted a ticket with Enterprise Support.  The issue is resolved in Monterey Beta 5, which I confirmed does actually resolve the issue. Unfortunately it does not resolve the issue for Big Sur.  

"

This issue has been reported to Product Engineering, and they have implemented a change in macOS 12 Monterey beta 5. At your earliest convenience, please test and confirm."

Then I asked what I could do with the issue now:

--

Thanks for testing and confirming with macOS Monterey. This will require an update from the 3rd party developer for macOS Big Sur 11.3.x-11.5.x

For additional background, Product Engineering addressed a long-standing security issue where the WebKit networking process was allowed to trigger keychain authentication requests. They fixed that issue in 11.3 which caused this unintended fallout.

macOS 12 Monterey has a fix which will allow legacy software that uses this method to keep working.

The permanent solution is for developers to adjust their software to properly handle these authentication flows through the WKNavigationDelegate’s NSURLAuthenticationChallenge handling. See the documentation for details on this https://developer.apple.com/documentation/webkit/wknavigationdelegate?language=objc.

They should adopt - webView:didReceiveAuthenticationChallenge:completionHandler:, responding with a credential that contains an identity if the challenge.protectionSpace.authenticationMethod is "client cert auth.”

If they adopt this approach, it will work on all supported macOS releases.

.a

[Cayde-6]

Looks like MS Edge V93 has been released, ASWebAuthenticationSessionWebBrowserSupportCapabilities  shows as supported

[Levi_]

Correct, however in my testing Edge is broken and does not finish enrollment properly. I get stuck after accepting the Jamf Azure App account access and it does not proceed to the Keychain prompt. This is rough man, I'm trying to get everyone off of Safari but Edge and Chrome just do not work reliably for the Intune Enrollment. 

[Cayde-6]

I swear to <Some Higher Power> I had this working in MS Edge but now get the stupid Get the App prompt.

Switched back to Safari and enrolment worked first time 😞

[Levi_]

At least your Safari enrolls the first time Cayde-6 🤠.

Mine fails after the user signs into the launched safari browser, has to close safari, and run the enrollment again and they are greeted to accept the cert and trust the connector app. I literally have instructions written out for end-users the process will fail the first time, but the second time is a charm. It's not good a good look for sure.

[piotrr]

is it possible that some of us here have been suffering from  IT284707 that's been active these past few days, preventing enrollment? 

Microsoft 365 admin center

Yes, I know that's not the issue this started as, but since we're already having our browser problem, it's easy to assume that any continuing problem is still caused by the original problem even though there's a new issue. 

[pueo]

Cannot see the content regarding IT284707.  It just takes me to a 365 Admin page.

thanks

[bwoods]

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

[Levi_]

Voted and I hope it gets enough votes to be changed.

[asidhu]

Previously i was just advising users to change the default browser to safari as a workaround and now i have one user, who has Safari set as default browser but jamfaad just wont work and keeps on going up until get the app -.-. How do i get this working? This is so annoying.

[pueo]

We are also seeing this in Safari as well.  Perhaps the new version Safari resolves the pop up.  
Jamf Support instructed me to set Chrome V92 and above as default. Log out and log back in and register again.  
Jamf/MS are working on the issue. 

Let's see how this unfolds.

[asidhu]

This particular mac has the latest Safari and also Chrome v94, nothing worked but i will give it one more try.