Quantcast
Channel: rtrouton – Der Flounder
Viewing all 764 articles
Browse latest View live

Performing password resets on Yosemite with unsetpassword

$
0
0

One issue that can crop up for Mac admins is the problem of “I don’t want to know my users’ passwords, but I need to set up their accounts.” When setting up accounts from a directory service like Active Directory or Open Directory, this problem can be avoided because it’s relatively easy to set up a Mac to use an account from a directory service without ever needing to know the user’s password.

The situation is different for local users with admin privileges on a machine though, as the Mac admin has two ways to proceed:

  1. Set a password on the local account, then give the password to the user.
  2. Set the password of the local account to be blank.

The first approach means that the Mac admin knows the password, which is a security issue. The second approach means that there’s no password at all and the user may opt to keep it that way, which is a greater security issue.

To help address this issue, the new unsetpassword tool in Yosemite allows an admin to set up a new local account with admin rights, then remove the account’s existing password and require a new one be set on the next login.

The unsetpassword tool does not have a man page. To learn how it works, run the following command in the Terminal:

unsetpassword --help

Screen Shot 2014-12-19 at 9.32.45 PM

One thing to be aware of is that while the password is removed, the account’s login keychain is not and will still be set to use the previous password. On login, the user will be prompted to create a new keychain.

Screeny Video Dec 19, 2014, 9.24 8091

To demonstrate how to use unsetpassword, I’ve made a video showing the following process:

  1. Running unsetpassword on the logged-in account
  2. The Mac shutting down
  3. Booting the Mac
  4. Setting a new password on the next login
  5. Choosing to create a new keychain

Note: The video has been edited to artificially reduce the amount of time it took to boot after the shutdown. Run time of the pre-edited video was 2 minutes, forty seconds.



fdesetup sync – fdesetup’s misunderstood command

$
0
0

Apple’s fdesetup tool includes a number of commands, including fdesetup sync. In the fdesetup manpage, sync is listed with the following description:

Synchronizes information from Open Directory to FileVault

Screen Shot 2014-12-21 at 10.55.50 AM

Since the description is brief and vague, misunderstandings about what fdesetup sync‘s functions were almost inevitable. Based on my research, here’s fdesetup sync does:

1. Automate the disabling of FileVault 2-enabled accounts

fdesetup sync checks with a Mac’s directory service (Active Directory, Open Directory, OpenLDAP, etc.) to see which accounts have been removed. If an account has been removed from the directory service, running fdesetup sync on an encrypted Mac will automatically remove the account from the list of FileVault 2 enabled accounts. The sync only affects the account’s FileVault 2 status and will not remove the account or account home folder from the Mac.

An important thing to know is that fdesetup is only checking to see if the account is there or not there. It’s unable to determine if an account has been set to be disabled, so if an account has been disabled but the account is still there, fdesetup sync will not change the FileVault 2 status of the account in question.

2. Automate the update of accounts’ user pictures

fdesetup sync checks with a Mac’s directory service (Active Directory, Open Directory, OpenLDAP, etc.) to see which accounts have user pictures associated with the account. If an account’s user picture is updated on the directory service, running fdesetup sync will allow the updated user picture to also be displayed on the FileVault 2 pre-boot login screen.

In many cases, this information will also have been updated automatically by the OS without the need for fdesetup sync to be run.

With those capabilities in mind, here’s two common misunderstandings I’ve seen or heard of in connection with fdesetup sync:

1. fdesetup sync updates the passwords at the pre-boot login screen

It does not. Based on my research, it appears that this job may be handled by opendirectoryd’s FDESupport module. I haven’t confirmed that with Apple though, so for the moment, treat this information about FDESupport as being my opinion rather than a fact.

2. fdesetup sync can automatically add accounts to a FileVault 2-encrypted Mac.

It does not, and the manpage for fdesetup is explicit about this point elsewhere in the manpage.

Screen Shot 2014-12-21 at 11.59.00 AM

NOTE: The manpage for fdesetup has a typo where it refers to a fdesetupsyncusers” command. This is actually referring to fdesetup sync.


Managing OS X’s automatic security updates

$
0
0

On Monday, December 22nd, Apple released OS X NTP Security Update 1.0 to fix a vulnerability in ntpd. What caught many folks off-guard was that this update installed itself in many cases, without action or authorization by the human using the Mac in question.

Security Update Installed notification

This marked the first time Apple has used its capability to push and automatically install an OS X security update, though the actual capability has been in OS X since OS X 10.8.x. Apple has used a similar capability in OS X 10.9.x and later to push updates for Apple’s XProtect and Gatekeeper.

So how did Apple make OS X NTP Security Update 1.0 install automatically? See below the jump for more details.

The key change appears to be some additional keys that appeared in the Software Update catalog with the NTP update’s entry.

<key>AutoInstallDelay</key>
<integer>0</integer>
<key>CriticalUpdate</key>
<true/>

Screen Shot 2014-12-23 at 4.39.59 PM

Credit to @mikeymikey for discovering these keys:

These keys don’t appear with other software updates available in the Software Update catalog for Mountain Lion, Mavericks or Yosemite. Based on the naming, it looks like the NTP updates were marked as critical updates where automatic installation was set to occur as soon as possible.

Apple has published a KBase article that explains in general how the automatic updates will work. If you would like to always manually download and install security updates, the KBase article also describes how to turn them off:

1. Open System Preferences

2. Click on the App Store icon (Software Update in Mountain Lion)

Screen Shot 2014-12-23 at 8.58.07 PM

3. De-select the following options

  • Automatically check for updates
  • Download newly available updates in the background
  • Install system data files and security updates

Screen Shot 2014-12-23 at 5.09.53 PM

One thing to be aware of is that disabling the automatic check for updates and installation will also disable updates from Apple for XProtect as well as Gatekeeper.

If you want to be notified of automatic security updates and choose when to install them, here’s how to do that:

1. Open System Preferences

2. Click on the App Store icon (Software Update in Mountain Lion)

Screen Shot 2014-12-23 at 8.58.07 PM

3. Select the following options:

  • Automatically check for updates
  • Download newly available updates in the background

4. De-select the following options:

  • Install system data files and security updates

Screen Shot 2014-12-23 at 8.28.11 PM

This option will cause you to be notified of security updates like the NTP update with the option of installing them.

Screen Shot 2014-12-23 at 5.01.47 PM

However, this option will also disable updates from Apple for XProtect as well as Gatekeeper. These options do not show up as available updates in Software Update and are designed to auto-install.

If you want to have automatic security updates, here’s how to do that:

1. Open System Preferences

2. Click on the App Store icon (Software Update in Mountain Lion)

Screen Shot 2014-12-23 at 8.58.07 PM

3. Select the following options:

  • Automatically check for updates
  • Download newly available updates in the background
  • Install system data files and security updates

Screen Shot 2014-12-23 at 4.53.59 PM

This option will cause security updates like the NTP update to be automatically installed, along with updates from Apple for XProtect as well as Gatekeeper.

Screen Shot 2014-12-23 at 5.18.09 PM

These options are set by default by the OS, so most home users and many enterprise users likely already have these settings in the App Store preferences.

Forcing automatic security updates to install

If you need to force an automatic security update to install on Mountain Lion, Mavericks or Yosemite, run the following command with root privileges:

softwareupdate --background-critical

The –background-critical function is actually an undocumented softwareupdate function, so it’s not listed when you run either softwareupdate –help or when you check the softwareupdate manpage.

As mentioned above, one important thing to know about forcing automatic security updates to install is that the Software Update function on the system in question must be set to automatically check for updates and to install security updates. Without those settings, automatic security updates (including XProtect and Gatekeeper updates) will not install.


Adding a self-signed Casper Root CA as a trusted root

$
0
0

Since Elliot Jordan’s presentation at JAMF Nation User Conference 2014, I’ve started using AutoPkgr in combination with Shea Craig’s JSSImporter to automatically package and upload a number of software packages to my Casper servers.

Having AutoPkgr handle this task has been great, but I’ve had to do some additional work to make sure that JSSImporter was OK with Casper using SSL certificates issued by its own internal certificate authority instead of by a third-party external certificate authority like Verisign. On top of that, the urllib3 library used by JSSImporter added a new warning that is triggered by HTTPS requests that use an certificate that can’t be validated. Since the Casper server was signing its own certificates using its own internal certificate authority, this warning was being triggered on every AutoPkg recipes’ run, which sometimes resulted in interesting emails like the one below.

Screen Shot 2014-12-24 at 9.26.24 AM

I could have installed the Casper agent on the VM that I was using to host AutoPkgr, which would have installed the root certificate for the Casper server’s internal certificate authority. However, I didn’t necessarily want to have Casper manage the VM as that would have consumed one of my available Casper licenses on a machine that didn’t need management.

However, I did want to get the root certificate for the Casper server’s internal certificate authority installed on the VM. That would allow the Casper server’s SSL certificate to be recognized as a validated certificate and fix the issues I was having with not having a validated certificate.

For details on how I fixed this, see below the jump.

If you’re using a Casper JSS’s built-in certificate authority, here’s how to download and install the built-in CA’s root certificate on your Macs.

1. Log into your Casper server.

2. Go to Management Settings

Screen Shot 2014-12-23 at 8.22.29 AM

3. Select Global Management

4. In the Global Management settings, select PKI

Screen Shot 2014-12-23 at 8.23.23 AM

5. In the PKI settings, click on the Download CA Certificate button.

Screen Shot 2014-12-23 at 8.24.18 AM

This will download a copy of the built-in CA’s root certificate as a .pem file

Screen Shot 2014-12-23 at 8.32.11 AM

Once you have the .pem file downloaded, you can import it into the System keychain using the command line or via Keychain Access.

Adding a trusted root via Keychain Access

1. Log into the Mac using an account that has admin privileges

2. Verify that you have the downloaded .pem file available

3. Open Keychain Access

Screen Shot 2014-12-24 at 9.55.24 AM

4. Select the System keychain in Keychain Access.

Screen Shot 2014-12-24 at 9.55.33 AM

5. Double-click on the .pem file

6. In the Add Certificates window that appears next, verify that the selected keychain is System and then click the Add button.

Screen Shot 2014-12-23 at 8.33.00 AM

7. Authenticate when prompted to modify the System keychain.

Screen Shot 2014-12-23 at 8.33.20 AM

8. When prompted, click the Always Trust button.

Screen Shot 2014-12-23 at 8.33.31 AM

9. Authenticate when prompted to modify the System Certificate Trust Settings.

Screen Shot 2014-12-23 at 8.34.29 AM

10. Verify that the imported root certificate is now showing up as trusted for all users.

Screen Shot 2014-12-23 at 8.35.12 AM

Once the root certificate has been installed and set to be trusted, the Casper server’s certificate should be recognized by AutoPkgr and the urllib3 library as a validated SSL certificate.


Managing automatic installation of ConfigData and security software updates on Yosemite

$
0
0

As mentioned previously, the updates for XProtect’s blacklist moved into Apple’s software update feed starting in Mavericks. Gatekeeper updates are also included in the software update feed on Mavericks and Yosemite, so both XProtect and Gatekeeper updates are being delivered to machines using the same delivery mechanism.

To help distinguish Gatekeeper and XProtect updates from other updates in the software update feed, Apple marks them as being ConfigData updates. For more details on this and how you can manage their automatic installation, see below the jump.

To illustrate, here’s an example of a Gatekeeper update from the Yosemite software update catalog:

Here’s an example of an XProtect update:

Marking these updates as ConfigData cues the App Store to not display these as available software updates in the App Store’s list of software updates. These updates are meant to be under Apple’s control and to be as invisible as possible.

Meanwhile, an automatically installed software update like OS X NTP Security Update 1.0 shows up as a normal software update, but has extra keys in its catalog listing to mark it as a critical update whose automatic installation is set to occur as soon as possible.

<key>AutoInstallDelay</key>
<integer>0</integer>
<key>CriticalUpdate</key>
<true/>

For those interested in examining for themselves, the Yosemite software update catalog is available for download from the following link:

http://swscan.apple.com/content/catalogs/others/index-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog

Along with the ConfigData and security updates being marked differently in the software update catalog, it’s possible to manage them separately by setting the correct values in /Library/Preferences/com.apple.SoftwareUpdate.plist. To enable XProtect and Gatekeeper updates to be installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate ConfigDataInstall -bool TRUE

To stop XProtect and Gatekeeper updates from being installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate ConfigDataInstall -bool FALSE

To enable automatic security updates to be installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate CriticalUpdateInstall -bool TRUE

To stop automatic security updates from being installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate CriticalUpdateInstall -bool FALSE

Because these values can be managed separately, it’s possible to set XProtect and Gatekeeper updates to be installed automatically while allowing the user to decide when to install security updates. To enable this, run the following commands with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate ConfigDataInstall -bool TRUE
defaults write /Library/Preferences/com.apple.SoftwareUpdate CriticalUpdateInstall -bool FALSE

In this scenario, the App Store preferences in System Preferences will have the Install system data files and security updates checkbox unchecked.

Screen Shot 2014-12-27 at 5.47.52 PM

The reason for this is that both ConfigDataInstall and CriticalUpdateInstall‘s values must be set to be TRUE in order for the Install system data files and security updates checkbox to be checked in the App Store preferences.

Screen Shot 2014-12-27 at 6.09.23 PM

One important thing to know about forcing automatic installation of ConfigData and security updates is that the Software Update function on the system in question must be set to automatically check for updates. Without the automatic checks, ConfigData and security updates will not install.

To control the automatic update check using the softwareupdate command line tool, run the following commands with root privileges:

To enable the automatic update check:

softwareupdate --schedule on

To disable the automatic update check:

softwareupdate --schedule off

You can also manage this using the defaults command line tool. To enable the automatic update check using defaults, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool TRUE

To disable the automatic update check using defaults, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool FALSE

2014 in review

$
0
0

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here's an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 1,000,000 times in 2014. If it were an exhibit at the Louvre Museum, it would take about 43 days for that many people to see it.

Click here to see the complete report.


Managing automatic App Store and OS X update installation on Yosemite

$
0
0

To go along with the automatic installation of security updates, there are also options in Yosemite’s App Store preferences in System Preferences to have your Mac automatically install available updates for OS X and updates for applications from the Mac App Store. For more details, see below the jump.

Apple has published a KBase article that explains in general how the automatic updates work. The first time updates are available on your Mac, OS X will prompt you with the choice of turning on the Always Update option.

always_update

When the Always Update option is selected, the following options should show up as checked in the App Store preferences in System Preferences:

  • Install app updates
  • Install OS X updates

Screen Shot 2014-12-27 at 6.39.14 PM

These options can also be selected by going into the App Store preferences in System Preferences and checking the correct checkboxes. When these options are checked in the App Store preferences, the Mac will check for new updates overnight and install them. If a reboot is needed as part of installing an update, the Mac will reboot automatically.

It’s possible to manage these settings by setting the correct values in /Library/Preferences/com.apple.commerce.plist. To enable app updates from the Mac App Store to be installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.commerce AutoUpdate -bool TRUE

To stop app updates from the Mac App Store from being installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.commerce AutoUpdate -bool FALSE

To enable OS X updates to be installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.commerce AutoUpdateRestartRequired -bool TRUE

To stop OS X updates from being installed automatically, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.commerce AutoUpdateRestartRequired -bool FALSE

Because these values can be managed separately, it’s possible to set App Store updates updates to be installed automatically while allowing the user to decide when to install OS X updates. To enable this, run the following commands with root privileges:

defaults write /Library/Preferences/com.apple.commerce AutoUpdate -bool TRUE
defaults write /Library/Preferences/com.apple.commerce AutoUpdateRestartRequired -bool TRUE

In this scenario, the App Store preferences in System Preferences will have the Install app updates checkbox checked and the Install OS X updates checkbox unchecked.

Screen Shot 2014-12-29 at 3.52.36 PM

One important thing to know about forcing automatic installation of app and OS X updates is that the Software Update function on the system in question must be set to automatically check for updates. Without the automatic checks, app and OS X updates will not automatically install.

To control the automatic update check using the softwareupdate command line tool, run the following commands with root privileges:

To enable the automatic update check:

softwareupdate --schedule on

To disable the automatic update check:

softwareupdate --schedule off

You can also manage this using the defaults command line tool. To enable the automatic update check using defaults, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool TRUE

To disable the automatic update check using defaults, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool FALSE

Hiding user accounts in Yosemite

$
0
0

On December 8th, 2014, Apple posted a KBase article showing a way to hide user accounts in Yosemite that was different than the methods available in previous versions of OS X.

In Yosemite, you can add an IsHidden user attribute to the user’s account record and set a specific value in order to hide or unhide the account:

  • Hide: Set the IsHidden user attribute’s value to 1
  • Unhide: Set the IsHidden user attribute’s value to 0

It’s also possible to unhide a hidden account by deleting the IsHidden user attribute from the user’s account record. For more details, see below the jump.

The dscl command line tool should be used to to set the IsHidden user attribute. To hide a user account, run the command below with root privileges:

dscl . create /Users/username_goes_here IsHidden 1

Screen Shot 2014-12-31 at 3.15.11 PM

The account in question should disappear from the Users & Groups preference pane in System Preferences.

Screen Shot 2014-12-26 at 12.45.31 PM

To unhide the account, run the command below with root privileges:

dscl . create /Users/username_goes_here IsHidden 0

Screen Shot 2014-12-26 at 12.47.26 PM  

As mentioned previously, an account can also be un-hidden by deleting the IsHidden user attribute. To do this, run the command below with root privileges:

dscl . delete /Users/username_goes_here IsHidden

Screen Shot 2014-12-26 at 12.47.04 PM

The account in question should now be visible in the Users & Groups preference pane in System Preferences.

Screen Shot 2014-12-26 at 12.44.32 PM

To further hide a user account, the account’s home directory can also be moved from /Users to a new location.

Screen Shot 2014-12-26 at 1.44.23 PM



Oracle’s Java 8 and Mac OS X 10.7.x

$
0
0

With Oracle’s Java 8, there’s been some confusion as to whether Java 8 runs on Mac OS X 10.7.5. This issue was lent additional urgency in the wake of Oracle’s announcement that they will begin auto-updating Java 7 users to Java 8 starting in January 2015.

The root of the confusion lies in the fact that Oracle has listed two different sets of system requirements on their website for Macs running Java 8 on Mac OS X.

The first set is available via Oracle’s general Java system requirements page. This page states that Java 8 requires the following:

  • Intel-based Mac running Mac OS X 10.8.3+, 10.9+
  • Administrator privileges for installation
  • 64-bit browser

The second set is available via the Java download page for Mac OS X. The system requirements linked from the download page state that Oracle’s Java requires the following:

  • Intel-based Mac running Mac OS X 10.7.3 (Lion) or later.
  • Administrator privileges for installation
  • 64-bit browser

In short, the question of Java 8 support for 10.7.x depended on which system requirement page was correct. For more details, see below the jump.

Based on my testing, it appears that the current version of Java 8 (Java 8 Update 25) installs on Mac OS X 10.7.5 without issues.

Screen Shot 2015-01-10 at 10.48.10 AM

Following installation, I tested on a 10.7.5 Mac against the following sites:

My work’s Juniper VPN (which uses a signed Java applet)

Oracle’s Java Test page: https://www.java.com/en/download/help/testvm.xml

Screen Shot 2015-01-10 at 11.22.57 AM

Java Tester’s Java Version page: http://javatester.org/version.html

Screen Shot 2015-01-10 at 11.31.02 AM

In all three cases, the Java applets on those sites launched and worked without issue using Java 8 Update 25 (though the javatester.org applet needed to be whitelisted.)


Yosemite’s FileVault 2 pre-boot recovery options

$
0
0

One of the changes that Apple has introduced with Yosemite is a more straightforward way to recover from login problems at the FileVault 2 pre-boot login screen.

When a FileVault 2-encrypted Mac sits for more than a minute with an account selected at the FileVault 2 pre-boot login screen, a message like the one below should appear:

If you’re having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start it up in the Recovery OS.

Screen Shot 2015-01-15 at 1.40.50 PM

If the instructions are followed, the Mac will boot from the Mac’s recovery partition on the next startup and go into a Reset Password wizard.

In the Reset Password wizard, there are currently three options available.

  1. I forgot my password
  2. My password doesn’t work when logging in
  3. My keyboard isn’t working when typing my password to login

Screen Shot 2015-01-16 at 8.20.23 AM

Each option will do different things, so let’s take a look at each. For more details, see below the jump.

I forgot my password

The I forgot my password option is most useful to folks who had chosen the option when enabling FileVault 2 to use their Apple ID to unlock the disk and reset your password.

screen-shot-2014-10-25-at-11-33-13-pm

If the user in question had set up their Apple ID to unlock the disk and reset their password, the following options are available:

A. Log in with your Apple ID

Screen Shot 2015-01-16 at 8.20.49 AM

B. The Reset Password wizard will check the locked disk.

C. The Mac will communicate back with Apple to match the Apple ID against the FileVault 2 recovery key that was stored with Apple.

Screen Shot 2015-01-16 at 8.21.13 AM

D. You’ll be prompted to reset your account’s password to a new one.

Screen Shot 2015-01-16 at 8.21.45 AM

Note: This password reset process is designed to reset the password of a local account. If the password reset process is run against a network account which has been enable for FileVault 2, the password sync may be broken between the network account and the directory service that manages the account.

E. You’ll be notified that your password has been reset and that you can now reboot and log in at the FileVault 2 pre-boot login screen.

Screen Shot 2015-01-16 at 8.22.13 AM

If the option of using an Apple ID to unlock the disk and reset passwords had not been chosen, the Reset Password wizard notifies the user that their FileVault recovery key had not stored with Apple and that iCloud FileVault recovery is not available. Instead, the user will need to provide their recovery key at the pre-boot login screen.

Screen Shot 2015-01-15 at 1.43.12 PM

My password doesn’t work when logging in

The “My password doesn’t work when logging in” option will provide another option for resetting your password, but it relies on the user actually knowing the correct password or having the password to another FileVault 2-enabled account on the Mac.

If the user has the correct password or the password to another account on the Mac which has been enabled for FileVault 2, selecting the “My password doesn’t work when logging in” option will go through the following process:

A. Asking for a password to unlock the boot volume.

Screen Shot 2015-01-15 at 1.43.39 PM

Note: This can be the user’s account password (if known and correct) or the password to another FileVault 2-enabled account on the Mac.

B. Select the relevant account.

Screen Shot 2015-01-15 at 1.44.11 PM

Note: This password reset process is designed to reset the password of a local account. If the password reset process is run against a network account which has been enable for FileVault 2, the password sync may be broken between the network account and the directory service that manages the account.

C. Enter and verify a new password.

Screen Shot 2015-01-15 at 1.44.29 PM

D. You’ll be notified that your password has been reset and that you can now reboot and log in at the FileVault 2 pre-boot login screen.

Screen Shot 2015-01-15 at 1.45.01 PM  

My keyboard isn’t working when typing my password to login

The “My keyboard isn’t working when typing my password to login” option will provide the option of decrypting your FileVault 2 encrypted Mac. If the user has their account password or the password to another FileVault 2-enabled account on the Mac, selecting the “My keyboard isn’t working when typing my password to login” option will go through the following process:

