Archive

Archive for April, 2016

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…

%d bloggers like this: