Jamf Connect continuously prompting that IDP password not in sync

[rpayne]

We have an issue where some machines keep prompting the user that their IdP password does not match their local password and are given the option to sync. However, when you hit sync, the login popup is completely greyed out (as shown below).

In all cases, we have verified that the password is in fact the same. I'm assuming this is cached somewhere and maybe needs to be cleared? Has anyone seen this?

[mikevandelinder]

@rpayne the grayed-out sign in window makes me think that license file may have expired or is missing. If the About menu is displayed in the dropdown menu, take a look in there for any messages.

[rpayne]

The license is present and working. We house our license in a separate configuration profile for easy of update. Pulling this CP results in the License is expired message.

[YanW]

try reinstalling Jamf Connect

[rpayne]

I forgot to update. Right after posting this, we reinstalled the latest connect. This fixed the greyed out. It still prompts for IdP sync though. It will accept the password, go away, and then reappear prompting for sync 30 seconds later.

[YanW]

If it's just 1 machine, you can try unscope the Menu profile and scope it back. 

I'm assuming your <key>NetworkCheck</key> is the default <integer>15</integer> in the Menu profile...? 

[rpayne]

That is correct. So far we've seen it on about 5 machines. Unscoping and rescoping results in no change.

[YanW]

Well, you might want to reach out to support. Sorry can't help much here

[rpayne]

You are totally good. I just thought I'd post here first

[dennisnardi · Accepted solution]

I've seen this behavior intermittently. I've been back and forth with Jamf Connect for a while and it was identified as a product bug and will hopefully be fixed in the near future. For reference I've seen this issue since ~March of this year, updating every version of JC, with Azure as my IDP. I do more often see this on non-ADE enrolled machines as well. 

My issue around this was documented as PI111500. My issue appears to be caused by the com.jamf.connect.state file at Users/$user/Library/Preferences having the "PasswordCurrent" value be set incorrectly (seemingly randomly), and JC doesn't update it right away.

This issue is usually random, or at least transient, and usually goes away on its own after a little while (in my environment anyway). A workaround is manually setting the "PasswordCurrent" value in the aforementioned plist file to be 1. 

[rpayne]

So No to revive an old thread, but I have some further questions, As of now were are fixing this issue in a reactive manor. I have yet to find a way to be proactive here. How are those of you who are having the issue detecting it before it's reported?

[dennisnardi]

Fully reactive here. I'm still seeing this from time to time (not too often), but less frequently than before. The PI I was given before is still active. 

[TheITGuy69]

I am seeing this issue, our situation is we have service accounts and new hire accounts where we disable MFA to allow for developer devices to be used by multiple devs with a service account or setting up new hire devices for them prior to them starting so we cannot set up MFA for them obviously. MFA is forced on everyone in the company.

The only thing that resolves it for me , is enabling the client secret in the configuration profile but we all know that was supposed to be deprecated in jamf 2.13.