A. Asking for a password to disable the FileVault 2 encryption on the boot volume.

Screen Shot 2015-01-16 at 8.21.13 AM

Note: This can be the user’s account password (if known and correct) or the password to another FileVault 2-enabled account on the Mac.

B. You’ll be notified that the boot volume has been decrypted and that you can now reboot and log in without being stopped at the FileVault 2 pre-boot login screen.

Screen Shot 2015-01-15 at 1.45.56 PM

One thing to be aware of is that the decryption process has only been initiated. Decryption will proceed once the Mac has been booted from a drive that is running a regular installation of Yosemite.


Downloading and deploying Adobe Flash Player 16.0.0.296

$
0
0

Over the weekend of January 24th, Adobe released Adobe Flash Player 16.0.0.296 to fix a critical vulnerability. This update was available for installation via the Flash auto-update, but there was nothing available for a manual download. This lack of a separate download meant that Mac admins didn’t have a way to get an installer for distribution to the Macs in their environments.

Adobe has stated that a manual download will be available during the week of January 26, but for the moment, it appears that the auto-update mechanism is the only way Adobe is distributing this update.

Fortunately, thanks to research by Greg Neagle and Per Olofsson, there appears to be a way to leverage AutoPkg to generate the needed installer package. See below the jump for details.


Update 1-26-2015: A 16.0.0.296 installer is now available on the Adobe Flash Player Distribution site (not linked because you gain access to the site after getting a valid Adobe Flash Player Distribution License Agreement in place.)



Update 2 – 1-26-2015: The AutoPkg download recipe for Adobe Flash has been updated to now download and decode the install_all_mac_pl_sgn.z file from Adobe’s Flash Player update feed for Macs. If you’re using AutoPkg, update your repos and you should get the changes. For more information on the actual recipe changes, see here.


Pre-requisites:

Adobe’s desktop auto-updater is downloading the following file:

http://fpdownload2.macromedia.com/get/flashplayer/update/current/install/install_all_mac_pl_sgn.z

The install_all_mac_pl_sgn.z file is an ASN.1-encoded file, which can be downloaded via a web browser or by using curl:

curl http://fpdownload2.macromedia.com/get/flashplayer/update/current/install/install_all_mac_pl_sgn.z > /path/to/install_all_mac_pl_sgn.z

Screen Shot 2015-01-26 at 7.45.38 AM

Once downloaded, it needs to be converted to a readable disk image file using the security command:

security cms -D -i /path/to/install_all_mac_pl_sgn.z > /path/to/install_all_mac_pl.dmg

Screen Shot 2015-01-26 at 7.47.50 AM

Once the disk image file is available, it can be used as a source by AutoPkg recipes. This option is available via the -p or –pkg option for AutoPkg’s run function.

Screen Shot 2015-01-26 at 7.36.26 AM

To create an Adobe Flash Player 16.0.0.296 installer package, run the following command:

autopkg run AdobeFlashPlayer.pkg -p /path/to/install_all_mac_pl.dmg

Screen Shot 2015-01-26 at 7.49.26 AM

Screen Shot 2015-01-26 at 7.50.35 AM

You should also be able to substitute other AdobeFlashPlayer recipes as well. Greg was able to add Adobe Flash Player 16.0.0.296 to his Munki repo with the AdobeFlashPlayer.munki recipe and I verified that I could upload Adobe Flash Player 16.0.0.296 to my Casper server:

autopkg run AdobeFlashPlayer.jss -p /path/to/install_all_mac_pl.dmg

FileVault 2 deferred enablement in Yosemite

$
0
0

One of the requirements when enabling an account for FileVault 2 is that the account’s own password must be provided in order for the account to be enabled. This is because the account’s password is used to generate a unique derived key via PBKDF2. This key is necessary for the account to unlock FileVault 2’s encryption, so the account’s password must be provided in order to enable an account.

Apple recognized that there would be situations where Mac admins would need to set up FileVault 2 for a person where the admin would not have the password for that person’s user account. To avoid the immediate need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with fdesetup‘s enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.

Screen Shot 2015-01-31 at 12.33.03 PM

The property list file will be created as a root-only readable file and contain information similar to what’s show below.

Screen Shot 2015-01-31 at 12.30.24 PM

Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.

Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:

fdesetup enable -user username -defer /path/to/filename.plist

Screen Shot 2015-01-31 at 2.23.07 PM

If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.

If you don’t want to specify the account, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist

Screen Shot 2015-01-31 at 2.24.49 PM

On logout, the user will be prompted to enter their account password.

Screen Shot 2015-01-31 at 10.57.19 AM

Once entered, FileVault 2 will be enabled and the recovery information plist file will be created. Once the enabling process is complete, the Mac will restart.

Screen Shot 2015-01-31 at 10.57.20 AM

An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.

In Yosemite, Apple added new options for fdesetup‘s -defer flag. These new options now allow Mac admins to set a deferred enablement with the following options:

  1. Enforce FileVault 2 enablement at logout
  2. Enforce FileVault 2 enablement at login
  3. Enforce FileVault 2 enablement at both login and logout

For more information, see below the jump.

Yosemite adds the following options for fdesetup‘s enable verb’s -defer flag:

  • -forceatlogin max_cancel_attempts
  • -dontaskatlogout

Screen Shot 2015-01-31 at 10.45.39 AM

These additional options allow a deferred FileVault 2 enablement to be enforced at the login window, rather than waiting for a logout or restart of the Mac in question. To demonstrate how this appears, I’ve made a video showing the following process:

  1. Logging in at the OS login window
  2. Being prompted to enable FileVault 2
  3. The Mac performing initial FileVault 2 setup
  4. The Mac automatically rebooting to the FileVault 2 pre-boot login screen.

Note: The video has been edited to artificially reduce the amount of time it took to initialize FileVault 2 setup. Run time of the pre-edited video was 1 minute, 12 seconds.

The -forceatlogin option must be set with an accompanying numerical value. This numerical value governs how many times the account which is being enabled can cancel having the FileVault 2 encryption process begin. For example, running the following command with root privileges will set a maximum number of ten cancellations:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 10

Screen Shot 2015-01-31 at 11.16.11 AM

If the user chooses to cancel, they will need to select the Don’t Enable button in the dialog window which will appear. They will also be informed of how many more times they can log in before FileVault 2 encryption must be enabled.

Screen Shot 2015-01-31 at 11.20.07 AM

If immediate enforcement is desired, setting a value of zero will enforce FileVault 2 encryption at the next login. To do this, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0

Screen Shot 2015-01-31 at 10.55.05 AM

The fdesetup commands shown above will enforce FileVault 2 enablement at both login and logout. If only enforcement at login is desired, the -dontaskatlogout option can be used. This will prevent a deferred FileVault 2 enablement from being enforced at logout. For example, running the following command with root privileges will enforce FileVault 2 encryption at the next login but not prompt the user on logout:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0 -dontaskatlogout

Screen Shot 2015-01-31 at 11.06.15 AM

The commands shown above will set up a deferred enablement with a personal recovery key (PRK). To set up a deferred enablement with an institutional recovery key (IRK), you will need to add the -keychain flag to the fdesetup command. For example, if you want to set up a deferred enablement of FileVault 2 where both a PRK and an IRK are used and the user is forced to enable FileVault 2 at the next login, run the following command with root privileges:

fdesetup enable -keychain -defer /path/to/filename.plist -forceatlogin 0

Screen Shot 2015-01-31 at 11.25.50 AM

If you want to set up a deferred enablement where only an IRK is used and the user is forced to enable FileVault 2 at the next login, but not prompted at logout, run the following command with root privileges:

fdesetup enable -keychain -defer /path/to/filename.plist -forceatlogin 0 -dontaskatlogout -norecoverykey

Screen Shot 2015-01-31 at 12.38.18 PM


Managing Yosemite’s FileVault 2 with fdesetup

$
0
0

With the release of Yosemite, Apple has continued to add functionality to fdesetup, a valuable command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption. This tool gives Mac administrators the following command-line abilities:

  • Enable or disable FileVault 2 encryption on a particular Mac
  • Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
  • Enable one or multiple user accounts at the time of encryption
  • Get a list of FileVault 2-enabled users on a particular machine
  • Add additional users after FileVault has been enabled
  • Remove users from the list of FileVault enabled accounts
  • Add, change or remove individual and institutional recovery keys
  • Report which recovery keys are in use
  • Perform a one-time reboot that bypasses the FileVault pre-boot login
  • Report on the status of FileVault 2 encryption or decryption

I’ll be taking you through all of the capabilities mentioned above, with a focus on showing exactly how they work. See below the jump for details.

Enabling Filevault 2 Encryption For One Or Multiple Users

fdesetup is amazingly flexible when it comes to enabling FileVault 2 encryption from the command-line. To start with the simplest method, run the following command with root privileges to enable FileVault 2 encryption:

fdesetup enable

You’ll be prompted for the username and password of the primary user, which is the account you will work with at the FileVault 2 pre-boot login screen once the encryption is turned on.

If everything’s working properly, you’ll next be given an alphanumeric personal recovery key and prompted to restart.

Figure_1-Using_fdesetup_enable_to_enable_FileVault_2_encryption

VERY IMPORTANT: The fdesetup-generated personal recovery key is not saved anywhere outside the machine. Make a record of it or you will not have a recovery key available to help unlock your Mac’s encryption in case of a problem.

You can also enable additional user accounts at the time of encryption, as long as the accounts are either local or mobile accounts on the Mac being encrypted. Run the following command with root privileges to enable FileVault 2 and specify the accounts you want:

fdesetup enable -user username -usertoadd other_username -usertoadd yet_another_username

You’ll be prompted for the passwords of the accounts specified. After that, you’ll be given an alphanumeric personal recovery key and prompted to restart. All of the accounts specified should appear at the FileVault 2 pre-boot login screen.

Figure_2-Using_fdesetup_enable_to_enable_FileVault_2_for_multiple_accounts

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>username</string>
<key>Password</key>
<string>password</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
</array>
</dict>
</plist>

Figure_3-Plist_format_for_fdesetup_enable

Additional users can be included as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Once the plist has been set up and properly formatted, run the following command with root privileges to enable FileVault 2 encryption and reference the account information in the plist file:

fdesetup enable -inputplist < /path/to/filename.plist

Since the accounts and passwords are in the plist file, fdesetup does not need to prompt for passwords. Instead, the alphanumeric personal recovery key is displayed and the user is prompted to restart. All of the accounts specified in the plist file should appear at the FileVault 2 pre-boot login screen.

Figure_4-Using_fdesetup_enable_with_plist_to_enable_FileVault_2_for_multiple_accounts

To avoid the need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with the enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.

The property list file will be created as a root-only readable file and contain information similar to what’s show below.

Figure_5–fdesetup_enable_-defer_recovery_information_plist_format

Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.

Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:

fdesetup enable -user username -defer /path/to/filename.plist

Figure_6-Using_fdesetup_enable_-defer_with_specified_user_to_enable_FileVault_2

If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.

If you don’t want to specify the account, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist

Figure_7-Using_fdesetup_enable_-defer_without_specified_user_to_enable_FileVault_2

On logout, the user will be prompted to enter their account password.

Figure_8-User_being_prompted_to_enter_password_for_deferred_enabling_of_FileVault_2

Once entered, FileVault 2 will be enabled and the recovery information plist file will be created. Once the enabling process is complete, the Mac will restart.

Figure_9-FileVault_2_deferred_enabling_process

An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.

In Yosemite, Apple has added additional options for fdesetup‘s -defer flag. These new options now allow Mac admins to set a deferred enablement with the following options:

  1. Enforce FileVault 2 enablement at logout
  2. Enforce FileVault 2 enablement at login
  3. Enforce FileVault 2 enablement at both login and logout

Figure_10-User_being_prompted_to_enter_password_at_login_for_deferred_enabling_of_FileVault_2

Yosemite adds the following options for fdesetup‘s -defer flag:

  • -forceatlogin max_cancel_attempts
  • -dontaskatlogout

These additional options allow a deferred FileVault 2 enablement to be enforced at the login window, rather than waiting for a logout or restart of the Mac in question.

The -forceatlogin option must be set with an accompanying numerical value. This numerical value governs how many times the account being enabled can choose to defer having the FileVault 2 encryption process begin. For example, running the following command with root privileges will set a maximum number of ten deferral opportunities:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 10

Figure_11–Using_fdesetup_enable_–defer_–forceatlogin_to_permit_deferred_enablement_of_FileVault_2

If the user chooses to defer, they will need to select the Don’t Enable button in the dialog window when it will appear. They will also be informed of how many more times they can log in before FileVault 2 encryption must be enabled.

Figure_12-User_being_given_the_option_to_defer_FileVault_2_encryption

If immediate enforcement is desired, setting a value of zero will enforce FileVault 2 encryption at the next login. To do this, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0

Figure_13–Using_fdesetup_enable_–defer_–forceatlogin_to_enforce_enablement_of_FileVault_2

The fdesetup commands shown above will enforce FileVault 2 enablement at both login and logout. If only enforcement at login is desired, the -dontaskatlogout option can be used. This will prevent a deferred FileVault 2 enablement to be enforced at logout. For example, running the following command with root privileges will enforce FileVault 2 encryption at the next login but not prompt the user on logout:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0 –dontaskatlogout

Figure_14–Using_fdesetup_enable_–defer_–forceatlogin_to_enforce_enablement_of_FileVault_2_at_login

Enabling Filevault 2 Encryption Using One Or Multiple Recovery Keys

Another capability of FileVault 2 in Yosemite is the ability to use the alphanumeric personal recovery key, an institutional recovery key using /Library/Keychains/FileVaultMaster.keychain, or both kinds of recovery key at the same time.

As seen in the earlier examples, fdesetup will provide the alphanumeric personal recovery key by default. To use the institutional recovery key, the -keychain flag needs to be used when enabling encryption:

fdesetup enable –keychain

The alphanumeric personal recovery key is displayed, but the encryption will also use the /Library/Keychains/FileVaultMaster.keychain institutional recovery key. In case recovery is needed, either recovery key will work to unlock or decrypt the encrypted drive.

Figure_15–Using_fdesetup_enable_-keychain_to_enable_encryption_with_both_recovery_key_types

If you want to specify that only the FileVaultMaster.keychain institutional recovery key be used, both the -keychain and -norecoverykey flags need to be used when enabling encryption:

fdesetup enable -keychain –norecoverykey

Figure_16–Using_fdesetup_enable_-keychain_-norecoverykey_to_enable_encryption_with_only_the_institutional_recovery_key

fdesetup is also capable of creating an institutional recovery key, using the -certificate flag to import an existing FileVault 2 public key. Once imported, fdesetup will automatically create a FileVaultMaster.keychain file to store the public key and save the keychain to /Library/Keychains.

The public key will need to be available as a DER encoded .cer certificate file. Once the certificate is available, the following command can be run with root privileges to enable FileVault 2, automatically create the institutional recovery key with the supplied public key and store it as /Library/Keychains/FileVaultMaster.keychain:

fdesetup enable -certificate /path/to/filename.cer

Figure_17–Using_fdesetup_enable_-certificate_to_enable_encryption_with_an_imported_certificate

To specify that only the FileVaultMaster.keychain institutional recovery key be used, add the -norecoverykey flag to the command:

fdesetup enable -certificate /path/to/filename.cer -norecoverykey

Figure_18–Using_fdesetup_enable_-certificate_-norecoverykey_to_enable_encryption_with_only_the_imported_certificate

