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

Managing El Capitan’s FileVault 2 with fdesetup

$
0
0

For the first time since fdesetup‘s initial release in OS X Mountain Lion 10.8.x, Apple has not added new features to fdesetup as part of a new OS release. Instead, fdesetup maintains the same set of features in OS X El Capitan 10.11.x as it had in OS X Yosemite 10.10.x.

This decision may mean that fdesetup, an essential command-line tool for enabling, administering and disabling Apple’s FileVault 2 encryption, is now considered by Apple to be a fully-developed toolset for managing FileVault 2.

fdesetup 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:

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 also has a -defer flag in El Capitan that can be used with the “enable” command option 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 at logout 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

In addition to enabling FileVault 2 as part of the logout process, Apple added the ability to set a deferred enablement at login to OS X Yosemite. In OS X El Capitan, this means that Mac admins can 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

To set a deferred enablement at login, the following options may be added to 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

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.


Enabling Filevault 2 Encryption Using One Or Multiple Recovery Keys

Another capability of FileVault 2 in El Capitan 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:

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 20 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 otheruser

 

Figure 21 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:

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 existing personal 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.

 

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 23 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 24 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 25 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_here

Figure 26 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 27 fdesetup remove error when specified account is not FileVault 2 enabled

 

Managing Individual And Institutional Recovery Keys

fdesetup in El Capitan 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 28 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:

 

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 30 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 31 Using fdesetup changerecovery to change to a new institutional recovery key

While the former institutional key’s /Library/Keychains/FileVaultMaster.keychain 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:

 

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 33 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 34 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:

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 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 36 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 37 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 38 Using fdesetup removerecovery institutional 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 39 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 El Capitan 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 40 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 41 Using fdesetup hasinstitutionalrecoverykey

One-Time Filevault 2 Encryption Bypass

fdesetup in El Capitan 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 the fdesetup authrestart command is run, it asks for the password of an existing FileVault 2-enabled user or a personal recovery key.

 

Figure 42 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:

Either the password of an existing FileVault 2-enabled user or a personal recovery key would be stored 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 44 Using fdesetup authrestart with inputplist

fdesetup authrestart may not be supported by all El Capitan-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 45 Using fdesetup supportsauthrestart

The authrestart function can also be leveraged part of enabling FileVault 2 encryption. To re-use a previous 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 and using only an institutional recovery key. It also wants the Macs to bypass the login screen and boot normally, so that the encryption process can continue unattended.

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, automatically reboot the Mac, bypass the FileVault 2 pre-boot login screen and boot normally to the OS login window.

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

 

Figure 46 Using fdesetup authrestart to enable encryption with institutional recovery key

Once fdesetup had finished enabling the accounts in the plist file and creating /Library/Keychains/FileVaultMaster.keychain, the Mac would immediately restart, bypass the pre-boot login screen and boot the OS. The encryption of the boot volume would proceed normally after the reboot.

If using the alphanumeric personal recovery key with -authrestart, the personal recovery key and other information will need to be exported to 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 -authrestart -inputplist < /path/to/recoverykeyinfo.plist -outputplist > /path/to/recoverykeyinfo.plist

Figure 47 Using fdesetup authrestart to enable encryption with personal recovery key

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 48 fdesetup status reporting decryption status

 

Figure 49 fdesetup status reporting encryption status

 

Figure 50 fdesetup status reporting encryption is enabled

 

Figure 51a fdesetup status reporting encryption is disabled and IRK is installed

 

Figure 51 fdesetup status reporting encryption is disabled

 

Conclusion

fdesetup in El Capitan is a solid tool for FileVault 2 management, with the abilities to 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 deferred enablement 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.



2015 in review

$
0
0

The WordPress.com stats helper monkeys prepared a 2015 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,500,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 64 days for that many people to see it.

Click here to see the complete report.


First look at Veertu

$
0
0

One of the lesser-known changes that Apple introduced with OS X Yosemite was a Hypervisor framework, which was designed to allow virtualization solutions to be built for OS X without the need for third-party kernel extensions.

Screen Shot 2016 01 08 at 11 58 50 PM

One reason for this was that eliminating the need for kernel extensions allowed the possibility of virtualization software to be distributed and sold via the Mac App Store. While neither VMware or Parallels have taken advantage of this, a new virtualization product named Veertu has recently become available in the MAS.

Screen Shot 2016 01 08 at 8 13 38 AM

Veertu is available for free from the MAS, and allows installation of selected Linux VMs, downloaded from Veertu’s online library. For more details, see below the jump.

Veertu’s library of Linux VMs appear to actually be ISO files, downloaded from a Veertu-hosted service, which are then leveraged to set up a new VM using the Veertu-provided ISO file. The process looks like this:

1. In the Create New VM window, select Download and run Linux VMs then click the Next button.

Screen Shot 2016 01 08 at 8 14 26 AM

Screen Shot 2016 01 08 at 8 14 27 AM

2. Select the Linux distro you want from the list then click the Next button.

Screen Shot 2016 01 08 at 11 32 55 PM

3. Veertu will download the appropriate installation ISO file from Veertu’s online library.

Screen Shot 2016 01 08 at 8 15 02 AM


Note: These Linux ISO files are coming from Veertu and not directly from the distro maintainers. If this is an issue, the alternative is purchasing the ability to install using a user-provided ISO and then separately downloading the appropriate ISO from the desired distro maintainers’ site.

4. Once the appropriate installation ISO file has been downloaded from Veertu, a summary of the VM’s default settings will be displayed.

Screen Shot 2016 01 08 at 11 40 00 PM

A. If the settings look fine as-is, click the Launch VM button.

Screen Shot 2016 01 08 at 11 40 01 PM

B. If there are settings which need to be changed from the defaults, click the Customize button and make any changes needed in the Edit VM window.

Screen Shot 2016 01 08 at 11 40 02 PM

Screen Shot 2016 01 08 at 11 41 47 PM

Screen Shot 2016 01 08 at 11 41 11 PM

