Skip to main content

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

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,  


Reply