It is also possible to include the public key data in a plist file, which allows the use of a plist to set up the institutional recovery key. The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>username</string>
<key>Password</key>
<string>password</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
</array>
<key>Certificate</key>
<data>
(Certificate data goes here…)
</data>
</dict>
</plist>

Using the public key’s DER encoded certificate file, the public key data for the plist can be obtained using the base64 tool by using the following command:

base64 /path/to/filename.cer > /path/to/filename.txt

At this point, you would copy the data string contained in the text file and place it into the Certificate value area of the plist file. You would store either the password of an existing FileVault 2-enabled user or (if available) an existing personal recovery key in the Password key in the plist.

Figure_19–Plist_format_with_institutional_public_key_data

Forcing A Restart When Enabling Filevault 2 Encryption

Along with the various options for enabling, it’s also possible to force a restart of the Mac once FileVault 2 has been successfully configured. This can help automate the process of enabling FileVault 2 on a Mac if no input from a logged-in user is needed.

For example, an institution may want to pre-configure its Macs to automatically encrypt with FileVault 2 at first boot with a local admin account enabled. It also wants to use only the institutional recovery key. If a plist with the desired account information and public key data to create the institutional recovery key is available, the following command could be run with root privileges to enable FileVault 2 and force a restart at the first boot:

fdesetup enable -inputplist < /path/to/filename.plist -norecoverykey -forcerestart

Once fdesetup had finished enabling the accounts in the plist file and creating /Library/Keychains/FileVaultMaster.keychain, the Mac would immediately restart and display the enabled accounts at the pre-boot login screen.

If you want to use the alphanumeric personal recovery key with -forcerestart, you will also need to output the personal recovery key and other information into a plist file. Taking the example above, the institution’s automated setup would run the following command with root privileges to automatically encrypt with FileVault 2 at first boot using both types of recovery key and a local admin account enabled:

fdesetup enable -inputplist < /path/to/filename.plist -outputplist > /path/to/recoverykeyinfo.plist –forcerestart

Disabling Filevault 2 Encryption

In contrast to all of the various options available for enabling FileVault 2 using fdesetup, the command to turn off FileVault 2 encryption is the following:

fdesetup disable

Figure_19–Using_fdesetup_disable_to_turn_off_FileVault_2s_encryption

Adding Additional Users After Filevault 2 Has Been Enabled

Once FileVault 2 has been enabled, you can add additional users using fdesetup. To do so, you will need to a) wait until the FileVault 2 encryption has completed and b) provide both the username and password of a previously enabled account as well as the password of the account you want to add. The following command run with root privileges will enable a user account named otheruser:

fdesetup add -usertoadd username_goes_here

Figure_20–Using_fdesetup_add_-usertoadd_to_enable_additional_accounts

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>username</string>
<key>Password</key>
<string>password</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
    <dict>
        <key>Username</key>
        <string>username</string>
        <key>Password</key>
        <string>password</string>
    </dict>
</array>
</dict>
</plist>

When adding additional users using a plist file, the top level Username key is ignored, and the Password key value should either be an existing FileVault user’s password or the recovery key. Additional users can be added as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Figure_21-Plist_format_for_fdesetup_add

Once the plist has been set up and properly formatted, run the following command with root privileges to add additional users by referencing the account information in the plist file:

fdesetup add -inputplist < /path/to/filename.plist

Figure_22–Using_fdesetup_add_–inputplist_to_enable_accounts

Listing Current Filevault 2 Users

To list all accounts enabled for FileVault 2, run the following command with root privileges:

fdesetup list

All accounts will be listed with both the accounts’ username and UUID

Figure_23–Using_fdesetup_list_to_show_enabled_accounts

Removing Users From The List Of Filevault 2 Enabled Accounts

You can remove users from the list of FileVault enabled accounts by using either their username or the account’s UUID. To remove the account using the username, run the following command with root privileges:

fdesetup remove -user username_goes_here

Figure_24–Using_fdesetup_remove_with_username

To remove the account using the account’s UUID, run the following command with root privileges:

fdesetup remove -uuid UUID_goes_here

Figure_25–Using_fdesetup_remove_with_UUID

In both cases, successful removal of the account will not produce any additional output. If the account being removed is not currently enabled for use with FileVault 2, an error message will be displayed.

Figure_26-fdesetup_remove_error_when_specified_account_is_not_FileVault_2_enabled

Managing Individual And Institutional Recovery Keys

fdesetup in Yosemite includes the ability to change, add and remove both personal and institutional recovery keys. This gives Mac admins much greater ability to manage recovery keys, including the capability to quickly update or remove compromised personal and/or institutional recovery keys in the event of a data breach or other problem.

You can add or change recovery keys using fdesetup changerecovery. To change to a new personal key, run the following command with root privileges:

fdesetup changerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user or the existing personal recovery key. Once entered, a new personal recovery key will be generated and displayed. The former personal recovery key will no longer work.

Figure_27–Using_fdesetup_changerecovery_to_change_to_a_new_personal_recovery_key

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

Figure_28-Plist_format_for_fdesetup_changerecovery_personal

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, run the following command with root privileges to change to a new personal recovery key and reference the password or recovery key in the plist file:

fdesetup changerecovery -personal -inputplist < /path/to/filename.plist

Figure_29–Using_ fdesetup_changerecovery_personal_with_inputplist

In the event that the Mac in question does not have a personal recovery key, running the commands above will add a personal recovery key instead of changing an existing one.

To change to a new institutional recovery key, you will need to have the new public key available. If you have a new institutional public key available as a DER encoded certificate file, you can run the following command with root privileges to replace the current institutional key:

fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer

If an institutional keychain is being used on this Mac, you will see a message that an existing FileVault Master keychain was found and moved. The reason for this is that, as part of this process, the current institutional key’s /Library/Keychains/FileVaultMaster.keychain file is replaced with a new /Library/Keychains/FileVaultMaster.keychain file that includes the new institutional recovery key’s public key.

Figure_30–Using_fdesetup_changerecovery_to_change_to_a_new_institutional_recovery_key

While the former institutional key’s /Library/Keychains/FileVaultMaster.keychain file was moved and not deleted, the former institutional recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
<key>Certificate</key>
<data>
(Certificate data goes here…)
</data>
</dict>
</plist>

Figure_31-Plist_format_for_fdesetup_changerecovery_institutional

You can also use the current institutional recovery key to authenticate the change to the new institutional key. If you have a keychain file available containing the private key of the current institutional key, you can run the following command with root privileges to replace the current institutional key:

fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer -key /path/to/filename.keychain

You’ll be prompted for the keychain’s password. Once entered, the current institutional key will be replaced with the new one.

Figure_32–Using_fdesetup_changerecovery_with_institutional_recovery_keychain

In the event that the Mac in question does not have an institutional recovery key, running the commands above (with the exception of using the current institutional key for authentication) will add a institutional recovery key instead of changing an existing one.

Removing Individual And Institutional Recovery Keys

You can remove recovery keys using fdesetup removerecovery. To remove the current personal recovery key, run the following command with root privileges:

fdesetup removerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user or the existing personal recovery key. Once entered, the personal recovery key will be removed from the system. The former personal recovery key will no longer work.

Figure_33–Using_fdesetup_removerecovery_to_remove_a_personal_recovery_key

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Figure_34-Plist_format_for_fdesetup_removerecovery

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the current personal recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -personal -inputplist < /path/to/filename.plist

Figure_35–Using_ fdesetup_removerecovery_personal_with_inputplist

To remove institutional recovery keys, run the following command with root privileges:

fdesetup removerecovery -institutional

You’ll be prompted for the password of an existing FileVault 2-enabled user, or a personal recovery key if one is available. Once entered, the institutional recovery key will be removed from the system and will no longer work.

Figure_36–Using_fdesetup_removerecovery_to_remove_an_institutional_recovery_key

The removal of the institutional key can also be automated using a properly formatted plist via a standard input stream (stdin). The plist is the same as the one used for removing the personal key.

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the institutional recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -institutional -inputplist < /path/to/filename.plist

Figure_37–Using_ fdesetup_removerecovery_personal_with_inputplist

You can also use the recovery key associated with an institutional key to authenticate the removal of that institutional key. Once authenticated, the institutional key is removed from the system and will no longer work.

If you have a keychain file containing the private key for the current institutional key available, you can run the following command with root privileges to remove the current institutional key:

fdesetup removerecovery -institutional -key /path/to/filename.keychain

Figure_38–Using_fdesetup_removerecovery_with_institutional_recovery_keychain

It is possible to use fdesetup removerecovery to remove one or both recovery keys on a particular Mac. Once the recovery keys are removed, the only way to unlock the FileVault 2 encryption is by using the password of an enabled account. That said, you could use fdesetup changerecovery to add one or both types of recovery keys back to the encrypted Mac.

Recovery Key Reporting

To go along with the ability to manage recovery keys, fdesetup in Yosemite enables Mac admins to detect which types of recovery keys are in use on a particular Mac. To check if a personal recovery key is in use, run the following command with root privileges:

fdesetup haspersonalrecoverykey

If FileVault 2 is using a personal recovery key, this command will return true. Otherwise it will return false.

Figure_39–Using_fdesetup_haspersonalrecoverykey

To check if an institutional recovery key is in use, run the following command with root privileges:

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an institutional recovery key, this command will return true. Otherwise it will return false.

Figure_40–Using_fdesetup_hasinstitutionalrecoverykey

One-Time Filevault 2 Encryption Bypass

fdesetup in Yosemite has the authrestart verb, which allows a FileVault 2-encrypted Mac to restart, bypass the FileVault 2 pre-boot login screen, and goes straight to the OS login window. To restart and bypass the FileVault 2 pre-boot login screen, run the following command with root privileges:

fdesetup authrestart

When you run the fdesetup authrestart command, it asks for the password of an existing FileVault 2-enabled user or a personal recovery key.

Figure_41–Using_fdesetup_authrestart

Once authenticated, the authrestart process puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.

It’s also possible to automate this process by importing the authentication via a properly formatted plist. The plist needs to follow the format below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Password</key>
<string>password</string>
</dict>
</plist>

Figure_42-Plist_format_for_fdesetup_authrestart

You would store either the password of an existing FileVault 2-enabled user or a personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, use the following command with root privileges to run the authrestart process and reference the password or recovery key in the plist file for authentication:

fdesetup authrestart -inputplist < /path/to/filename.plist

Figure_43–Using_fdesetup_authrestart_with_-inputplist

fdesetup authrestart may not be supported by all Yosemite-compatible Macs. To verify if a specific Mac supports authrestart, run the following command with root privileges:

fdesetup supportsauthrestart

If the Mac supports fdesetup authrestart, this command will return true. Otherwise it will return false.

Figure_44–Using_fdesetup_supportsauthrestart

Reporting On Filevault 2 Encryption Or Decryption Status

fdesetup can report on FileVault 2 encryption or decryption status. Running the following command with root privileges will display the current state:

fdesetup status

Figure_45-fdesetup_status_reporting_decryption_status

Figure_46-fdesetup_status_reporting_encryption_status

Conclusion

In Yosemite, Apple has continued the evolution of the fdesetup tool to add even more functionality. fdesetup in Yosemite can enable FileVault 2, add and remove users from the list of FileVault 2 authorized accounts, manage recovery keys, report on FileVault 2’s status and more. Among its greatest strengths are:

  • It allows options for automating FileVault 2 setups via scripting.
  • fdesetup’s defer option can be used to set up a self-service procedure for enabling encryption either at login or logout.
  • It supports multiple recovery keys for FileVault 2, giving Mac admins more options for handling recovery situations.
  • It allows you to rotate or remove recovery keys on an as-needed basis.
  • It provides a one-time method for bypassing encryption on restart, to accommodate situations where an encrypted Mac needs to be restarted from a remote location.

Managing FileVault 2 encryption using this tool will save you time and give encryption options available with no other software.


Installing the Xcode command line tools on 10.7.x and later

$
0
0

A number of Mac admins need to provide the Xcode Command Line Tools for the Macs in their environments, either as part of building machines or afterwards. To help with this task, I’ve developed a script that will download and install the Xcode Command Line Tools on Macs running 10.7.x and higher. See below the jump for more details.

The script will perform different tasks, depending on which version of OS X it’s being run on.

On OS X 10.9.x and 10.10.x:

  1. Creates a placeholder file in /tmp. This file’s existence is checked by the softwareupdate tool before allowing the installation of the Xcode command line tools.
  2. Runs the softwareupdate tool and checks for the latest version of the Xcode command line tools for the OS in question.
  3. Uses the softwareupdate tool to install the latest version of the Xcode command line tools for the OS in question.
  4. Removes the placeholder file stored in /tmp.

On Mac OS X 10.7.x and 10.8.x:

  1. Uses curl to download a disk image containing the specified Xcode Command Line Tools installer from Apple’s web site.
  2. Renames the downloaded disk image to cltools.dmg.
  3. Mounts the disk image silently in /tmp. Disk image will not be visible to any logged-in user.
  4. Installs the Xcode Command Line Tools using the installer package stored on the disk image
  5. After installation, unmounts the disk image and removes it from the Mac in question.

Note: This script should not be used as part of a payload-free installer package. On 10.9.x and 10.10.x, the softwareupdate tool will not work properly when called from within an installer package.

The script is available below. It’s also available from my Github repo from the following link:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_xcode_command_line_tools


Free tools for the budget-minded Mac admin

$
0
0

In the ##osx-server IRC room, a question that comes up fairly often from new Mac admins is one similar to this:

I’m on a tight budget. Are there any free tools that I can use to help manage my Macs?

There are a lot of free tools available to Mac admins, a number of which are community-built open-source tools. Here’s a list of free tools to get started with:


Update 2-4-2015: Tom Bridge has put together a list of free or cheap Mac sysadmin tools.

Imaging and machine building

Installer package building and development

FileVault 2 recovery key management

Mac management

NetBoot

OS installation and upgrades

Software management and deployment

Know of any more free tools to help manage Macs? Got a favorite that you think is missing from the list? Let me know in the comments.



Certificate authority expiration and Apple software updates

$
0
0

A while back, there was an issue when the certificate Apple used to digitally sign installers expired. This issue was handled by Apple in a couple of ways:

  1. Reissuing installers signed with an updated certificate
  2. Adding the -allowUntrusted function to the installer command line tool

In the past couple of weeks, Apple has released new versions of a number of updates, which are now available for download by folks running Apple’s Software Update service or third-party tools like Reposado. Most of these updates were for older OSs where Apple has since stopped providing new updates. When these updates were checked, there didn’t seem to be any difference between the “old” and “new” versions of the installers.

So why is Apple pushing new copies of the updates to Mac admins’ software update servers? The answer appears to be again in the digital signing of the updates. For more details, see below the jump.

Unlike the previous episode, where the Software Update certificate directly associated with signing the installers had expired, this change appears to affect the Apple Software Update Certification Authority certificate authority. This is an intermediate certificate authority, which provides a way for the Software Update certificate to establish a chain of trust back to Apple’s root certificate authority. For older updates (those issued before 2013), the Apple Software Update Certification Authority certificate authority has an expiration date of Saturday, February 14th, 2015.

Screen Shot 2015-02-10 at 7.11.06 AM

Once the Apple Software Update Certification Authority certificate authority expires, that breaks the chain of trust for any certificates that rely on it. As a consequence, a Software Update certificate used to sign an installer which uses the expired Apple Software Update Certification Authority won’t be trusted even though the Software Update certificate itself expires in 2019.

