Deleting and recreating the login keychain via Self Service

In Andrina Kelly's great JNUC 2013 talk, she included a handful of examples of how to use Self Service to give customers the ability to self-solve recurring issues. One of the examples is recreating the login keychain. Her script is on Github here. It gets the currently logged-in user, detects their login keychain, then deletes it and creates a new one. This requires the user's password, which the script prompts for using cocoaDialog.

I've wanted to get something similar going at my workplace, but I've been trying to avoid deploying cocoaDialog to machines as all of our machines already have jamfHelper and AppleScript available. It seems like overkill to install yet another dialog tool if I can get the ones already there to do what I want.

Based on my previous work (which is in turn based on Elliot Jordan's) I decided to utilize jamfHelper and AppleScript to do the heavy-lifting of prompting for the password and passing it along.

From the user's point of view, it will work like this:

They'll open Self Service, and find the Fix Keychain policy (or whatever you want to call it).


Happy Holiday Time

Hey y'all, you may have heard that some holiday of some kind is coming up soon. Whether or not you celebrate I hope you have a wonderful end of the year and enjoy some kind of festivities that bring you joy. If there aren't festivities this time of year that bring you joy, maybe these pictures of my cat Charlie in festive kitty things will bring a smile to your face.





One way to update NoMAD

Now that I have a few people "in the wild" (nomads, if you will…) using NoMAD in our environment, I needed to find a way to install updates that played nicely with the app as its running. If you install and have NoMAD create its LaunchAgent in the user Library (as opposed to the system Library) the LaunchAgent needs to be unloaded prior to running the installer for the new version. Part of the fun of this, especially if managing with an MDM like Jamf, is that Jamf runs as root while the LaunchAgent is in the user's Library. You have to tell Jamf to run launchctl in the correct user context for action to happen in the user's environment.

Fortunately for me, this is something I've been coming across quite a bit recently and have learned a few handy tricks from other Mac admins out there. I knew based on my manual updates/testing that the order of operations needed to be something like this:

  1. Unload ~/Library/LaunchAgents/com.trusourcelabs.NoMAD.plist
  2. Run installer.
  3. Load ~/Library/LaunchAgents/com.trusourcelabs.NoMAD.plist

I figured that this would be best accomplished running one script, with the script itself calling a second policy in the JSS on a custom trigger that contains the installer .pkg. 

A 10000 ft view of the workflow goes something like this:

  1. update_NoMAD.sh runs on policy1, scoped to computers with NoMAD installed.
  2. update_NoMAD.sh triggers policies using update_nomad, this policy2 contains the installer pkg.
  3. update_NoMAD.sh finishes running and at the end NoMAD has quietly closed the old version, updated, and launches the new version.

EA for detecting if a Mac has a Touch Bar



Now that we have some of the new late-2016 MacBook Pros, we want to be able to see at a glance how many of them are in a fleet. After some back and forth with Ross we came up with a relatively simple extension attribute for Jamf Pro that looks for the Touch Bar Agent as an indicator of a machine being a Touch Bar Mac.


We ran into a caveat with the above EA, though; if a machine has Touché or some other Touch Bar emulator on it the TouchBarAgent and ControlStrip will activate (regardless of the physical presence of the Touch Bar), which would skew reporting.

We went through a few ideas until Ross finally settled upon the following:


A Smart Group based on this criteria may be useful if you want to enforce any policies for the Touch Bar via Configuration Profile, or any first-run settings like putting the screen saver shortcut in the Control Strip. It could also be used to scope fun stuff to your Touch Bar Macs, like TouchSwitcher (shown above), Pac-Bar, Dino, or Touch Bar Piano. Because after all, if you're paying more for the Touch Bar you might as well get some use out of it.

Revisiting Custom QuickAdd Packages

With new Apple hardware now available on the market, I've found myself revisiting alternative methods for provisioning and re-provisioning Mac hardware. Interest in "non-imaging" provisioning methods has ebbs and flows in the MacAdmin community, and seems to be at the forefront yet again due to the reading of tea leaves and testing old workflows on new hardware that can (and might in the future) have unexpected and undesirable results. Last year I started toying with the idea of a customized QuickAdd package when it was looking like DEP wasn't a possibility at my old shop. New Macs (especially brand new hardware models) often come with forked OS builds that accommodate new features that the OS installer from the App Store has yet to include. If you buy a new machine, then wipe the shipped OS and install your own (or even delete the entire drive and all partitions), you may find yourself gambling when you don't need to.

Anyway. I'm not here to stern-parent-stare you, other people can do that. ಠ_ಠ

Back to the QuickAdd package.

So the build of the QuickAdd package changed slightly with JSS/Jamf Pro version 9.9, which included a new location of the jamf binary to behave well with recently-added SIP restrictions. Jamf also changed around the components of the QuickAdd package and binary installer. As of 9.96, it looks something like this:



Because of the binary moving to /usr/local/, the  postinstall script in the QuickAdd package is slightly different as well.

Fave Friday

Getting AD User Details with NoMAD and Extension Attributes

Although NoMAD is still in it's development/beta stages, it is already proving to be an incredibly handy tool for lots of organizations. Tom Bridge summed it up pretty nicely:
It feels a little silly to be so excited about something so simple as NoMAD, but there’s nothing simple about NoMAD behind the scenes. It’s doing a lot of heavy lifting that you’d usually need binding to accomplish. Preventing the complication of binding simplifies your Mac environment. On the Macadmins.org Podcast recently, we spent an hour talking with Joel Rennich about just that.
 

From the device user's perspective, NoMAD is a menubar utility that shows password expiration and provides handy one-click access to things like Self Service ("Get Software"), a help desk portal or Bomgar session (configurable in the "Get Help" option), and much more.

Settings can be put in place with a robust list of preference keys, and these can be applied with Configuration Profiles. Once the preferences are set and an AD user account has been signed in, details of the account a written to a preference file called com.trusourcelabs.nomad.plist, located in the logged-in user's Preferences.

If you run defaults read com.trusourcelabs.nomad.plist on a computer with NoMAD installed and configured, you'll get some fun details about the account, including some information that will be presented much like the following: