Skip to main content
Solved

Jamf Connect 3.7.0 Password not in Sync

  • March 17, 2026
  • 3 replies
  • 52 views
StoopsE
Forum|alt.badge.img+4

Hello,

Google is our IdP for logging in to Jamf Connect Login. I am using Self Service+ which states that the local password is “In Sync”. If I change a users password in Entra (which then will sync to Google Workspace), the “in Sync” does not go away or update ever. If I were to reset the password locally though Self Service+ using the menu bar drop down (opens Entra password change portal) it then states that the password is out of sync and that I need to login again to Self Service+. Great! I login, it accepts the new password, and states that the password is “in Sync”. I am never prompted for the old password.

If I log out of the user and log back in with the new password, I am successful at the Google SSO pane, but it then has a smaller Jamf Connect pane that asks for valid credentials, which is the previously set password. The local password will not update despite “being in sync”.

I have to be doing something fundamentally wrong, any help would be really appreciated. 

Best answer by StoopsE

Alrighty,

It seems that I have resolved it. I tried quite a few things in the search to find what was causing the interference, out of them, I think that both CreateJamfConnectPassword and OIDCNewPassword being enabled when one or the other should have been (according this article) may have been apart of the issue. I can see in connect’s logs it’s able to check at the verify pane during login and determine that the passwords were not matched, then prompting once logged in notifications to update the passwords as expected.

If anyone has more details on this conflict of keys I would appreciate to know if this could really have attributed to what I experienced or if it was something else I did.

 

 

3 replies

StoopsE
Forum|alt.badge.img+4
  • StoopsE
  • Author
  • New Contributor
  • Answer
  • March 18, 2026

Alrighty,

It seems that I have resolved it. I tried quite a few things in the search to find what was causing the interference, out of them, I think that both CreateJamfConnectPassword and OIDCNewPassword being enabled when one or the other should have been (according this article) may have been apart of the issue. I can see in connect’s logs it’s able to check at the verify pane during login and determine that the passwords were not matched, then prompting once logged in notifications to update the passwords as expected.

If anyone has more details on this conflict of keys I would appreciate to know if this could really have attributed to what I experienced or if it was something else I did.

 

 

A
Forum|alt.badge.img+1
  • angelohuang
  • New Contributor
  • March 18, 2026

I’ve seen this kind of “looks in sync until a user-triggered reset” behavior when the menu bar status is basically reporting the last successful local sync, not actively polling Entra/Google for a change.

A couple things that usually help narrow it down:
- Make sure you have a clear “source of truth” for password changes (IdP vs local) and a predictable way the local macOS password gets updated (typically at login / re-auth).
- Force a re-auth / re-sync path (sign out of Jamf Connect menu bar, have the user log in again, or run the relevant Jamf Connect verify/sync command if you have one in your environment) and see if the status flips immediately.

If you’re comparing approaches, this write-up on how Platform SSO + user authorization handles password changes/syncing on macOS was a good reference for me:
Mac Platform SSO & Apple User Authorization Policy

Curious: are you using Jamf Connect Verify / a scheduled verify, or only relying on the Self Service+/menu bar status?

StoopsE
Forum|alt.badge.img+4
  • StoopsE
  • Author
  • New Contributor
  • March 18, 2026

​@angelohuang  

Curious: are you using Jamf Connect Verify / a scheduled verify, or only relying on the Self Service+/menu bar status?

We are using Connect Verify. Signing out and signing in or using the menu bar connect would momentarily change the status of the sync state in Self Service+, but not actually prompt for the prior password after authenticating with Google. I did find some notes on the settings conflict I had and it does seem that may have been the issue as I would log in and it would retain the prior password in SSP.

But now, after a password has been changed, Verify appears (normal workflow uses passthrough) the user then needs to enter their old password. When they get to the desktop SSP notifies that they are out of sync and the manual portion of the sync is kicked off.

Terms & ConditionsCookie settingsAccessibility statement