Screen Shot 2016 01 08 at 11 41 42 PM

Once all changes have been made, close the Edit VM window and click the Launch VM button.

5. The VM launches, using the ISO file as the boot disk, to begin the process of installing the chosen Linux distro.

Screen Shot 2016 01 08 at 11 42 25 PM

Screen Shot 2016 01 08 at 11 42 59 PM

Veertu also offers an in-app purchase option (currently priced at $39.99) which unlocks the ability to install Windows or other Linux distros using either an optical drive or a user-provided ISO file. The installation process looks like this:

1. In the Create New VM window, select Install your own VM from ISO or DVD then click the Next button.

Screen Shot 2016 01 08 at 11 27 47 PM

Screen Shot 2016 01 08 at 11 27 48 PM

2. Name the VM as desired, then select to install from an ISO file or the optical drive.

Screen Shot 2016 01 09 at 12 53 13 AM

Screen Shot 2016 01 09 at 12 53 32 AM

3. Once the ISO or optical drive is selected, click the Next button.

Screen Shot 2016 01 09 at 12 53 40 AM

4. Choose the OS which is being installed into the VM.

Screen Shot 2016 01 09 at 12 54 02 AM

Screen Shot 2016 01 09 at 12 54 11 AM

Screen Shot 2016 01 09 at 12 54 23 AM

5. Once the OS has been selected, click the Next button.

Screen Shot 2016 01 09 at 12 54 29 AM

6. A summary of the VM’s default settings will be displayed.

Screen Shot 2016 01 09 at 12 54 32 AM

A. If the settings look fine as-is, click the Launch VM button.

Screen Shot 2016 01 09 at 12 54 33 AM

B. If there are settings which need to be changed from the defaults, click the Customize button and make any changes needed in the Edit VM window.

Screen Shot 2016 01 09 at 12 54 34 AM

Screen Shot 2016 01 09 at 12 54 50 AM

Screen Shot 2016 01 09 at 12 54 43 AM

Screen Shot 2016 01 09 at 12 54 53 AM

Once all changes have been made, close the Edit VM window and click the Launch VM button.

7. The VM launches, using the optical drive or ISO file as the boot disk, to begin the process of installing the chosen OS into the VM.

Screen Shot 2016 01 09 at 12 55 43 AM

Screen Shot 2016 01 09 at 12 55 53 AM

Once a VM is created, Veertu stores the VM at the following location:

/Users/username_goes_here/Library/Containers/com.veertu.Veertu/Data/VM Library/

Screen Shot 2016 01 08 at 11 45 29 PM

As of this date, only Linux and Windows VMs are being supported. OS X VMs are not supported yet, but that option should be available in a future Veertu release.


Limitations

In working with Veertu, I’ve noticed that it has some limitations.

A. Bridged networking is not supported:

Veertu VMs are not able to use bridged networking, which is important because you must have a bridged network connection in order to PXE boot or NetBoot. Instead, Veertu VMs support using NAT networking or host-only networking.

B. Unable to change location of VMs:

As of this date, VMs created by Veertu must be stored in the com.veertu.Veertu container in ~/Library/Containers.

C. Unable to retain ISO files downloaded from Veertu’s online library:

Each time a new VM is created using the option of using Veertu’s online library of Linux ISOs, Veertu needs to download the ISO again.


FIPS 140-2 validation and FileVault 2

$
0
0

One question I’ve seen which has caused confusion for folks who deal with security regulations is this: Is FileVault 2 FIPS 140-2 validated?

The answer is: Yes, depending on the version of OS X

The cryptography used by FileVault 2 on the following versions of OS X has gone through the FIPS certification process and has been validated as being as being FIPS 140-2 Compliant:

OS X 10.11 is currently in the process of becoming FIPS 140-2 validated. The reason El Capitan is not automatically FIPS 140-2 validated has to do with OS X’s CoreCrypto cryptography foundation and how the FIPS 140-2 certification process works.

FIPS certification

The FIPS certification process tests a specific cryptographic module used inside a system to protect information. It also applies only to a cryptographic module used in a shipping product; the cryptographic module in question can’t be a prototype or in beta. 

Another important thing to know is that the testing is very specific and applies only to the cryptographic module submitted for review. If the vendor changes anything in the cryptographic module, it loses its FIPS certification and has to be resubmitted for laboratory testing and government review.

There are three major phases in the process:

Phase 1: Design and Documentation

In order to prepare for the FIPS validation process, the cryptographic module in question has to be designed to pass the various tests involved and also be properly documented. This is the part of the process which the vendor has the most control over.

Phase 2: Laboratory Testing

Once the cryptographic module has been designed, documented and shipped, it is submitted to a third-party accredited Cryptographic and Security Testing (CST) laboratory to test the module(s) in question against FIPS 140-2’s qualitative levels of security. This testing can take an indeterminate amount of time, depending on how well the cryptographic module is designed and documented.

Best case: A cryptographic module that properly meets the requirements and with all required documentation written correctly can complete its laboratory testing in two to three months.

Phase 3: Government Review

After the lab has tested the cryptographic module, a report on the testing is submitted to the Cryptographic Module Validation Program (CMVP) for review. CMVP is a joint US-Canadian program that reviews all the test reports, with the CMVP Validation Authorities being the National Institute of Standards and Technology (NIST) for the US Government and the Communications Security Establishment (CSE) for the Government of Canada. This review can also take an indeterminate amount of time, depending on how many test reports need review, and can range from two months to eight months.

Apple and CoreCrypto

Apple’s CoreCrypto library is used by various components in OS X to provide low level cryptographic primitive support. This is the cryptographic library which is submitted by Apple to the FIPS 140-2 certification process.

With every version of iOS and OS X, Apple has made changes to CoreCrypto. As part of making those changes, Apple has had to resubmit CoreCrypto to laboratory testing and government review as part of the FIPS 140-2 certification process.

