Jamf Connect password sync - "Your local password is incorrect"

I'm having the same issue. I am on Jamf Connect version 2.4.0 Build 4. I know my local password is correct because I entered it to unlock FileVault and as my sudo password in terminal. Did you ever find a solution for this? I'm on Monterey beta 3 and I can't login at all from the Jamf Connect login window. I have to reboot each time to unlock FileVault, so I can't test if Jamf Connect is taking the password at all.

This issue persists for me.  The only thing that Jamf support was able to identify was an error stating "no UUID found" in the Jamf Connect logs, an error they hadn't seen before.  The proposed solution was to recreate my Okta account, which I have yet to try.  Based on your last post, I did find a local password complexity configuration profile that does not match our current password complexity policy, and we're going to modify that to see if it changes anything.  Thanks for the suggestion!

I'd like the follow up on this. I was running into the same problem. The issue for me was my Passcode Policy config profile on the machine. It was set to match okta/AD fully, 16ch and specifically "Password History of 24".

It was the password history part of the config profile killing the Connect Sync and giving me "your local password is incorrect." The logs heled me here. It was actually correct, but it was failing to sync the password with okta because the password was already used on the mac so the okta password coming down form high did not meet complexity requitements I needed to turn this feature off in order for syncing to work. This was because the password had previously matched Okta before the user changed it manually. 

We had an instance of this in our environment. Lots of head scratching and bashing. Found something simple to fix this, and verify everything was synced after it was completed, including FileVault.

Open system prefs, Users and groups, and unlock it with an admin account, then change the password while its unlocked. Please try this out in your environment if you can and let me know if you have success or not, thanks!

It turns out this was the solution for us as well.  We had previously modified a local password policy in Jamf that didn't help, but one of my coworkers found a different password policy that did fix this. 

Can you please describe how you did this?

In the configuration profile you use for Passcode, verify that your settings match or are less restrictive than your SSO password policy.

Actually just ran into this issue again. We are implementing a new password policy, so users are being required to update their Okta password, which syncs to Jamf Connect for their local user password. My director changed his password in Okta, logged in to Jamf Connect with the new password, got the prompt to enter the local password, entered the local password, got told it was incorrect. Logs showed nothing. I tested with my account on two different machines, had no problems. We ended up having him boot into Recovery and use the FileVault Recovery key to reset the password to the new one. I'm just wondering if we're going to have to do this every time he resets his password now.... 

For me, this issue only appeared when there was a mismatch between the network name and the local user name.

Confirmed by enrolling a fresh Mac in Jamf where the username did not match the network name. Sign into Jamf Connect, then perform a password change. Jamf Connect prompts the user to enter local password. "Your local password is incorrect"

(What's weird is the password does actually sync, but still Jamf Connect displays the error that the local password was incorrect.)

Then created a new user on the same machine where username matches the network name. Change network password. Jamf Connect prompts for local password. Works as expected.

One thing to note: In my environment, we are using Jamf Connect but not at the login screen. Using the custom login screen seems like it handles the username mismatch fine. But without that, Jamf Connect seems confused.

When you say you are using Jamf Connect but not at the login screen, what exactly do you mean? Are you only using the Jamf Connect Menu, and not the Jamf Connect Login Window? Because if so, you answered a question I asked myself last week of "can we use Jamf Connect without the login window?" We are using FileVault, so the only time we seem to get the Jamf Connect Login window instead of the FileVault login screen or the system unlock screen is during an upgrade or when there's a problem. Lately it's been random - someone will try to login, they either can get past the FV screen and then the jamf Connect screen comes up and won't take their password, or they enter their password at the FV login screen and it doesn't work and we end up having to use the recovery key. In either case, the user is using the password they've used the day before, or earlier that day - no password changes to the local machine or in Okta. It just seems to break.

I got the same issue when I try to change the Okta password from jamf connect menu, the new password was accepted by Okta (dev) because I set a very simple password policy. but when I type my computer old password for syncing, it show me "the local password is incorrect", I'm pretty sure the old password is correct, so I tried to reset the password in system preferences with the new okta password, I got a warning because the new password is not meet the macOS password policy. 

Then I reset the Okta password again and this time the new password meet macOS password policy, after changed the Okta password and type old computer password, it synced.

So, the content of message "Your local password is incorrect" is not correct, it has nothing to do with the old password, it is about the new password is mot meet the macOS password policy.

Exactly - the messaging definitely needs to be better. When we changed our password policy I went through everything with a fine-toothed comb to make sure all the password policies aligned. Found out after the fact that Azure AD has hard-coded password policy and won't accept spaces as symbols, which has caused an entirely different issue for us.

we are seeing this now with attempting to migrate names that don't match SSO 

I found that if we ignore the Connect pop asking for the users account and password and reboot the migration works. I have yet to determine a way to keep the Connect pop from appearing for the first time. 

This appears to be a password history issue. once removed from the Jamf side the password applied was allowed to move forward. 

I was doing some research and found this thread a while after you posted so just old information if you've already took care of this . . . We use just the Jamf Connect menu bar app for most of our machines by configuring only com.jamf.connect in our config profile. We have some shared machines that we configure both the com.jamf.connect.login and com.jamf.connect items which then shows the Jamf Connect login window. Take Care!

Thank you Abrunner for helping me with this post!!