Are the local accounts actually locked? MacOS does have the ability to lock and account, and Jamf Pro can see it.
The Three things I would check:
- Conditional Access policies to ensure everything is allowed.
- Remove Jamf Connect on an effected device and see if the user can login after the issue without Jamf Connect.
- Reason being Jamf Connect hides macOS login error popups.
- Jamf Connect Logs, what is connect saying.
Are the local accounts actually locked? MacOS does have the ability to lock and account, and Jamf Pro can see it.
The Three things I would check:
- Conditional Access policies to ensure everything is allowed.
- Remove Jamf Connect on an effected device and see if the user can login after the issue without Jamf Connect.
- Reason being Jamf Connect hides macOS login error popups.
- Jamf Connect Logs, what is connect saying.
The issue is unrelated to Microsoft/Conditional Access. Other Microsoft accounts are able to log in on the machine, the only accounts facing the issue are ones that have migrated from mobile AD accounts to local.
After resetting the login screen back to default, it claims the account is locked. This is odd, as the account is local at this point. The issue starts when the account becomes local.
Logs weren’t significant/helpful.
The workaround we have found is logging into our IT admin account and setting the users password to what their microsoft account is, which then allows them to login.
Do you maybe have a more restrictive local password policy than your default AD domain policy? Maybe test running "pwpolicy -clearaccountpolicies" on an affected machine (as a working admin account), then try the local user login again.
Hi @jsommers, did you found a fix for this problem?
We have the same issue with some of our users. At the moment, we didn't find out anything in common between the users/devices with this issue. We have a support case with this problem and the only thing that appears in the logs is this line:
2024-10-11 12:31:24.116539-0300 0xfd15 Error 0x0 4756 0 authorizationhosthelper.x86_64: (JamfConnectLogin) [com.jamf.connect.login:DemobilizeMech] Something went wrong, there is no password in user data context
Before installing JC v2.37 the user had never reported a difficulty with its credentials. Right now we are working to try to get that "user data context" and see what we can find there.
Hi @jsommers just wondering if you had any updates to add regarding your account lockout issue? We have experienced a very similar situation, which makes me nervous to deploy to existing devices, until we understand the root cause of the issue.
I believe the lockout may have something to do with the fact that the account is possibly still linked to the on prem AD (unclean demobilisation), but not able to authenticate to it, so puts the account (locally) in lockout mode.
Hi @jsommers just wondering if you had any updates to add regarding your account lockout issue? We have experienced a very similar situation, which makes me nervous to deploy to existing devices, until we understand the root cause of the issue.
I believe the lockout may have something to do with the fact that the account is possibly still linked to the on prem AD (unclean demobilisation), but not able to authenticate to it, so puts the account (locally) in lockout mode.
Hi
Did you find anything about this? I believe I have a similar issue too
Hi
Did you find anything about this? I believe I have a similar issue too
Unfortunately we haven't got to the bottom of this issue (yet)..
Just curious if you demobilized your users BEFORE or AFTER you unbound from AD? Also, during the demobilization process, were the Macs able to communicate with your domain controllers?
What happens if you try to login the Mac with the password the user had before migrating to the Local account, Please check if there is any password policies are configured in the Machine, clear the local password policies before migrating to the Local account,