Local Accounts become locked after demobilization

jsommers
New Contributor III

Hello,


We are transitioning part of our fleet from AD binding to jamf connect; however, we have hit an odd snag. In the past, we'd be able to just install jamf connect and once the user logged in, it would demobilize their account and sync with their entra credentials. With this new batch with JC 2.37, the accounts become Local, however they then get locked. When a user tries to log in with Entra SSO, it loads, looks like it has accepted the credentials but then just returns to the login screen. It does not accept any password with local login aswell. One thing to note, the devices are not on premise when the change takes place, if that has any effect. If anyone has seen this and has a fix, it would be much appreciated.

 

-Jack

Jack Sommers
3 REPLIES 3

AJPinto
Honored Contributor III

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.

jsommers
New Contributor III

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.

Jack Sommers

williamaddis
New Contributor III

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.