Identifying FileVault 2 institutional recovery keys on OS X El Capitan

April 10, 2016 Leave a comment

On OS X 10.9.0 – 10.11.x, you can run the following command to verify if a FileVault 2-encrypted Mac is using an institutional recovery key (IRK) as a valid recovery key.

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an IRK, this command will return true.

Screen Shot 2016 04 10 at 4 20 04 PM

Otherwise it will return false.

Screen Shot 2016 04 10 at 4 03 57 PM

As part of the release of OS X 10.11.2, a new function was added to fdesetup‘s hasinstitutionalrecoverykey verb. Now, in addition to identifying whether or not FileVault 2 on a particular Mac has an institutional recovery key, a new -device option has been added which outputs a SHA-1 hash in hexadecimal notation of the IRK’s public key. This helps Mac admins answer two questions about institutional recovery keys:

  1. Is an IRK being used as a valid recovery key on this Mac?
  2. If an IRK is in use, which one is being used?

The -device option needs to be supplied with an identifier for the encrypted drive in question. This can be in the form of a BSD device name ( /dev/diskX ), the mount path ( /Volumes/Macintosh HD or ), or a UUID for the Logical Volume or Logical Volume Family of a CoreStorage volume.

To display the hash for an IRK’s public key on the Mac’s boot volume, run the command below with root privileges:

fdesetup hasinstitutionalrecoverykey -device /

It should output the hash of the IRK’s public key in hexadecimal notation.

Screen Shot 2016 04 10 at 4 19 21 PM

This value should be consistent across all FileVault 2-encrypted Macs which are using this IRK, so it should help Mac admins identify if a particular Mac is set up with the correct FileVault 2 institutional recovery key (or keys) used by their shop.

To assist with this, I’ve written a script to report the hash of the IRK’s public key. For more details, see below the jump.

Read more…

DeployStudio 1.7.3 updated from build 160401 to build 160404 to address Active Directory binding issue

April 6, 2016 Leave a comment

Following the release of DeployStudio 1.7.3, I discovered and reported a problem with the Active Directory binding to the DeployStudio folks.

To address the issue, they released a new version of DeployStudio but didn’t change the version number from 1.7.3. Instead, the new DeployStudio 1.7.3 has a different build number:

  • DeployStudio 1.7.3 build 160401 – released April 1st, 2016
  • DeployStudio 1.7.3 build 160404 – released April 4th, 2016

If you have already installed DeployStudio 1.7.3, I recommend checking to see which build you have installed. If needed, upgrade both your DeployStudio server and DeployStudio boot sets to DeployStudio 1.7.3 build 160404.

For more details on identifying the different builds of DeployStudio 1.7.3, see below the jump.

Read more…

DeployStudio 1.7.3 using configuration profiles for Active Directory binding on OS X El Capitan

April 2, 2016 1 comment

As part of the release of DeployStudio 1.7.3, DeployStudio is now using an unsigned configuration profile to manage binding to an Active Directory domain for Macs running OS X 10.11.x.

Screen Shot 2016 04 02 at 5 00 04 PM

Screen Shot 2016 04 02 at 5 00 24 PM

This undocumented change currently appears to apply only to Macs running OS X El Capitan. Earlier versions of OS X are still being bound to AD using Apple’s dsconfigad tool. For more details, see below the jump.

Read more…

Checking XProtect and Gatekeeper update status on Macs

March 28, 2016 6 comments

As part of making sure that XProtect and Gatekeeper are providing up-to-date protection, it can be worthwhile to see when your Mac received the latest updates from Apple for both XProtect and Gatekeeper. As both are background processes, as well as also receiving Config Data updates silently in the background, it’s not always obvious when updates have been applied.

To assist with this, I’ve written a couple of scripts to report the last time that Gatekeeper and XProtect have been updated on a particular Mac. For more details, see below the jump.

Read more…

Running processes in OS X as the logged-in user from outside the user’s account

March 25, 2016 1 comment

One challenge that can crop up for Mac admins is the problem of running a script or other tool with root privileges and using it to launch and run another tool, script or application as if the logged-in user had launched it. An example of this would be installing Dropbox using an installer package, then launching the Dropbox application as the logged-in user as a post-installation task. One reason to do so would be to give the user the opportunity to sign into their Dropbox account.

To accomplish this task, Apple has provided functionality in the launchctl tool.

For 10.9.x and earlier, launchctl‘s bsexec function was used for this purpose. bsexec allows you to start a process like a tool, script or application in a specific context. One way to get the correct context for the logged-in user is to identify the process identifier (PID) for the loginwindow process associated with the logged-in user, which can be accomplished by using the command below:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep logged_in_username_here | grep -v "grep" | awk '{print $2}'

For example, if I logged in with an account named username, running the command shown below should provide the PID for the username account’s loginwindow process:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep username | grep -v "grep" | awk '{print $2}'

Screen Shot 2016 03 25 at 1 08 11 PM

 

Once the PID has been identified, it can be used to identify the context that I want to start a process in. For example, the commands below can be run with root privileges to first identify the correct PID for the username account’s loginwindow process, then launch Safari as the username account using the open command:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep logged_in_username_here | grep -v "grep" | awk '{print $2}'
launchctl bsexec PID_number_here open "/Applications/Safari.app"

Screen Shot 2016 03 25 at 1 17 19 PM

 

Screen Shot 2016 03 25 at 1 19 46 PM

 

When we check the process list for which account is was launched from, the Safari process should show up as being run by the username account.

Screen Shot 2016 03 25 at 1 18 37 PM

 

If you wanted to automate opening Safari as the logged-in user, you could run a script like the one below with root privileges:

Starting in OS X Yosemite, Apple made a number of changes to the launchctl tool and added a new asuser function. The asuser function is designed to take the place of the bsexec function, in the context of starting processes in the context of a specific user account. This makes it easier, as you now just need to figure out the username and do not have to figure out the PID of the user’s loginwindow process.

You can identify the user by either the user’s account name, or by the account’s UID. One way to identify an account’s UID is to use the id command as shown below:

id -u username_goes_here

To continue with the example of opening Safari, you can run the commands below to first identify the correct UID, then launch Safari as the username account using the open command:

id -u username_goes_here
launchctl asuser username_uid_goes_here open "/Applications/Safari.app"

 

Screen Shot 2016 03 25 at 2 09 27 PM

Screen Shot 2016 03 25 at 2 07 21 PM

 

Screen Shot 2016 03 25 at 2 49 03 PM

If you wanted to automate opening Safari using the logged-in user’s UID, you could run a script like the one below with root privileges:

As mentioned earlier, you can also use just the account name with launchctl‘s asuser function. In that case, you can run the command below to launch Safari as the username account using the open command:

launchctl asuser username_goes_here open "/Applications/Safari.app"

If you wanted to automate opening Safari using the logged-in user’s account name, you could run a script like the one below with root privileges:

Creating a DNAStar Lasergene 13.x installer

March 17, 2016 4 comments

As part of my day job, I support some medical research software packages that most Mac admins have likely never heard of. One of these software packages is DNAStar‘s Lasergene software suite. Up until now, this software used an Installer VISE installer, which required me to completely repackage the software for deployment. However, as of Lasergene 13.x, DNAStar has switched to using Bitrock’s InstallBuilder for the Lasergene installer. This tool does not produce standard installer packages, but InstallBuilder installer applications do support installation and uninstallation via the command line. That allows me to run an installation or uninstallation of the Lasergene suite by using the commands shown below:

To install a copy of DNAStar Lasergene which uses a network license server:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --mode unattended

To install a copy of DNAStar Lasergene which uses an individual license code:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --dnastarProductKey XXXXX-XXXXX-XXXXX

To uninstall DNAStar Lasergene:

"/Applications/DNASTAR/Uninstall Lasergene 13.app/Contents/MacOS/installbuilder.sh" --mode unattended

While this installation method is still not ideal, I can at least script it. That makes it an improvement over the hand-crafted installers I previously had to create for Lasergene.

Unfortunately, there is a quirk of Lasergene’s installation process which carries over from the Installer VISE days, which is that the Lasergene installer assumes that the account running the installation is going to be the owner of the application. So if you install Lasergene as your local admin, that may mean that your users aren’t able to run the Lasergene applications because they may not have permission to run the applications or access one or more of the application data files.

To address both the installation and permissions issues, I was able to create an installer using this method that handles both the installation and then fixing the permissions as a post-installation task. For more details, see below the jump.

Read more…

Speaking at X World 2016

March 17, 2016 3 comments

I’ll be speaking at X World 2016 in Sydney, Australia, where I’m planning to do a couple of sessions. This is the first time I’ve had the pleasure of traveling to Australia, so I’m looking forward to this opportunity to meet and learn from the Australian Mac admin community.

X World 2016 will be held at the University of Technology Sydney (Broadway City Campus) and is scheduled for the week of July 6th. Hope to see you there!

Categories: X World 2016
Follow

Get every new post delivered to your Inbox.

Join 290 other followers

%d bloggers like this: