Jamf Connect, Tahoe, Keychain

So we got told the same thing that we needed to update to 3.0. But what has fixed this so far for me is i had the user restart the mac, login, then type there password into that pop up and click Always Allow. Once they did that the pop up has not returned. 

https://learn.jamf.com/en-US/bundle/jamf-connect-release-notes/page/Jamf_Connect_macOS_Release_Notes.html

Jamf Connect 3.5 fixes the issue:

[PI143263, PI144134] Fixed: Jamf Connect presents the following one-time prompt on computers with macOS Tahoe 26.1 beta, both on the login window and on the desktop: "Self Service+ wants to use your confidential information stored in "Jamf Connect" in your keychain."

Appreciate your responses to the thread and hearing about what’s happening in your environments.

​@Corey-Ribble I see a similar thing as you. Except if they restart or logout and have to log back in the dialog comes back.

​@BookMac I’ve got a test computer that I’ve upgrated to 3.5 after its normal install of 2.45.1 that with light testing appears to be working without prompting the keychain dialog. It’s the ambiguity about what version computers in Jamf School should be running. I’m happy that 3.5 seems to “work” but I don’t like that it’s not documented. From that same link you shared further down the page in a callout.
 

Compatibility for Jamf Connect 2.45.1

If you are deploying Jamf Connect with Jamf School, Jamf recommends to continue using version 2.45.1 which is compatible with macOS Tahoe 26. This will preserve the existing menu bar capabilities for Jamf Connect and not affect existing deployments.

Because 3.0 and up are built with the idea that Self Service+ will exist on that computer to provide the menu bar functionality but Jamf School it doesn’t seem will get Self Service+ leaves us hanging. I’m encouraged that Jamf Connect Login 3.5 works right now on my test machine but some dependency could break it in the near future. 

Even though Jamf states 2.45.1 is compatible with Tahoe, I would say a keychain warning every reboot or login is not acceptable for the end user and often them having to input their password multple times even though they are clicking “Always Allow”.

If others aren’t seeing the repeated dialog box after a reboot or login on 2.45.1, I’d loved to know to keep me looking for what may be amiss in our configuration.

 

​@red_beard I ran into this same issue a few weeks back. And you're 151% correct that anything in the 3 branch requires SS+. So out of a necessity I was able to get it to work, via these steps.

1. Added JC 3.X to PreStage. This allows account creation to proceed as normal.
2. Did a quick enrollment policy that includes a reboot
3. Then had a policy that installed at startup/log JC 2.45.1

What this did was the following. It allowed the account to be created via JC with whomever is your IdP. Yes the device boots to the Desktop and you still see the keychain error/message pop up. However the quick “enrollment” policy kicks in and reboots the device. The device reboots, then decrypts [if FV’d] and JC window prompts the user [if configured this way]. Once the user signs in, JC 2.45.1 is being installed and you have the JC.app in the Application folder. Which provides you with the menu applet once you “launch” JC.app.

I found this to be extremely help in my previous environment. As this method addressed the keychain issue and our users did not need to type in their password in this window/prompt.

I would recommend to create another PreStage and test this out in your environment. Hopefully this maybe addressed in the future. Who knows? Maybe JC 2.46 will be released to  create a stopgap until your org  is ready to update to SS+. Now that is another conversation.

~L0$