Auto Login Local User

A colleague recently got this working. I believe he found that populating the kcpassword file and plist entries worked only as a startup task.

Hi blindcola

I could deploy the kcpassword file and run this command and now it works. Thank you!

Does anyone know if CreateUserPkg works with Sierra? I tried it, and am getting an error about not finding a keychain, and a looping error about macOS needing to repair the Library to run applications.

Development has ceased, with 10.9 being the last supported OS.

Is there a replacement?

Is there another way to do this (Create a new user, set it to auto-login, and save it as a pkg, so it can be deployed as part of a config in Imaging) in Sierra?

@JayDuff It does still work, in my limited testing.

@bentoms

@JayDuff It does still work, in my limited testing.

I'm interested to hear about your environment. I tried to use it with an otherwise-stock AutoDMG-created Sierra image, and I got a nasty error loop. It kept asking for the password to unlock a keychain, and saying a keychain was not found.

@JayDuff The behavior you describe is often due to using an AD login but not having the option to create a mobile account at login enabled, but I don't understand why that would be a problem with a user being created with CreateUserPkg.

@sdagley Thanks for weighing in.

We do have AD in use here, but the Macs aren't bound to it. We only use it for logging into storage, authenticating to our copiers, and getting onto the BYOD network. Also, the account created is not on AD (it's called "Default").

I was thinking there could be a conflict with the management account being created by Casper, but I tried with a different User ID (505), and checked the install after imaging box, and that got it! But it didn't auto-logon for some reason, and it is asking for iCloud and Siri, even though I've manually installed a .AppleSetupDone file from a computer that has already answered those questions. That's a separate issue.

I think checking the Install After Imaging box made the difference for the account. So, yeah - CreateUserPkg works, except the Auto Login.

I was able to get everything working! I used CreateUsrPkg to create the user. The Autologin didn't work, but I put a script into the JSS that's essentially a one-liner:

#/bin/bash

defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser default

exit 0

Then I brought this script into the JSS.

I added both of the scripts to the Configuration, in Casper Admin, setting them to run After Reboot, and BINGO!

I know this post has been dead for a while...

I have the setting, and kcpassword file deploying fine on a Macbook Pro - 10.13.5 - as part of my post-DEP workflow, but it isn't working on an iMac with the exact same set up...

Anyone else seeing this? Anyone have any ideas?

Tim

I'm interested in a working solution for this as well. Anyone currently able to automatically enable auto login for a local user in a 10.13, DEP or Netinstall workflow?

dtmille2, I'm currently stuck here as well.

I really don't want to make the techs login as local administrator to finalize a "zero touch" process.

dtmille2 & tnielsen

The way i got this to work in 10.14, was to use a Computer PreStage Enrollment to create my local admin user.

I then used pycreateuserpkg cli to create the exact same user with autologin set with the command switch, and deployed that identical user as a pkg.
https://github.com/gregneagle/pycreateuserpkg

My cli looked something like this.
$createuserpkgbinarypath/createuserpkg -n $orgname_autologin -f $Orgname AutoLogin Account -u 501 -p $Password -H /Users/$orgname_autologin --admin --autologin --hidden --version=1.0.0 --identifier=$OrgnameAutologinpkg /Users/$User/Documents/cccbautologin.pkg

That worked for me to get near-Zero touch provisioning working for us. In our case we need to install all applications/configurations, bind to AD before handing the device to the end user. (We have a 20GB Parallels Windows VM to install for most users)

@benk Is the -u always 501? Are you still using this method on 10.14+?

@kericson I just tried @benk 's method on a 10.15 machine. The first user account is going to be 501, unless you've specified it with something else (used pycreateuser to create a different account with a different UID or created a hidden user account, etc). In my case we use 503 (you could use 550 or something else that's at least higher than the first few 500's to be safe).

thanks @benk — this same process worked perfectly for me on Big Sur as well. Created a local user with a policy, then installed a package of the same user. So far have only tested installing the package manually, not from JAMF, but so far looks good.

I made a couple scripts to do this without deprecated scripting dependencies (Python/perl/Ruby) and without needing to create a package either: setAutomaticLogin.jamf.sh (use in a jamf policy) and setAutomaticLogin.sh (standalone)

I talk a bit more about them here: Automating automatic login for macOS

The account will need to exist before running the script, as it'll check and also verify the password is correct. Hope this helps make things easier for folks!

@brunerd this looks great! You mentioned making the scripts to avoid deprecated scripting dependencies, but the scripts are written in bash. I know bash isn't technically deprecated, but do you know what would be involved in converting the scripts to zsh? I was specifically looking at the Jamf script, and I thought for line 58 it'd need to be changed from i=0 to i=1 (since the first item in a zsh array will be indexed as 1 instead of 0), but I wasn't sure what other changes might need to be made since I don't fully understand the process.

Oh hey I missed this, but here we are 5 months later and bash is still here, in fact I will bet you bash will be around in macOS for a long time, see my post macOS shell games: long live bash if they have csh, ksh, tcsh and dash, they are obviously not stressing about macOS having too many old shells laying around. I know Apple doesn't shy away from breaking things but they'd have to be truly insane to kill bash just because they don't like the new license of v4 and decide to kill the whole thing because v3 is "old". I really don't think that's happening.

But yeah 1 based arrays are a zsh annoyance difference 😁 

I'll wager BASH will be the last thing they remove, but I'm moving what I can to ZSH and SH in the meantime. Man, I wish shellcheck.net would support zsh. :-\\

The above Application doesn't seem to work on Ventura any more and is not supported.  But this script did work.  Can we move the Accepted Solution to this post? Or add it as an alternative post?  It looks like the create user package isn't being maintained anymore. 

If you use VSCode with ShellCheck, you can activate shellcheck in bash mode when prompting it to the second line as comment: 

Did you deploy the script through a policy or pkg from composer? 

We ended up using composer to build the package.