Apple’s stated intention is to continue FIPS 140-2 validation for OS X’s CoreCrypto cryptography foundation, which would also cover FileVault 2 on future versions of OS X, but the certification process itself can only be begun once that future OS has been released. Meanwhile, as noted above, the testing and governmental review process will take months to complete.

The good news is that it’s possible to at least see where Apple is in the process. NIST has a website where the current list of modules in the process can be viewed via a PDF which is updated weekly. To check for Apple’s progress, search the PDF for entries where Apple, Inc. is listed as the vendor.

Apple’s existing FIPS certifications are also available for reference via the link below:

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm


Creating an Office 2016 15.18.0 installer

$
0
0

Microsoft recently released a new software installer to help make the task of deploying updated copies of Office 2016 for Mac admins a lot easier. This new installer is available along with the latest Office 2016 volume license installer and is named Microsoft_Office_2016_VL_Serializer.pkg.

Screen Shot 2016 01 14 at 9 44 13 AM

This installer is designed to do the following:

  • Activate an unlicensed version of Office 2016 and set it to use the volume license.
  • Convert an existing/activated version of Office 2016 for Mac to use the volume license.
  • Fix the volume license on a machine where the volume license isn’t being recognized.

The installer package (which must be downloaded from Microsoft’s volume license site) makes it possible to install an unlicensed copy of the Microsoft Office 2016 full installer and then set up that copy of Office 2016 to use your shop’s volume license for Office 2016. This is advantageous for the following reasons:

  1. Microsoft usually releases unlicensed Office 2016 full installers much sooner than they release the volume licensed Office 2016 full installer via Microsoft’s volume license site.
  2. Unlicensed Office 2016 full installers can be downloaded from the internet without requiring access to Microsoft’s volume licensing site.

For example, as of January 14, 2016, the latest version of Office 2016 is Office 2016 15.18.0. Microsoft has released an unlicensed Office 2016 15.18.0 full installer for use with Office 365. Meanwhile, the Microsoft volume license site site has Office 2016 15.17.0 available for download.

Downloading an unlicensed Office 2016 full installer

  1. Go to http://macadmins.software (this site is run by Microsoft and is safe to download from.)
  2. Locate the O365/Retail download link (highlighted in bright green in the image below.)
  3. Download an unlicensed Office 2016 full installer which is up-to-date with the latest Office 2016 software

 Screen Shot 2016 01 14 at 9 49 42 AM

I have an existing process which can be used to build a combined Office 2016 installer using Packages, so I decided to apply the same process to building an Office 2016 15.8.0 installer. See below the jump for an example of using Packages to build a combined Office 2016 installer which includes both an unlicensed Office 2016 15.18.0 full installer and the Microsoft_Office_2016_VL_Serializer installer package.

Pre-requisites

  • Packages
  • Microsoft_Office_2016_VL_Serializer installer package
  • Unlicensed Office 2016 full installer package

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

Screen Shot 2016 01 14 at 9 44 39 AM

2. In this case, I’m naming the project Microsoft Office 2016 15.18.0

Screen Shot 2016 01 14 at 9 44 49 AM


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 4 – Configuring a project.)

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

Screen Shot 2016 01 14 at 9 45 03 AM

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 2016 01 14 at 9 45 26 AM
 

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

Screen Shot 2016 01 14 at 9 45 35 AM

6. Select your installers and drag them into the Additional Resources section of your Packages project.

In the case of my example, I’m selecting the following installers:

  • Microsoft_Office_2016_Installer.pkg (this is the unlicensed Office 2016 15.18.0 full installer)
  • Microsoft_Office_2016_VL_Serializer.pkg

Screen Shot 2016 01 14 at 9 53 37 AM

Screen Shot 2016 01 14 at 9 54 39 AM

7. The last piece is telling the installers to run. For this, you’ll need a postinstall script. Here’s the one I’m using:

Notice that $install_dir in the postinstall script refers to the path to the package’s working directory. That’s where Packages will be storing the installers, inside the Package-built installer’s embedded directory where it stores the items defined in the Additional Resources section.

The -target value is defined as “$3″ because some information is passed along by the Packages-built installer to its included scripts when those scripts are run by the installation process. (For more information, see the PackageMaker How-To available here and search on the page for $3)

In this case, -target being defined as “$3″ means that the postinstall script will install the two Office 2016 packages onto the desired drive.

The script also governs what order the installers run in, so the unlicensed Office 2016 installer runs first and the volume license serializer runs next after the first job finishes. The -dumplog and -verbose flags are to help you track the progress of installation if you’re looking at the installer log.

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

sudo chmod a+x /path/to/postinstall

10. Once completed, add the postinstall script to your Packages project.

Screen Shot 2016 01 14 at 9 55 47 AM

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

Once you have the package built, you should be able to test it by installing it on a machine while the machine is logged out. Once installed, Office 2016 15.8.0 should be properly licensed and not prompt you for a product key.


Suppressing Office 2016’s First Run dialog windows

$
0
0

As part of preparing to deploy Office 2016 in my own environment, I wanted to be able to suppress the various “What’s New” dialog windows which are displayed on Office 2016 applications’ first launch to market the applications’ features.

Screen Shot 2016 01 16 at 12 05 36 AM

Using the Microsoft Volume License installer to install Office 2016 (or using the volume license serializer package to install the volume license) will include automatic functionality to stop the version-specific “What’s New” dialog windows from appearing. However, I also needed to be able to suppress the initial “What’s New” dialog windows that appear the first launch of Office applications.

In order to suppress the initial “What’s New” dialog windows, certain settings need to be applied to the following files:

  • /Library/Preferences/com.microsoft.Outlook.plist
  • /Library/Preferences/com.microsoft.PowerPoint.plist
  • /Library/Preferences/com.microsoft.Excel.plist
  • /Library/Preferences/com.microsoft.Word.plist
  • /Library/Preferences/com.microsoft.onenote.mac.plist

Setting: kSubUIAppCompletedFirstRunSetup1507 – boolean value (true / false)
Function: Suppresses the “What’s New” dialog for Office 2016 applications’ first launch.
Applied to the following files:

