Script to run only on new account creation

[sgoetz]

I am wondering is it possible to create a script that will only run when a new account is created on the machine. This script will setup a bunch of stuff for the user like Wifi, Admin Rights, Enabling the user for FileVault. The machines are domain bound, so the idea will be that the machine will get imaged by our desktop team and hand the machine to the user. The user will plug into the network and log in with their AD credentials. This will create teh account on the machine for the first time. Thats when I need the script to run.

[emily]

I have a script that runs Once Per Computer on the Login trigger that adds that first logged-in user to the admin group on the machine. So theoretically you can do what you're asking about. The trick is to log in with that user's credentials first, without logging in as another account beforehand. Depending on your workflow that may be difficult (or not!). It works best for us for new hires when we have the pre-set credentials at our disposal.

[mm2270]

There is also the Once per user frequency in policies that may help here, which can be paired up with the Login trigger. Keep in mind though that it truly is 'once per user' globally. See here for more information on that.
As long as a user isn't typically logging in on different Macs under the same user account, that may work. There won't be any issue with JSS connectivity since you mentioned they will be wired into your network.

[hkabik]

Put the script in the login items of the User Template? Have it delete itself at the end of the script?

[mm2270]

@hkabik I had also considered mentioning this, and also discussing a global LaunchAgent to do the work, but the realized this won't work since those don't run as root. If @sgoetz is looking to do things like call policies with the jamf binary or enable FileVault (sudo fdesetup, etc) then those commands will fail since that would run as the user and not in a root context.
Using a LaunchDaemon would get around that problem, but then those run at startup typically, and not only when someone logs in. I've used LaunchDaemon's in the past to simulate a LaunchAgent, but its not the easiest nor most reliable thing to do.

[hkabik]

Good point!

So, it's round about and no where near immediate but... have a script in login in items of the User Template that writes a specific file to the drive then self deletes.

Have a smart group based on the existence of that file.

Have a policy trigger for that smart group that runs your necessary configuration then deletes that file.

Just a thought... surely an overly complicated one.

[russeller]

Along what @emilykausalik said if you do have a local account you don't want the "once per computer" policy running on at login you can use the exclude tab in the scope of the policy to ignore the name of specific accounts so the policy doesn't run for the wrong user.

[bentoms]

@sgoetz Are all users admins? Or just a group of them?

If so, you should be able to have them set as admins via the AD plugin.

For the other stuff, you could run LaunchAgents in ~/Library/LaunchAgents/ that trigger scripts elsewhere.

These scripts could check for admin membership & run, their last action would be deleting the calling LaunchAgent in ~/Library/LaunchAgents/.

[cdev]

I'd think about having a simple LaunchAgent that calls a script that self-destructs after running. The script could even call a custom trigger from the JSS to apply a "first-login" set of tweaks/changes that affect only the currently logged-in user.