Skip to main content
Solved

Jamf Connect window disappears with no username+password: machine softlock

  • August 1, 2024
  • 4 replies
  • 154 views
N
Forum|alt.badge.img+7

Hello!

We have a Jamf Connect window setup that works well except for one part: If you are a new hire and haven't setup your account yet (we use Okta), when you receive a new machine and get to that window, you'll let it sit but it will auto-continue to a standard MacOS login window. Without walking through the setup process that immediately follows the JC window, the machine will never pickup your username and you'll find yourself in a type of soft-lock where the machine doesn't have an account to use and we need to reach out to these users to walk them through a complete wipe/rebuild from Recovery.

 

I assume there's just some setting/property in our Jamf Connect config profile that "autocomplete's" but I'm unsure what it is. Potentially the "Allow Local Fallback" property? We use that for it's intended use after the user has already setup an account to login to their machine, but our problem of course occurs only for new hires only when they haven't setup an account first.

For what it's worth, we notice the Jamf Connect window goes away in favor of the normal MacOS login window at around the same time the screensaver comes up (15 minutes)

If anybody has any suggestions I'm all ears! Maybe even a secret keystroke to bring back the Jamf Connect window?

Best answer by Nate1

Okay I figured this out and it's a situation probably unique to our setup/company:

Long story short: we have a policy that updates Jamf Connect and in that policy we reset the Authchanger. At the initial Jamf Connect login screen, if it sits long enough it will check-in to Jamf and run policies and ours was getting reset via that policy.

 

Long story long:

At the initial login screen your computer can actually do things, like check-in and run policies. Additionally we have a slight security measure in place to allow users to log into Jamf Connect once which creates a local account for them, then turn off Jamf Connect going forward so no other network accounts can login. The idea is that now only one user (the initial user) can login so it's slightly more secure. In order to make sure Jamf Connect gets turned off so users only see the MacOS login screen, we have a policy that runs "/usr/local/bin/authchanger -reset -jamfconnect".  This policy only runs on machines that detect the Jamf Connect window. Of course brand new machines where we WANT the JC window will have the policy run as soon as it checks-in, thus removing the JC window and leaving the computer soft-locked with no local users and no way to log in via a network. (we do have local admin users but giving out those passwords to new hires who had this happen is a non-starter).

 

I've solved this issue by creating a smartgroup that checks for all machines that have enrolled between 0 and 5 days, and removes them from that authchanger policy. Problem solved ...assuming the user logs in for the first time within 5 days.

    4 replies

    AJPinto
    Forum|alt.badge.img+26
    • AJPinto
    • Legendary Contributor
    • August 2, 2024

    This is not the expected behavior of Jamf Connect. If the Launch Daemon is deployed and configured correctly, Jamf Connect should supersede the macOS Login screen indefinitely. Something seems off, and I dont think its Jamf Connect.

     

    Are you deploying the Jamf Provided Jamf Connect Launch Daemons?

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • August 2, 2024

    This is not the expected behavior of Jamf Connect. If the Launch Daemon is deployed and configured correctly, Jamf Connect should supersede the macOS Login screen indefinitely. Something seems off, and I dont think its Jamf Connect.

     

    Are you deploying the Jamf Provided Jamf Connect Launch Daemons?


    Just to confirm, this is the "JamfConnectLaunchAgent.pkg" thats included with the .dmg download from Jamf? If so, yes however we have since upgraded the Jamf Connect version for deployments (we're using 2.28 whereas our LaunchAgent is from the 2.20 dmg). I feel stupid for asking now since it seems obvious, but should the LaunchAgent packages be updated whenever the JC agents are updated? They were always named the same inside the dmg so I stupidly assumed the Launch Agents contained the same info every time and just the JC version changed.

     

    I'm testing with 2.37 Jamf Connect and the same Launch Agent that came with the 2.37 dmg now. Will report back shortly.

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • August 2, 2024

    Just to confirm, this is the "JamfConnectLaunchAgent.pkg" thats included with the .dmg download from Jamf? If so, yes however we have since upgraded the Jamf Connect version for deployments (we're using 2.28 whereas our LaunchAgent is from the 2.20 dmg). I feel stupid for asking now since it seems obvious, but should the LaunchAgent packages be updated whenever the JC agents are updated? They were always named the same inside the dmg so I stupidly assumed the Launch Agents contained the same info every time and just the JC version changed.

     

    I'm testing with 2.37 Jamf Connect and the same Launch Agent that came with the 2.37 dmg now. Will report back shortly.


    Unfortunately same experience after confirming the JamfConnect package and JamfConnect Launch agent package both came from the 2.37 DMG download from Jamf.

     

    For what it's worth, this only occurs on the first login seconds after passing through the Remote Management window.

     

    Some interesting notes though: We do have a Jamf Notify script/screen that installs some packages in the background while showing some windows letting the users know some basic things about their laptop. I did now realize that if I wait at the JC login screen until it flips back to the standard MacOS login, then login with the local user, there will be no JamfNotify screen, i.e. it logs straight into the desktop. I'm curious if the JamfNotify script is running the background and when it's done it resets the login window. At the end of our script we reset the authchanger with: 

    /usr/local/bin/authchanger -reset -jamfconnect

    Maybe that is causing issues?

    N
    Forum|alt.badge.img+7
    • Nate1
    • Author
    • Contributor
    • Answer
    • August 22, 2024

    Okay I figured this out and it's a situation probably unique to our setup/company:

    Long story short: we have a policy that updates Jamf Connect and in that policy we reset the Authchanger. At the initial Jamf Connect login screen, if it sits long enough it will check-in to Jamf and run policies and ours was getting reset via that policy.

     

    Long story long:

    At the initial login screen your computer can actually do things, like check-in and run policies. Additionally we have a slight security measure in place to allow users to log into Jamf Connect once which creates a local account for them, then turn off Jamf Connect going forward so no other network accounts can login. The idea is that now only one user (the initial user) can login so it's slightly more secure. In order to make sure Jamf Connect gets turned off so users only see the MacOS login screen, we have a policy that runs "/usr/local/bin/authchanger -reset -jamfconnect".  This policy only runs on machines that detect the Jamf Connect window. Of course brand new machines where we WANT the JC window will have the policy run as soon as it checks-in, thus removing the JC window and leaving the computer soft-locked with no local users and no way to log in via a network. (we do have local admin users but giving out those passwords to new hires who had this happen is a non-starter).

     

    I've solved this issue by creating a smartgroup that checks for all machines that have enrolled between 0 and 5 days, and removes them from that authchanger policy. Problem solved ...assuming the user logs in for the first time within 5 days.

    Terms & ConditionsCookie settingsAccessibility statement