Login requires Google consent every time

[rosmer]

Suddenly, as of a few days ago, users are prompted on every login to allow Jamf Connect to access their Google accounts. They need to scroll down and click Allow every time.

The only thing that's changed recently that I'm aware of is that Jamf Connect version 2.35 went out just before the issue appeared. I tried rolling back on a test device with no luck though. Laptops are all on at least 14.4.1 of Sonoma.

I found two old posts with a similar issue, but neither state what actually fixed the issue: Old post 1 and old post 2 

[CraftyCilantro5]

Not sure if this would help but often times our users who use chrome to access company sharepoints are prompted to sign in. even if they just signed in minutes ago theyre prompted when moving to different sharepoint sites. We reset their keychains and it worked for them.
Careful with the keychains cause some of them interact with our device management via intune.

Also, we just recently added in the microsoft sso plugin for our macs which prompts for sign in much less now.

[AJPinto]

I would roll back Jamf Connect to rule in/out it being something with the client. However, based on the popup I am going to figure this issue is on the IDP side and something in your Google Admin Console needs to be adjusted.

[rosmer]

Thanks for looking @AJPinto. I rolled back to Jamf Connect 2.33 on a test device and still get the prompt. 

I checked out LDAP settings within Google Admin and see the certificate for the Jamf Connect web app is still valid, so I'm not sure what else to check there.

[AJPinto]

Since its happening on the older version of Jamf Connect also, that would point the issue on your IDP (google). Unfortunately, I don't have deep knowledge of Googles Admin Console, but Jamf Support may be able to provide direction.

However, I would pass this off to your IDP folks. If this is you, maybe time to open a ticket with Google.

[bryancowie]

Hello, I am having this same issue. Was there any resolution to this issue?

[JustinParcher]

Having the same problem in our environment. Machines in the field are on version 2.29, and I have tested on 2.35 without change. The macOS App Access Control is configured in Google Workspace Console to allow access. 

[MMA-Admin]

Same issue here but only for one user… so far. 

[mtk]

Same thing has cropped up here too.

[rosmer]

We're still having the trouble. I've opened a ticket with JAMF support, but it does seem to be an issue on the Google side of things. If we figure it out I will post what I find!

[greenside]

same issue here, just started getting users reporting this

[MMA-Admin]

Becoming widespread now with our user base and definitely seems to be something going on with Google. The Prompt on my phone 2FA authentication is not working either. I don't know enough about OAUTH and APIs to do any work on this myself, so am relying on the greater minds here, at Jamf, and at Google for a solution. I will open a ticket with Google.

[avail]

Popping in a 'same' here as well. I've even tried whitelisting the Jamf Connect client ID for Google OAuth, but no joy 😥

[J-tech]

We also have this same issue with the Jamf Connect consent screen which started about a week ago. We opened a Jamf Support ticket last Friday and were also advised to open a Google support ticket as well, which I did last night.  Hopefully someone on the thread will get some traction with Google as it does seem to be something on their end.  

[greenside]

Has anyone had any luck with Google?

[MMA-Admin]

nothing yet. 

[rosmer]

No progress for us yet. JAMF is waiting on info from Google while looking into it themselves, and Google has so far given no help. The only suggested action was to add the Oauth Client ID as Trusted in the API section of Google Admin, which we have done multiple times.

Google wants to get a HAR file (https://toolbox.googleapps.com/apps/har_analyzer/) but since JAMF Connect is not logged into through a traditional web browser I don't know how I could collect those logs.

[rosmer · Accepted solution]

I have a fix, but not a great one. It at least points to where the issue is.

If you followed Jamf Connect's guide to integrating with Google then you entered https://127.0.0.1/jamfconnect as the Authorized redirect URI when setting up the OAuth Client ID.

Through a bit of a trial and error I've found that the OAuth Consent Screen does not like IP addresses anymore in the Authorized Domains section. I changed the URI to a fake domain address, like https://jamfconnectloginscreen.com, and changed it to match in the Jamf Connect Login Settings config profile in Jamf, and now I no longer get the consent screen.

I did this on a test setup because using a fake domain doesn't seem like a good idea long term. I don't know if any credentials actually get sent out to it.

I updated my ticket with Jamf in hopes they can figure out a proper fix.

[MMA-Admin]

I have forwarded your solution to Google support as well, as this seems to possibly be a Google Cloud change, not liking 127.0.0.1

[MMA-Admin]

Spoke with someone in person from Jamf and the solution above is the correct solution. You must change your URI to point to a valid FQDN, but one that will not answer or redirect. Google is not likely to change their URI requirement and pointing to any valid site that does not answer the redirect request is all that the Jamf Connect needs to work. According to the Jamf employee I spoke with, the documentation for setting up Jamf Connect will be updated in the near future to reflect this change.

[BKZU]

Alright, that's great news, waiting for official communication before making any changes.

[PCichy]

Can we use "localhost" instead?

[MMA-Admin]

I tried localhost on a test device with a test policy, without changing it on the Google end as I didn't want to hose all my users, and it did not work. I think it would have to change on the Google side, but I am not game for testing that myself. Not skilled enough to set up another instance in the cloud, etc.

[mtk]

Added localhost to the google side (as an additional URI), and setup test profiles with it, did not work.

Did add localhost.org to Google and the profiles as a test, and that seems to work OK.

[PCichy]

Yes, thanks. Tested it 10 minutes ago. Same here.

I won't put random domain as a solution. Waiting for official fix. Thanks all!

[avail]

The suggestion I got back from Google was to add the client ID for Jamf Connect to the domain wide API delegation in Google Admin, which really feels like quite a sledge hammer approach to it. Haven't tested it yet because it's such a big change I need some approvals before having a go. 

[astrugatch]

did they say which scopes would need to be added and allowed?

[rosmer]

In Google Cloud - Credentials - Oauth 2.0 Client IDs is where Jamf Connect has you create an ID. Within that ID you have to enter an "Authorized redirect URI"

This URI is what has to be a domain name now, but it doesn't say that explicitly that I can see. This will automatically be added to the Oauth Consent Screen's Authorized Domain list, which does specify that it needs to be a "top private domain"

Whatever you choose to enter, you have to change the OIDCRedirectURI key in your Jamf Connect Login Settings config profile to match. I tried it now with our school's website domain and it seems to work ok. I'm still hesitant to push it for all users though as I'm not totally clear on what it's used for yet.

[PCichy]

Any updates?

[rosmer]

Nothing from JAMF on my end. They closed the ticket stating they're still researching.

Google support was no help.

[KCOURTEAU]

I just ran into this today. The workaround of using a domain name seems to work. It would be great to get something official from JAMF or Google on it though.

[RobinJJ]

Maybe something?

https://apps.google.com/supportwidget/articlehome?hl=en&article_url=https%3A%2F%2Fsupport.google.com...

In google admin console: https://admin.google.com/ac/owl 

[avail]

Funnily enough, I just tried the Domain-wide delegation bit today but with no change :(

I added the ID from the existing OAuth config we had whitelisted in Third Party App Access in Google admin and added the same 3 scopes to the domain wide delegation config but no joy!

[ejadadic]

I'm having trouble understanding Jamf. They are selling a comprehensive product, but I've received information about multiple Jamf Pro bugs (including Jamf Connect) that haven't even reached the development stage. I'm frustrated with the quick fixes and assurances provided to customers.

[RobinJJ]

here we go: https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Suppressing_Google_Conse...