/Library/Preferences/com.microsoft.Outlook.plist
/Library/Preferences/com.microsoft.PowerPoint.plist
/Library/Preferences/com.microsoft.Excel.plist
/Library/Preferences/com.microsoft.Word.plist
/Library/Preferences/com.microsoft.onenote.mac.plist

Setting: FirstRunExperienceCompletedO15 – boolean value (true / false)
Function: Suppresses additional “What’s New” dialog for Outlook and OneNote.
Applied to the following files:

/Library/Preferences/com.microsoft.Outlook.plist
/Library/Preferences/com.microsoft.onenote.mac.plist

Note: That is a capital letter O in O15, not zero15.

Setting: SendAllTelemetryEnabled – boolean value (true / false)
Function: Suppresses the offer to send crash reports to Microsoft.
Applied to the following files:

/Library/Preferences/com.microsoft.Outlook.plist
/Library/Preferences/com.microsoft.PowerPoint.plist
/Library/Preferences/com.microsoft.Excel.plist
/Library/Preferences/com.microsoft.Word.plist
/Library/Preferences/com.microsoft.onenote.mac.plist

To automate the deployment of these settings, I’ve developed a script. For more details, see below the jump.

This script is designed to check for individual Office 2016 applications. If an Office 2016 application is found on the Mac in question, the specific settings to suppress the “What’s New” dialog for that application are applied.

The script and an associated payload-free package are available on Github at the following address:

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


Payload-free package slides from the January 2016 MacDMV meeting

Controlling the Diagnostics & Usage report settings on El Capitan

$
0
0

One of the pop-up windows you get on first login to Yosemite and El Capitan is the Diagnostics & Usage pop-up window. This window requests permission for the following:

  1. Send diagnostics and usage data to Apple
  2. Share crash data with non-Apple developers

Screen Shot 2016 01 21 at 10 07 46 AM

 

I’ve been suppressing this window on OS X Yosemite by setting the values shown below in /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist

<key>AutoSubmitVersion</key>
<integer>5</integer>
<key>AutoSubmit</key>
<false/>
<key>ThirdPartyDataSubmitVersion</key>
<integer>5</integer>
<key>ThirdPartyDataSubmit</key>
<false/>

On OS X El Capitan, it looks like the numeric value set for the AutoSubmitVersion and ThirdPartyDataSubmitVersion settings has changed from 4 to 5. The new settings should look like this:

<key>AutoSubmitVersion</key>
<integer>5</integer>
<key>AutoSubmit</key>
<false/>
<key>ThirdPartyDataSubmitVersion</key>
<integer>5</integer>
<key>ThirdPartyDataSubmit</key>
<false/>

For more details, see below the jump.

I’ve updated the script which I had previously written for Yosemite, so that it now sets the proper numeric value for the AutoSubmitVersion and ThirdPartyDataSubmitVersion settings on Yosemite and El Capitan in /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist. The updated script is available below, and also from my Github repo:

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

 

This script sets whether you want to send diagnostic info from Yosemite and later back to Apple and/or third party app developers by applying the appropriate values in /Library/Application Support/CrashReporter/DiagnosticMessagesHistory.plist.

If you want to send diagnostic and usage data to Apple, set the following value in the script for the SUBMIT_DIAGNOSTIC_DATA_TO_APPLE setting:

SUBMIT_DIAGNOSTIC_DATA_TO_APPLE=TRUE

If you want to send crash data to non-Apple developers, set the following value in the script for the SUBMIT_DIAGNOSTIC_DATA_TO_APP_DEVELOPERS setting:

SUBMIT_DIAGNOSTIC_DATA_TO_APP_DEVELOPERS=TRUE

By default, the values in this script are set to send no diagnostic data, either to Apple or to non-Apple developers:

SUBMIT_DIAGNOSTIC_DATA_TO_APPLE=FALSE
SUBMIT_DIAGNOSTIC_DATA_TO_APP_DEVELOPERS=FALSE

To change this in your own script, comment out the FALSE lines and uncomment the TRUE lines as appropriate.

 

Hat tip to Shea Craig for letting me know that the numeric values for the AutoSubmitVersion and ThirdPartyDataSubmitVersion settings had changed between Yosemite and El Capitan.



Suppressing the iCloud and Diagnostics pop-up windows on El Capitan using profiles

$
0
0

After posting how to control the Diagnostics & Usage report settings on El Capitan, I was tipped off that there were new ways available on OS X El Capitan to manage both the Diagnostics and the iCloud pop-up windows using profiles.

The profile settings can be seen via Server 5.x’s Profile Manager and currently apply only to OS X El Capitan. For more information, see below the jump.

The iCloud pop-up window can be managed via the Login Window profile payload. To suppress the iCloud pop-up window, click on the Options tab for that payload in Profile Manager and check the Disable Apple ID setup during login option.

Screen Shot 2016 01 27 at 9 52 32 PM

The Diagnostics pop-up window can be managed via the Security & Privacy profile payload. To suppress the Diagnostics pop-up window, click on the Privacy tab for that payload in Profile Manager and uncheck the Allow sending diagnostic and usage data to Apple, and sharing crash data and statistics with app developers option.

Screen Shot 2016 01 27 at 9 53 37 PM

For those folks not using Profile Manager to manage their Macs, I’ve created two profiles, one for suppressing each pop-up window, and made them available for download from my GitHub repo:

 

Both profiles can be used as-is, but both include the following genericized information:

PayloadOrganization: includes Company Name
PayloadIdentifier: includes com.github

If the genericness is an issue, edit the profiles where needed.

Hat tip to @mboylan for pointing me towards the new profile settings.


Installing Endnote X7.5’s Cite While You Write plug-ins for Office 2008, 2011 and 2016

$
0
0

Thomson Reuters has released Endnote X7.5, an updated version of their Endnote bibliography software. This updated version had been long-awaited by a number of folks because it added support for Word 2016.

I have an existing process for deploying and licensing Endnote X7.x and I found that the site license which I’ve been using with previous versions of Endnote X7.x also worked fine with 7.5. One thing that did not work was Endnote X7.5 automatically deploying its Cite While You Write (CWYW) plug-ins for Word 2008, 2011 and 2016.

Screen Shot 2016 02 02 at 3 02 20 PM

In previous versions of Endnote, Endnote’s first launch triggered an assistant which installed the CWYW plug-ins to their correct location. Endnote X7.5, or at least Endnote X7.5’s trial version, appeared to lack this functionality. In addition, the CWYW plug-ins for Word 2016 need to be installed into a completely different location than for previous versions of Word:

  • Word 2008: /Applications/Microsoft Office 2008/Office/Startup/Word
  • Word 2011: /Applications/Microsoft Office 2011/Office/Startup/Word
  • Word 2016: /Library/Application Support/Microsoft/Office365/User Content.localized/Startup.localized/Word

Unlike previous versions of Microsoft Office, the Word 2016 support directories were also not created by Office 2016 by default, so they were not likely to exist unless a third-party plug-in for Word had previously been installed.

Screen Shot 2016 02 02 at 3 01 23 PM

To address the various issues identified, I wrote a script. For more details, see below the jump.

The script is designed to do the following:

  1. Remove existing Endnote CWYW plug-ins for Word 2008, Word 2011 and Word 2016
  2. Detect if Word 2016 is installed and add the appropriate support directories if needed.
  3. Detect which version(s) of Microsoft Office are installed and install new copies of the appropriate Endnote CWYW plug-ins

The script is also available on Github at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/endnote_x7_plug-in_installation


Word 2016 and Endnote’s “com.ThomsonResearchSoft.EndNote.plist” dialog window

$
0
0

Microsoft Office 2016’s applications are sandboxed, which means that they don’t have access to external files and settings by default and need to ask permission from the user. Thomson Reuters’ Endnote software is affected by this because it uses a plug-in for Word 2016. This means that the first time you launch Word 2016 after installing Endnote’s plug-in, you will see a dialog box along with this message:

EndNote needs access to the file named ‘com.ThomsonResearchSoft.EndNote.plist’. Select this file to grant access.

If you’re seeing this dialog box, the com.ThomsonResearchSoft.EndNote.plist file should be already selected. If the file has been selected, please click the Grant Access button. This procedure should only need to be performed once.

Screen Shot 2016 02 05 at 7 51 34 AM

 

However, if you’re seeing this dialog box and the com.ThomsonResearchSoft.EndNote.plist file has not been automatically selected, that means that Endnote has been installed on this Mac but never launched. For more details, see below the jump.

To fix this issue, please use the procedure below:

1. Click the Cancel button in the dialog box.

Screen Shot 2016 02 05 at 7 50 05 AM

2. Quit Word
3. Launch Endnote
4. Launch Word
5. You should see the dialog box again along with this message:

EndNote needs access to the file named ‘com.ThomsonResearchSoft.EndNote.plist’. Select this file to grant access.

This time, the com.ThomsonResearchSoft.EndNote.plist file should be selected.

6. Click the Grant Access button.

Screen Shot 2016 02 05 at 7 51 34 AM

 

This procedure should only need to be performed once. For more information, please see the links below:

http://endnote.com/kb/136020

http://endnote.com/kb/138936


Slides from the “FileVault 2 Decrypted” Session at MacAD UK Conference 2016

Getting started as a Mac admin

$
0
0

To close out MacADUK 2016, there was a panel discussion about the non-technical skills involved with being a Mac admin. One question was something like this:

“How should a new Mac admin get started?”

The folks on the panel (including myself) had a few answers for this, including doing research and finding a good mentor. I didn’t realize it at the time, but my brain had also filed it away for some further processing because it’s a dang good question and deserves more than the few minutes that we were able to devote to it. Because everybody’s different, I’ll just say what my opinions are on the subject.

1. Figure out if this is what you want to do.

You want to be happy in your career, right? Honestly, the first thing to figure out is if going into IT, and Macs specifically, is the way you want to go.

In my case, I figured it out back in college while working for the campus computer labs in the 1990s. The lab I worked in was for the engineering school and had a bit of everything: Macs, PCs running Windows 3.1, and Sun Microsystems boxes running SunOS. I found the Macs easier and more intuitive to work with than the other OSs, and I learned on-the-job how to fix them.

If you’re looking to figure out if this is what you want to do, getting an internship or an entry-level job in the field is a good way to learn. Working at an Apple store, with an eye towards getting on the Genius Bar, is another entryway that a number of new Mac admins have emerged from in recent years.

2. Figure out the best way you learn things. Learn stuff that way. Accept that the learning never stops. Repeat.

The most important element of your Mac admin career is having the skills to do the job. This is an ongoing learning process which you pick up through both training and experience.

How you learn best is going to be different for everyone. Some folks go to training classes and frankly get nothing from them, while classroom instruction is the best way someone else can learn. Ditto for books. Ditto for professional conferences. Figure out how you learn best, then pursue that method to help you accumulate the various skills you’ll need for this career path. If someone suggests an alternate way, try it! But the most important thing is finding what works for you.

In my case, I tend to learn best these ways:

A. Googling – Whenever I’ve got a problem that I’m not sure how to solve, my first stop is Google. I’ve found that very few problems are genuinely new under the sun and searching online may turn up the solution to a problem that you’ve been banging your head against. The solution may not all be in one place. Part may be in a StackExchange post, another part may be in a blog post, yet another part may be through searching GitHub. But a lot of answers to the issues you’re seeing are out there; you just need to find them.

B. Asking questions – We all get along with a little help from our friends, and the Mac admin community is pretty friendly. Asking questions in the MacAdmin Slack community, on the MacEnterprise mailing list, or on Twitter via the #macadmin or #macadmins hashtag, has helped me out a lot.

