First Boot GUI

[RMahabeersingh]

This is my first post. I'm at a loss and still very very new to the JAMF Suite and shell scripting in general.

rtrouton's First Boot Package Install tool works wonders for installing packages and showing a log. But, it only works for me when using Casper Admin to make the package "Install on Reboot"; is this normal? I'd like to avoid the "Casper Finishing Installing Software" window if possible. Just placing the LaunchDaemon, LaunchAgent, LoginLog, and firstbootpackageinstall.sh files in its respective locations will suppress the login window and launch LoginLog but the postbootpackageinstall.log file is never created.

To give a brief overview of my workflow:
1. AutoDMG to create a clean DMG of OS X along with any available updates.

1. Casper Composer to create a DMG to just place the source files of apps to install on reboot in a common location, /private/tmp/, for example. A short list of apps being installed would include Adobe Reader, Flash, Shockwave, Air, Java, McAfee Security, etc.

2. Casper Imaging and Target Mode Imaging to deploy OS X and installer files in /private/tmp/, and rtrouton's First Boot Package Install tool. Note: PKGs are NOT being added to the fb_installers folder; it's only being used to launch LoginLog and run several shell commands while showing it's progress.

firstbootpackageinstall.sh was modified to install all packages located in /private/tmp/ (done this way to install packages while having the ability to view a log, instead of staring at the Apple boot screen) and also apply any customizations i.e. Wallpaper, Screen Saver, Power Options, etc.

While this works, I'd like to take it one step further by loading a form of some sort at first boot which will contain fields to enter the end user's Real Name, Username, Password, and Custom Asset Tag. This will prevent having to use the OS X Setup Assistant (and all of its annoying Keyboard, Regional, iCloud, Registration, and EULA windows. Additionally, it will allow the creation of a local personalized account, report the asset tag #, and run additional commands to update MS Office apps with a full name. I imagine this custom dialog at first boot to look like the OS X Setup Assistant Create User window with a field for Asset Tag. Can someone please point me in the right direction to accomplish this, or suggest another tool that is capable of doing what I'm after?

The goal is to use Target Mode Imaging to create a fully up-to-date machine and personalize it in as little steps as possible. I'd like all apps to be installed immediately after imaging instead of having to wait for a Policy to kick-off, and for apps that are being installed on reboot, show a log of its progress (hence, the use of LoginLog).

Ideally, packages would install during imaging instead of afterwards but (and I may be wrong), PKGs containing postinstall scripts require that install on reboot.

Thank you for taking the time to read my long post!

[RMahabeersingh]

I should probably add that the "Real Name", Username, and Password would all be much simpler if the computer was bound to Active Directory, which can be done.

This leaves the question of how to prompt for the Asset Tag # to be entered upon login. Would cocoaDialog be the way to go?

Also, my concern with Active Directory is, since all of the computers are MacBooks and they would only be joined to an internal network to perform the AD bind then connected to an external network all other times, are there any repercussions of having a computer bound to AD but never communicates after the initial connection? Will the cached profile remain on the MacBook indefinitely? Possible to change the password for that cached account while not connected to the domain?

[mm2270]

If the MacBooks will never connect back to your internal network at a point after setup, I would not recommend trying to use AD binds and AD accounts. The AD trust gets broken typically after around 2 weeks of non communication to the DCs. That can be adjusted a bit both on the Mac and on the AD side, but I would question what value there would be in using AD accounts on these Macs. If they aren't going to be talking to AD, at least periodically, you kind of lose most of the advantages of using them in the first place, like enforced password rotation, SSO and a few other things.
The accounts will stay cached on the Mac, but as I said, you will be forced to make a lot of adjustments to the policies enforcing communication or you'll have problems down the line.

[Aaron]

Slight tangent here, sorry to derail, but...

@mm2270

The AD trust gets broken typically after around 2 weeks of non communication to the DCs

Where can I find more information on this/change settings on the client side? This might explain the issue I have with some Macs not reporting in to AD when it should.

[calumhunter]

@Aaron pretty sure this is the "password interval"

dsconfigad -passinterval

[mm2270]

Yes, the password change interval is what I was referring to above as @calumhunter mentioned. You can view it by doing: dsconfigad -show
You can also change it with dsconfigad -passinterval <some integer>
I think setting it to "0" actually turns it off completely, but no-one I've ever talked to recommends that, because it represents a security risk. The default is 14, which means 14 days. The Mac will attempt to get a new password from AD, as long as it can communicate with AD. If its out of contact for too long, the computer password stored in the System keychain and what AD has for the computer object get out of sync and then the trust is broken.

[bentoms]

We set it to 0.

We have people that will spend up to 1 month off our lan.

I'm not sure who much of a security issue it is...

[calumhunter]

i've seen some orgs have policies that remove computer accounts from AD if they haven't updated their machine password in x days. So even if you set the passinterval to 0 on your client you might run into problems.
Best to check with your AD team or admin about the implications

[mm2270]

Yep, as @calumhunter points out, even setting the computer password to never rotate can be moot in some instances, because AD itself may be instructed to purge those stale records of machines that haven't communicated after x amount of days.

Also, re: the security risk, I think the thinking is that if a machine hasn't been in use for an extended period of time, its possible said machine is also way out of compliance with regards to patches of vulnerabilities. If the system suddenly comes online say 6 months or a year later and has very old versions of software, it could get exploited, and if you then allow it to connect into your AD environment, it could wreak some havoc. This mostly applies to Windows systems since they still tend to be more affected by malware, but the days of no Mac malware are really behind us at this point.