Screen Shot 2015-02-10 at 8.05.38 AM

Apple is addressing this situation by re-signing and re-issuing updates, a process which will hopefully be completed before the Apple Software Update Certification Authority expiration date of 2-14-2015. It also appears that sometime in 2013, Apple started using a new Apple Software Update Certification Authority certificate authority when signing installers. This newer certificate authority has an expiration date of 10-24-2019.

Screen Shot 2015-02-10 at 7.26.04 AM


Oracle’s Java 8 Update 31 has been updated to …. Java 8 Update 31

$
0
0

Oracle has released a new update for Java 8, but this update has an interesting wrinkle. Oracle has put out a new build of Java 8, but didn’t bump the version number from Java 8 Update 31. So folks who had previously installed Java 8 Update 31 may receive a message to update to Java 8 Update 31 from their current version, which will also be Java 8 Update 31.

This may lead to some confusion.

java_8_update_31

Build numbers for the two Java 8 Update 31 releases

January’s Java 8 Update 31 (released on January 20, 2015): Java 8 Update 31 build 13

February’s Java 8 Update 31 (released on February 10, 2015): Java 8 Update 31 build 15

If you have Java 8 Update 31 installed, you can find out which build you have by running the following command in Terminal:

defaults read /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Info.plist CFBundleVersion

If you have Java 8 Update 31 build 13, the following string will be returned:

1.8.31.13

Screen Shot 2015-02-13 at 12.39.10 PM

If you have Java 8 Update 31 build 15, the following string will be returned:

1.8.31.15

Screen Shot 2015-02-13 at 12.30.22 PM

Following installation of Java 8 Update 31 build 15, I tested on a 10.10.2 Mac against the following sites:

My work’s Juniper VPN

Oracle’s Java Test page: https://www.java.com/en/download/help/testvm.xml

Screen Shot 2015-02-13 at 12.09.11 PM

Java Tester’s Java Version page: http://javatester.org/version.html

Screen Shot 2015-02-13 at 12.08.47 PM

In all three cases, the Java applets on those sites launched and worked without issue using Java 8 Update 31 build 15 (though the javatester.org applet needed to be whitelisted.)


AutoPkg slides from the January 2015 MacDMV meeting

$
0
0

The January 2015 MacDMV meeting on Saturday, January 24th was quite the event, between having to move from our planned meeting place due to a fire and figuring out the best way to give Keynote presentations while gathered around a table at the Silver Diner for an impromptu brunch. All obstacles were overcome though, and I was able to collaborate with Jennifer Unger on a talk about AutoPkg.

For those who want a copy of the AutoPkg talk, here are links to the slides in PDF and Keynote format:

PDF: http://tinyurl.com/MacDMVAutoPkgPDF

Keynote slides: http://tinyurl.com/MacDMVAutoPkgKeynote


Deploying Sophos Enterprise Anti-Virus for Mac 9.2.x

$
0
0

With the release of Sophos Enterprise Anti-Virus 9.2.x, Sophos changed how their enterprise antivirus solution for Macs was installed. While previous versions of Sophos Enterprise used an Apple installer metapackage, Sophos has now switched to using an application to install their enterprise antivirus software.

Screen Shot 2015-02-25 at 7.48.51 PM

This switch was a problem for Mac admins who wanted to deploy Sophos Enterprise Anti-Virus 9.2.x, as the previously-available installer package had simplified the task of deployment. The new Sophos Enterprise Anti-Virus 9.2.x install application added further complexity by storing many of the installer’s files and other components outside the application in a separate Sophos Installer Components directory.

Screen Shot 2015-02-25 at 7.50.06 PM

However, after doing some research and testing, it looks like it is possible to repackage Sophos Enterprise 9.2.x for deployment. For more details, see below the jump.

Sophos’ application can be run from the command line using the InstallationDeployer tool and include both install and remove switches. Here’s how to install and uninstall Sophos 9.x using the Sophos Enterprise Anti-Virus installer application:

Install:

/path/to/Sophos\ Installer.app/Contents/MacOS/tools/InstallationDeployer --install

Uninstall:

/Library/Application\ Support/Sophos/opm/Installer.app/Contents/MacOS/tools/InstallationDeployer --remove

With these commands, it’s possible to add the Sophos Installer application and the Sophos Installer Components directory to an installer package and run the needed commands with preinstall and postinstall scripts.

The other part of the puzzle is providing configuration and login credentials, to allow Sophos 9.2.x to communicate back with the Sophos Enterprise console following installation. After working on the problem in his own shop, Tim Kimpton figured out that both of the following files were needed:

/Library/Preferences/com.sophos.sau.plist

/Library/Sophos Anti-Virus/Sophos.keychain

Once I had this information and understood what was going on, here’s how I repackaged Sophos Enterprise Anti-Virus 9.2.x so that it could be deployed via an installer package.

Prerequisites:

Packages

A copy of the Sophos Installer application and the Sophos Installer Components directory from your Sophos Enterprise console server. The Sophos installer is available from the link below:

smb://your_sophos_enterprise_server_name_goes_here/SophosUpdate/CIDs/S000/ESCOSX/

A copy of the Sophos.keychain file, which will need to be taken from the following location on a Sophos Enterprise-managed machine: /Library/Sophos Anti-Virus/Sophos.keychain

A copy of the com.sophos.sau.plist file, which will need to be taken from the following location on a Sophos Enterprise-managed machine: /Library/Preferences/com.sophos.sau.plist

1. Set up a new Packages project and select Raw Package.

Screen Shot 2015-02-25 at 7.51.54 PM

2. In this case, I’m naming the project Sophos Enterprise Anti-Virus 9.2.4

Screen Shot 2015-02-25 at 7.52.13 PM

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

Screen Shot 2015-02-25 at 7.52.33 PM

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Post-Installation Behavior section, set On Success: to Do Nothing

In the Options section, check the box for Require admin password for installation.

Screen Shot 2015-02-25 at 7.52.40 PM

5. Click on the Scripts tab in your Packages project.

6. Select the Sophos Installer application and the Sophos Installer Components directory and drag it into the Additional Resources section of your Packages project.

Screen Shot 2015-02-25 at 7.53.34 PM

7. Select the Sophos.keychain file and drag it into the Additional Resources section of your Packages project.

Screen Shot 2015-02-25 at 7.53.46 PM

8. The last piece is doing an automated uninstall of any existing Sophos installations, then installing a fresh copy of Sophos with the pre-configured autoupdate settings.

For this, you’ll need a preinstall script and postinstall script. Here are the ones I’m using:

Preinstall:

Postinstall:

9. Once you’ve got the preinstall and postinstall scripts built, run the following command to make the script executable:

sudo chmod a+x /path/to/preinstall
sudo chmod a+x /path/to/postinstall

10. Once completed, add the preinstall and postinstall scripts to your Packages project.

Screen Shot 2015-02-25 at 7.54.13 PM

11. Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3Creating a raw package project and Chapter 10Building a project.)

Testing the installer

Once the package has been built, test it by taking it to a test machine that does not have Sophos and install it. The end result should be that Sophos Anti-Virus installs properly and has the pre-configured settings for your Sophos Enterprise server included automatically.


IRC and the Mac admin community

$
0
0

One of the interesting developments of the past few years has been the use of IRC by the Mac admin community to get more of us “together” in the same place to ask questions and get help from each other. For me, it’s been an invaluable resources in solving problems as many pairs of eyes can look at a particular issue and arrive at a solution (or even multiple solutions.)

For those interested in joining the conversation, here are the two IRC channels on Freenode that you’re most likely to find me in:

##osx-server: http://webchat.freenode.net/?channels=#%23osx-server

#jamfnation: http://webchat.freenode.net/?channels=%23jamfnation

If you’re new to IRC, I recommend reading Tom Bridge‘s A Field Guide to IRC, available from AFP548.


Viewing all 764 articles
Browse latest View live