When should you ask questions of your fellow Mac admins? After you’ve done some research. You may find that the research answers your original question and leads you to ask even better questions, which in turn will make for a better discussion of your problem.

C. Testing – If the question is “What happens if I do X?”, the best answer many times is “Try it and see!”.

As part of this, I’ve got a couple of rules I go by when testing:

i. Have a test environment which is separate from your production environment – Test environments are meant to go * BOOM * on occasion, that’s why you have them. Production is sacred, don’t test things where it may affect the folks you support.

ii. Whenever possible, use virtual machines when testing – Picking up a copy of VMware Fusion or Parallels and running your tests inside VMs running OS X may be what saves you from hosing your own Mac when something unexpected goes wrong.

D. Find problems, then solve them – One of the most frequent ways I’ve learned new things is in passing, while I’m trying to solve a problem. Maybe it’s a problem just for me, maybe it’s a problem for a lot of people, including me. Maybe it’s a problem that’s not actually a problem for me, but it’s a problem for someone else. Any way you slice it, they’re all problems and the journey you take when solving problems is a great way to learn.

E. Documenting – I’ll be the first person to tell you that I have a terrible memory. Writing things down in a lot of detail does two things for me:

i. It actually helps my memory – By going through the process of writing up a problem and its solution, I actually remember more details later from memory.
ii. It’s a prosthetic memory – I don’t have to remember everything, I wrote it down so I didn’t have to. What I need to know is where I documented it, and search functions help out a lot there (see my earlier point about Googling.)

3. Find a mentor

One of the best ways to get experience is finding a good mentor and working with them to get the benefit of their own experiences. This may be tough if you’re the lone Mac admin in your shop, but you may also be able to find one (or several) online, again via the MacAdmin Slack community or via Twitter, or via meeting someone at a professional conference and then working with them via email or other ways of communicating online.

4. You will make mistakes

Nobody is perfect, nobody knows everything and failure is always an option. Accept that, and plan how to minimize the consequences to others from your mistakes.

I always try to learn from my mistakes, and some days it feels like I’m learning constantly. But I work very hard to make sure others aren’t affected by the commission and consequences of my mistakes. It’s not only the right thing to do, it will save you time because you’ll only have to fix your stuff and not have to fix others’ stuff as well.

5. Be flexible

There may be multiple ways to solve your problem; be open to alternate approaches. The important thing is solving the problem and there’s usually more than one way.

6. Accept that the solution you adopt today may not be the solution you need tomorrow

Over the past 18 years, I’ve seen Apple change some pretty fundamental things:

You have to be able to pick up which direction Apple is signaling that it’s moving to, and adjust your tools and solutions to match that direction. Sometimes that may mean you have to stop using a tool that’s worked for you a long time and pick up a new one to learn from scratch. Be prepared for that possibility and embrace those changes when you see them coming.

To close out, welcome to the craft! This is a really good time to start being a Mac admin, as Apple’s gear is on the ascendant in a number of places it traditionally hasn’t been and it’s an exciting time to be a part of it. Good luck, and may you have great success.


Certificate expiration and downloaded Mac App Store installers

$
0
0

Mac admins who have previously downloaded installers from the Mac App Store may be seeing some of those installers displaying warning messages and/or failing to install as of this morning.

Screen Shot 2016 02 15 at 8 20 31 AM

This behavior is now appearing because the certificate Apple had been using to digitally sign installers for MAS apps has recently expired.

Screen Shot 2016 02 15 at 8 20 35 AM

Apple is handling the issue on their end by reissuing installers, which are signed with an updated certificate that expires on February 7, 2023. If a needed application with the correct version is still available from the MAS, the easiest fix may be to re-download the installer from the MAS. The newly-downloaded installer will be signed with the new certificate.

Screen Shot 2016 02 15 at 8 20 12 AM

In the case of applications where the needed version is no longer available from the MAS, or the application itself is no longer available, there are two ways to handle this issue:


Creating password-protected PDFs on OS X

$
0
0

If you want to restrict access to a PDF document, one way to do this is by setting a password on it. Thanks to OS X’s built-in PDF creation tools, it’s relatively straightforward on OS X to add a password to an existing PDF document, or include a password as part of the process of creating a PDF. For more details on this process, see below the jump.

Adding a password to an existing PDF document

Apple has an existing KBase article describing the process of password-protecting a PDF:

1. Open the PDF you want to password-protect in Apple’s Preview.

Screen Shot 2016 02 19 at 10 12 16 AM

 

2. Under the File menu, select Export…

Screen Shot 2016 02 20 at 8 56 01 PM


3. Check the Encrypt checkbox.

Screen Shot 2016 02 20 at 8 56 10 PM

 

4. Type the password you want to use to protect the PDF, then retype it to verify.

5. Once finished entering the password, choose the filename for the password-protected PDF and then click the Save button.

Screen Shot 2016 02 20 at 8 56 27 PM

 

Adding a password as part of creating a PDF from a document

The process is slightly different if you want to create a PDF from a non-PDF document and add a password as part of the PDF creation process.

1. Open the document from which you want to create a password-protected PDF.

Screen Shot 2016 02 20 at 8 31 18 PM

 

2. Under the File menu, select Print…

Screen Shot 2016 02 20 at 8 53 33 PM


3. In the Print window, select the PDF drop-down menu.

Screen Shot 2016 02 20 at 8 53 53 PM

 

4. In the PDF menu, select Save as PDF…

Screen Shot 2016 02 20 at 8 54 07 PM


5. In the next window, select Security Options…

Screen Shot 2016 02 20 at 8 54 25 PM


6. Check the box for Require password to open document.

Screen Shot 2016 02 19 at 10 33 17 AM

 

7. Type the password you want to use to protect the PDF, then retype it to verify.

8. Once finished entering the password, click the OK button.

Screen Shot 2016 02 20 at 8 54 45 PM

 

9. Choose the filename for the password-protected PDF and then click the Save button.

Screen Shot 2016 02 20 at 8 54 26 PM

 

