Self Service+ wants to access key "Jamf Connect" in your keychain (Will not Accept PW and close)

I’m also getting this. There was the release of Jamf connect 3.5 but I haven’t tried to install that to see if it resolves the issue.

Thank you for this ​@SlipStream, I had not noticed the update published. I do believe it is the resolution.

It is recommended that Jamf School users not upgrade to v3 from v2. What do we do then?

I am seeing this issue re-emerge on 26.4 Beta 2 while on Jamf Connect 3.5 and Self Service + 2.16

This keychain pop-up came up for us when our Jamf Pro instance was upgraded to 11.25.0. Upgrading to Jamf Connect 3.7.0 made the pop-up go away, but broke something else. As of now, our users to have to enter their password twice before getting into the desktop.

changing the branding from Self Service to Self Service+ appears to have resolved this issue for us.  From JAMF support:

With Jamf Pro 11.25, there was an improvement to branding with Self Service+ however the improvement involved modifying the app bundle. This modification of the app bundle caused a break in the Jamf Connect keychain item that Jamf Connect Login creates and Self Service+ uses if custom branding is specified in the Self Service+ application. So by us updating the branding header to include the + symbol, that resolves this issue but it will take time for this change to make it's way to your computers.

Funny enough, we just did some testing with Jamf Support, and the engineer we worked with thinks this is the problem as well. The “+” is not in the name of our custom branded Self Service+ application, which is prompting this keychain box.

Can you clarify where you made this change? I’m desperate to resolve this issue as it’s come back again and I can’t seem to find where the “+” is missing from the branding!

In your Jamf Pro instance, go to Settings → Self Service → Branding → select your default macOS branding → add the “+” in to the name after Self Service under Application Header. We haven’t tested this yet. We’re still building out our sandbox and want to try there before production.

That appears to have fixed it for us; thank you for your help and good luck!

We’re currently testing our fleet and have been working on this issue for some time, 

We added the “+” while making sure our Macbooks are on Tahoe (26.2) and upgraded JamfConnect 3.5-

We believe this also solved the issue for us too! 

Would you suggest adding the “+” to the name after Self Service under Application Header “before” flicking the switch for auto deployment of SS+? (And if so should I do this just before or can this be done anytime in adavnce without any impact on classic SS already installed). Our fleet already has JCL 3.7 installed on the devices.

We added the ‘+’ in the application header after we had already deployed SS+. I can’t speak to how it would effect classic SS. When speaking with Jamf Support they did say very clearly its important to have Self Service+ installed before Jamf Connect and encouraged us to use a smart group targeting only computers with SS+ to install Jamf Connect 3.5 and later. (I work with ​@stevenfray previous commenter)

​@bethstelzer thank you I really appreciate it. Unfortunately that order isnt an option, as previously a few versions ago, we were advised by Jamf to install JCL/JC prior to SS+ being installed, 

“"Unfortunately, there's no way to completely avoid this keychain prompt when deploying Self Service+ after Jamf Connect 3.5.
When Self Service+ is installed, it automatically applies password sync and privilege elevation configurations if a Jamf Connect configuration profile is present, and it needs keychain access for these functions even without password sync enabled. The prompt appears because Self Service+ requires permission to access credentials that Jamf Connect previously stored in the keychain.
This is expected behavior - the prompt should only appear once per user when Self Service+ first requests keychain access permissions. While you can't eliminate it entirely, your deployment strategy of installing JCL 3.5 first is still the correct approach to minimize other potential issues during the rollout."

This prompt is *usually* either:

- the login keychain password being out of sync with the current account password, or

- a Jamf Connect / Self Service+ version combo that keeps re-triggering the keychain item access request.

If you haven’t already, I’d start by confirming the login keychain password matches the user’s current login password (Keychain Access → change “login” keychain password, or create a new login keychain if it’s unrecoverable). Quick step-by-step here: Change your keychain password to match with your login password

If the keychain is definitely in sync and it *still* loops, the “upgrade Jamf Connect login package (3.5+ / 3.7)” fix mentioned above aligns with what we’ve seen too.

The issue is a known compatibility bug between older versions of Jamf Connect and Self Service on newer macOS versions.

The Solution

Update to Jamf Connect v3.5 or later. Specifically, installing the Jamf Connect login package for version 3.5 resolves the underlying credential conflict and stops the recurring keychain prompts at startup.

Alternative Workaround

If an immediate update isn't possible, you can manually adjust the keychain permissions:

1. Open Keychain Access.

2. Find the Jamf Connect key.

3. Right-click and select Get Info > Access Control.

4. Select "Allow all applications to access this item" and save changes.