Post-Enrollment Autologin with Monterey 12.4

[kirbybj]

We are using PreStage Enrollment and want to skip setup and have the first login to be Autologin with the created user during PreStage Enrollment so the rest of the Jamf policies can finish before the first Network user logs in.

Has anyone done this before and can help with what has worked and how to do it. any help would be appreciated.

[SCCM]

why do the polcies need to run with autologin account? cant you create a policy set to run on "enrolment complete" which runs a script with "jamf policy -trigger" comaands running the rest of the policies (set custom triggers on them)

[kirbybj]

I do have the policies run on "enrollment complete". I am trying to see how I can have the first login be an autologin. The client is in PreStageEnrollment Scope.It recovers the macOS and starts the RemoteManagement process. The user answers a few questions and we are at the login screen. I want this first login to be autologin with creds we created in the PreStageEnrollment. Once loggedinDepNotify takes off and informs the user of the process happening in the background, Then once the Jamf policies finish installing DepNotify completes. Then the user can restart and login with their network creds.

Any suggestions in this process? Best practices or flow you can suggest?

[SCCM]

Ive not used it myself but i know some users were using a "kcpassword" script like this: https://github.com/xfreebird/kcpassword
or https://www.brunerd.com/blog/2021/08/24/automating-automatic-login-for-macos/

Not sure if it works on the latest OS, but any info sec team would prob frown upon use of something like that, i would suggest reading up on "kcpassword" script.
***The above is not a recomendation***

[kirbybj]

Thanks I did some reading before posting here and I believe kcpassword is using a python 3 script with will not work after 12.3. I will check it out again to confirm. Thank you for responding.

[SCCM]

The first link uses phython3, i think the guy in the second link re-wrote it to work in bash to get around the problem (not sure if that helps you).

[mrheathjones · Accepted solution]

I currently have an enrollment workflow similar to what you are describing. This works well for us on macOS 12.5 (even tested with macOS 13). See below.

1. Create a package copying the kcpassword file to /private/etc (file ownership should be root:wheel and permissions 600)
   1. You can generate this file by setting auto login on for the user in System Preferences on a test device, then grabbing a copy of the kcpassword file from /private/etc
2. Create postinstall script for package
   1. Script should contain the following code:
      1. if [ -f /etc/kcpassword ]
         then
         /usr/bin/defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser <auto_login_username_here_remove_brackets>
         fi
   2. I'm enabling ssh, kickstarting ARD as well as setting the user photo  as well which are all optional 

I have a policy that installs the "Deploy_Autologin.pkg" package as an Enrollment complete trigger. My Enrollment policies are prepended with numbers 01-xxx to ensure they are executed in the order I want/need. The final policy with the enrollment complete trigger is a "Reboot" policy. After reboot, our auto login account is then auto-logged in and the configuration phase begins, one of the policies deletes the kcpassword file and deletes the autoLoginUser key from the com.apple.loginwindow plist which disables auto-login. During the configuration, right before the final reboot policy, I create a dummy file that an extension attribute is looking for. if the dummy file exists (EA = TRUE) the device is added to a Smart Group that is scoped to delete the enrollment account at at all of the necessary triggers. Long story short, yes I've done this and yes this works (for me at least). Hopefully this helps. 

[kirbybj]

Thank you for this solution. I’m going to give it a shot.