Once the password-protected PDF has been created, it should appear with a lock icon as part of the file icon.

Screen Shot 2016 02 19 at 10 15 09 AM

 

Now that the PDF has been password-protected, you should be prompted to enter a password before being given access to the contents of the PDF.

Here’s how it should appear in Apple Preview:

Screen Shot 2016 02 19 at 10 15 17 AM

 

Here’s how it should appear in Adobe Acrobat Reader DC:

Screen Shot 2016 02 19 at 10 18 03 AM



Apple security update blocks Apple Ethernet drivers on OS X El Capitan

$
0
0

Over the weekend, Apple released an update for a kernel extension blacklist used by System Integrity Protection on OS X El Capitan. This blacklist is a security measure to help Apple block kernel extensions which have been found to be harmful or problematic for OS X. This update belonged to a category of updates which Apple has set to install automatically and in the background, so its installation would have been both automatic and invisible.

Unfortunately, this blacklist update appears to have inadvertently contained the kernel extension information for Apple’s own Ethernet drivers. This is a problem because blocking the Ethernet drivers means your Mac will not be able to connect to your network via an Ethernet connection.

Apple appears to have quickly recognized the problem and has released a follow-up update which fixes this issue.


Update – 10-28-2016: Apple has posted a knowledgebase article about this issue: https://support.apple.com/HT6672

The good news:

  1. This issue does not affect your Mac’s WiFi connection. WiFi has separate drivers which were not affected.
  2. If the Ethernet drivers are blocked, but the Mac has not yet rebooted, your Ethernet connection will remain working until the next time the Mac reboots.
  3. The follow-up update which fixes the problem may already be installed on your Mac.

For more information, see below the jump.

To see if you have the problem update installed, use the procedures below:

Checking via the System Information application:

1. Open the System Information application in /Applications/Utilities

Screen Shot 2016 02 27 at 10 25 29 PM

2. Go to the Software: Installations section and search for the following entries:

Incompatible Kernel Extension Configuration Data 3.28.1 – This contains the blacklist update which blocks Apple’s Ethernet driver software

Screen Shot 2016 02 27 at 9 44 14 PM

Incompatible Kernel Extension Configuration Data 3.28.2 – This contains the follow-up update which removes Apple’s Ethernet driver software from the blacklist.

Screen Shot 2016 02 27 at 9 41 21 PM

Checking via the command line:

1. Open Terminal
2. Run the following command:

cat /var/log/install.log | grep com.apple.pkg.IncompatibleKextConfigData.14U2129

If you get a result like this, the Incompatible Kernel Extension Configuration Data 3.28.1 update was installed:

Feb 26 22:02:45 computername system_installd[14244]: PackageKit: Writing system content receipt for com.apple.pkg.IncompatibleKextConfigData.14U2129 to /

3. Next, run the following command to see if the Incompatible Kernel Extension Configuration Data 3.28.2 update which fixes this issue was also installed:

cat /var/log/install.log | grep com.apple.pkg.IncompatibleKextConfigData.14U2130

If you get a result like this, the follow-up Incompatible Kernel Extension Configuration Data 3.28.2 update that fixes the problem was installed:

Feb 27 20:28:23 computername system_installd[527]: PackageKit: Writing system content receipt for com.apple.pkg.IncompatibleKextConfigData.14U2130 to /

If you have the Incompatible Kernel Extension Configuration Data 3.28.1 update installed, but do not yet have the Incompatible Kernel Extension Configuration Data 3.28.2 update installed, the Ethernet drivers for your Mac will be blocked from running the next time the Mac is restarted. That will result in your Mac not being able to connect to your network via an Ethernet connection.

To fix this, the Incompatible Kernel Extension Configuration Data 3.28.2 update needs to be installed and the Mac rebooted again. After this reboot, the Ethernet drivers should be enabled again and your Mac’s Ethernet connection should work normally again.

To install the Incompatible Kernel Extension Configuration Data 3.28.2 update:

  1. Verify you have a working connection to the Internet
  2. Open Terminal
  3. Run the following command with root privileges:
softwareupdate --background-critical

Screen Shot 2016 02 27 at 10 33 23 PM

Running the softwareupdate –background-critical command forces a check-in with Apple’s software update service and will trigger your Mac to automatically install the Incompatible Kernel Extension Configuration Data 3.28.2 update.

For those interested in checking the affected kernel extension blacklist, it is stored in the following location:

/System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist

When the Incompatible Kernel Extension Configuration Data 3.28.1 update is installed, the /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist file is updated with the following entries, which add Apple’s Ethernet drivers to the kernel extension blacklist:

<key>com.apple.iokit.AppleBCM5701Ethernet</key>
<string>LT 10.2.0</string>
<key>com.apple.iokit.AppleYukon2</key>
<string>LT 4.0.0</string>

Screen Shot 2016 02 27 at 8 17 46 PM

When the Incompatible Kernel Extension Configuration Data 3.28.2 update is installed, those entries are removed:

Screen Shot 2016 02 27 at 8 43 53 PM


Using pmset on OS X to schedule restarting your Mac

$
0
0

OS X’s pmset command line tool is designed to control power management settings on your Mac, but it also has various options for scheduling your Mac to perform various actions at set times using the following format:

pmset repeat type weekdays time

The various types documented in pmset’s man page are as follows:

  • sleep – puts the Mac to sleep
  • wake – wakes the Mac from sleep
  • poweron – starts up the Mac if the Mac is powered off
  • shutdown – shuts down the Mac
  • wakeorpoweron – depending on if the Mac is off or asleep, the Mac will wake or start up as needed

The weekday options are as follows:

  • M = Monday
  • T = Tuesday
  • W = Wednesday
  • R = Thursday
  • F = Friday
  • S = Saturday
  • U = Sunday

The time option documented in the man page is as follows:

  • HH:mm:ss

The time must be set in 24 hour format, with a leading zero for numbers less than 10.

Examples of this would be:

