Skip to main content

Has anyone experienced an enrolled device, utilizing JAMF Connect, just *changing* the local password, even when no password change was initiated?

Our users enroll devices with JAMF Connect and Google IdP. It creates a local account with the same password as their email. If they change their password to their Google account, JAMF Connect will yell at them to change the local password to match the new Google password- which is exactly how it's supposed to work.

I have a bizarre situation that has occurred 3 separate times (once even to me) where the local password just changes on its own and locks the user out of their device. When I have the user login on a different device with their email password (which should be the password for the local account), they are successful, so it's not an issue of them typing their password incorrectly.

I have assisted two people through the recovery process at this point. Even on the root level in recovery mode, it rejects that known password. Our only saving grace has been that JAMF Pro stores the FV2 encryption key, or else I would have had to nuke and pave their devices and just hope the backups were working. 

When it happened to me, it was a brand new computer and hadn't yet stored the encryption key in JAMF Pro, so I was forced to nuke and pave- my password is the same to this day, it just changed on me.

I feel like I am taking crazy pills, so please tell me if this has happened to you and if you did anything to resolve it. I am opening a support case as well, but thought I'd ask the community too. 

Thanks! 

I don't think its JAMF Connect, I think its FileVault.

 

Try differing FV enablement for something like 3 logins. This would allow the users to get their passwords sorted out before FV enables. This way FV does not attempt to enable when their temp password is in place. 

I don't think its JAMF Connect, I think its FileVault.

 

Try differing FV enablement for something like 3 logins. This would allow the users to get their passwords sorted out before FV enables. This way FV does not attempt to enable when their temp password is in place. 


Hi there! Thanks for the reply, but there is no temp password being set. The computer automatically loads JAMF Connect on enrollment and authenticates against the IdP, plus the password lock out is happening well after the enrollment period, with the exception of when it happened to me right after enrollment, but the password had always been my IdP password. It would not have allowed me to move past the JAMF Connect screen without the correct password. 

It is such a bizarre issue.

Hi there! Thanks for the reply, but there is no temp password being set. The computer automatically loads JAMF Connect on enrollment and authenticates against the IdP, plus the password lock out is happening well after the enrollment period, with the exception of when it happened to me right after enrollment, but the password had always been my IdP password. It would not have allowed me to move past the JAMF Connect screen without the correct password. 

It is such a bizarre issue.


I'm having that issue as well, I'm about to roll out 175 computers, and this keeps happening on my testers. It works to log the user in with Jamf Connect via Google, then after a short time, the password has been changed to some unknown password, and I have no ability to change it other than to go to recovery mode and change it using the recovery key from Jamf.

I'm having that issue as well, I'm about to roll out 175 computers, and this keeps happening on my testers. It works to log the user in with Jamf Connect via Google, then after a short time, the password has been changed to some unknown password, and I have no ability to change it other than to go to recovery mode and change it using the recovery key from Jamf.


I feel so relieved to know I'm not the only one. When you go into google admin's investigation tool, does the user you used for JAMF Connect show a TON of non-suspicious re-auth password errors by chance? That's what I'm seeing on a lot of users, but am trying to determine if it is related to this issue or another issue. 

I feel so relieved to know I'm not the only one. When you go into google admin's investigation tool, does the user you used for JAMF Connect show a TON of non-suspicious re-auth password errors by chance? That's what I'm seeing on a lot of users, but am trying to determine if it is related to this issue or another issue. 


I'm happy to know I'm not the only one too, I was about ready to chuck the computers out the window! Just checked that tool and saw a few failed login attempts for me (I was using myself as the tester) but not a massive amount. One other odd thing that I've noticed though is that when a setcomputername script we have runs on these computers, it names them root - the script is supposed to name the computer as the logged in user's username.

This is happening to us as well. Users will get randomly locked out, not even at the Filevault screen but just at the user lock screen. Nothing in Jamf logs

We are not using FV here, but I have had the same on a few of our pre-stage users the last few months. They'll setup their computer on Friday, and then come back to it Monday to sign in and no password works. It's the craziest thing. I've tried a few different tests to see if I could find out where the issue is taking place, but it just doesn't seem to be going away.

I have the same problem, we've about 250 MacBook under Jamf and this issue is occurred on about 20/25 devices in the last week

It ended up being FileVault in our case. Apparently our Jamf Connect script was enabling FileVault, which seemed to be done before the Google password was given to the computer during enrollment. Once we changed the enable FDE script to false instead of true, the issue was resolved. We only deploy FileVault through a config profile now, and I'm enabling it in Self Service versus having the computer run it in the background. Hope that helps!

We are seeing this in our environment. Filevault is not enabled. We are deploying a generic local account through a policy to handful of lab computers. For some reason after a day or two, no one can login. We have to login with the local admin and reset the password. 

 

I removed Jamf Connect thinking that was the issue, but it is still there.

for me, it's happening randomly with the user Admin account, not the user "employee" account. I didn't find this related to Jamf Connect at least, some devices are okay, but some others are not.

I figured out that the Admin password was changed with the local password of the employee.. does it make sense what I said? 

for me, it's happening randomly with the user Admin account, not the user "employee" account. I didn't find this related to Jamf Connect at least, some devices are okay, but some others are not.

I figured out that the Admin password was changed with the local password of the employee.. does it make sense what I said? 


Do you have FileVault being enabled during enrollment? Apparently it's best to enable that after the user has logged in to prevent the computer from changing the password.

Do you have FileVault being enabled during enrollment? Apparently it's best to enable that after the user has logged in to prevent the computer from changing the password.


yes, jamf connect and FileVault enabled

Reply


Terms & ConditionsCookie settings