4:00 AM = 04:00:00
1:00 PM = 13:00:00
12:00 AM (midnight) = 00:00:00

These options all match what shows up in the Energy Saver preference pane’s scheduling options, with one exception. There is a Restart option in the Energy Saver settings which doesn’t appear to have a documented type in the pmset man page.

Screen Shot 2016 02 26 at 10 23 05 PM

 

The answer turns out to be that there is a undocumented restart type which is not listed on the pmset man page. For more information, see below the jump.

This restart type can be used like the other types with pmset. For example, if you want to schedule a Mac to automatically restart every day at midnight, run the command shown below with root privileges:

/usr/bin/pmset repeat restart MTWRFSU 00:00:00

Screen Shot 2016 02 28 at 7 11 00 PM

 

If you want to schedule a Mac to automatically restart at 11:59 PM on Monday, Wednesday, Friday and Sunday, run the command shown below with root privileges:

/usr/bin/pmset repeat restart MWFU 23:59:00

Screen Shot 2016 02 28 at 7 11 28 PM

Once a schedule has been set, the Mac will restart at the specified times. If the Mac is logged in, a dialog window similar to the one shown below will appear.

Screen Shot 2016 02 29 at 12 00 04 AM

 

The desired restart time should show up in the Energy Saver preference pane’s scheduled options, which is accessible using the following procedure:

1. Open System Preferences
2. Select the Energy Saver preference pane

Screen Shot 2016 02 28 at 7 09 28 PM

3. Click the Schedule… button

Screen Shot 2016 02 28 at 7 09 45 PM

4. The desired schedule should be listed.

Screen Shot 2016 02 28 at 7 11 39 PM

 

Note: If you have selected several, but not all weekdays, the schedule window will display Weekdays for the daily interval.

Screen Shot 2016 02 28 at 7 31 36 PM

 

You can also check the settings in the following file:

/Library/Preferences/SystemConfiguration/com.apple.AutoWake.plist

Screen Shot 2016 02 28 at 7 12 59 PM


Deploying Word, Excel and PowerPoint templates for Microsoft Office 2016

$
0
0

In many shops, Mac admins have a requirement to deploy templates for Microsoft Word, Excel or PowerPoint. With Microsoft Office 2011, this is a relatively straightforward process as there is an existing directory for Word, PowerPoint and Excel templates at the location shown below:

/Applications/Microsoft Office 2011/Office/Media/Templates

Template files deployed to this location are available to all users on the Mac.

Screen Shot 2016 03 05 at 9 29 10 PM

 

In contrast, the necessary support directories for templates are not created by Office 2016 by default, so they are not likely to exist unless templates had previously been installed. The reason for this is that Office 2016 apps are sandboxed and don’t have the ability to write to locations outside the application sandbox unless granted permission. Fortunately, the Office team at Microsoft has documented in the PDF document linked below where templates should be installed:

Installing User Content in Office 2016 for Mac:
http://macadmins.software/docs/UserContentIn2016.pdf

When I read the documentation, it showed that the correct place to store template files is at the location shown below:

/Library/Application Support/Microsoft/Office365/User Content.localized/Templates.localized

Template files deployed to that location are available to all users on the Mac.

Screen Shot 2016 03 05 at 10 12 32 PM

 

As mentioned previously, the necessary support directories for templates are not created automatically when Office 2016 is installed. To address this, I’ve written a script that will create the needed directory structure. For more information, see below the jump.

The script shown below is designed to do the following:

  1. Create the directories needed for Office 2016 Word, Excel and PowerPoint templates
  2. Assign those directories the following permissions:
  • root: Read, Write, Execute
  • admin: Read, Write, Execute
  • Everyone: Read, Execute

The script is also available from my Github repo:
https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/create_office_2016_template_directory


Using AutoPkg recipes with alternate software downloads

$
0
0

An issue that crops up occasionally for AutoPkg is that a vendor will release a new version of their software but be slow to update the download location which an AutoPkg recipe is looking at. Alternatively, there may be instances where a software vendor releases two versions of their software and AutoPkg only picks up one of them. A good example of this is Oracle’s Java 8, where the past few releases of Java 8 have actually had two versions of Java 8 released simultaneously.

Fortunately, if you can manually download the needed software, there is a way to leverage AutoPkg to generate the needed installer without needing to change your AutoPkg recipe. See below the jump for details.

To use Oracle’s release behavior as an example, Oracle currently has Java 8 Update 73 and Java 8 Update 74 available. What’s the difference between Update 73 and Update 74? Update 73 is a Critical Patch Update (CPU), which contains both fixes to security vulnerabilities and critical bug fixes. Update 74 is a Patch Set Update (PSU), which means it contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems. So the short version is that Update 73 has “critical bug fixes” and Update 74 has “Update 73’s bug fixes, plus more bug fixes.”

For those interested in more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

AutoPkg’s Java 8 .download recipes will download Java 8 Update 73, but it will not detect or download Java 8 Update 74. To address this issue, the disk image for Java 8 Update 74 can be manually downloaded and then 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

Specifying the -p option tells AutoPkg not to download the software as it normally would, but instead use the referenced installer package or disk image in place of what would normally be downloaded.

For those that would need to have Java 8 Update 74, you would use the -p or –pkg option for AutoPkg’s run function and reference a Java 8 Update 74 disk image when running your recipe. In this example, I’m using a OracleJava8.pkg recipe:

autopkg run OracleJava8.pkg -p /path/to/downloaded_Java_8_disk_image.dmg

Screen Shot 2016 03 15 at 3 03 32 PM

Instead of AutoPkg downloading Java 8 Update 73 from Oracle’s website and creating a Java 8 Update 73 installer, the disk image containing the Java 8 Update 74 installer is referenced by the OracleJava8.pkg recipe and a Java 8 Update 74 installer package is generated.

Screen Shot 2016 03 15 at 3 06 02 PM


Speaking at X World 2016

Viewing all 764 articles
Browse latest View live