For those who wanted a copy of my MDM talk at the MacDeployment 2019 conference, here are links to the slides in PDF and Keynote format.

PDF – https://tinyurl.com/MacDeploy2019PDF

Keynote – https://tinyurl.com/MacDeploy2019Keynote

Since its initial release in OS X Mountain Lion 10.8.x, Apple’s main tool for managing FileVault 2 encryption has been fdesetup. With the transition from managing Core Storage-based encryption on HFS+ to managing the native encryption built into Apple File System completed, this well-developed toolset continues to be Apple’s go-to tool for enabling, configuring and managing FileVault 2 on macOS Mojave.

With its various functions, fdesetup gives Mac administrators the following options for managing FileVault:

• 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

For more details, please see below the jump.

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, FileVault will enable and you’ll be given an alphanumeric personal recovery.

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 FileVault will turn on. All of the accounts specified should appear at the FileVault 2 pre-boot login screen.

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 FileVault turns on. All of the accounts specified in the plist file should appear at the FileVault 2 pre-boot login screen.

To avoid the need to enter a password, fdesetup also has a -defer flag 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.

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

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

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

Once entered, FileVault 2 will be enabled and the recovery information plist file will be created.

In addition to enabling FileVault 2 as part of the logout process, Apple added the ability to set a deferred enablement at login when they released OS X Yosemite. In macOS Mojave, 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

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

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.

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

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

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 macOS Mojave 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.

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

Note: On macOS 10.14.5, there is a bug with this command where a personal recovery is generated even though the -norecovery flag is specified.

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

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

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.

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

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

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

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

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

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

fdesetup remove -uuid UUID_here

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.

Managing Individual And Institutional Recovery Keys

fdesetup in macOS Mojave 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.

Note: To be prompted for the personal recovery key, leave the username blank when prompted for username. The next prompt will be for the current 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

You can also export the recovery key to a plist file using the -outputplist verb. To use a plist to import a plist with authentication credentials and export the new recovery key to a separate plist, run the following command with root privileges to change to a new personal recovery key, reference the password or recovery key in the plist file and export the recovery key to a new plist file:

fdesetup changerecovery -personal -inputplist  /path/to/new_recovery_key_filename.plist

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.

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:

fdesetup changerecovery -institutional -keychain -inputplist < /path/to/filename.plist

In the event that the Mac in question does not have an institutional recovery key, running the commands above will add an 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.

Note: To be prompted for the personal recovery key, leave the username blank when prompted for username. The next prompt will be for the current 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

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.

Note: To be prompted for the personal recovery key, leave the username blank when prompted for username. The next prompt will be for the current 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

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 macOS Mojave 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.

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.

One-Time Filevault 2 Encryption Bypass

fdesetup in macOS Mojave 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.

Note: To be prompted for the personal recovery key, leave the username blank when prompted for username. The next prompt will be for the current recovery key.

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:

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

fdesetup authrestart is not supported by all 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.

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

Zoom is a popular video conferencing suite which is used by a number of shops because it provides a consistent cross-platform experience. Recently, it was discovered that Zoom was setting up a local webserver process. This capability enabled Zoom’s client to be launched in response to clicking a URL, but it also potentially allowed someone to be forcibly connected to a Zoom call with their video camera active. This issue has been assigned the following CVE identifier:

CVE-2019-13450: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13450

Once this vulnerability was widely publicized, Zoom responded with an updated version of their Zoom client for macOS which removes the local webserver and also allows users to manually uninstall the Zoom client. They also provided the following manual remediation instructions:

I’ve taken those commands and used them to build a script to address the vulnerabilities described in CVE-2019-13450. For more details, please see below the jump.

The script is available below and on my GitHub repo:

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

This script is also available as a payload-free package on my GitHub repo, available for download from the payload_free_package directory available from the link above.

For those who wanted a copy of my installer scripting talk at Penn State MacAdmins 2019, here are links to the slides in PDF and Keynote format.

PDF – https://tinyurl.com/PSUMacAdmins2019PDF

Keynote – https://tinyurl.com/PSUMacAdmins2019Keynote

As part of the Zoom vulnerability issue, further problems have been discovered as security researchers look into the local webserver installed by older versions of the Zoom app for macOS.

Apple has moved quickly and released an update to MRT (Malware Removal Tool) which addresses the issue by removing the local webserver. This update has the following version number:

1.45.1.1562731315

The installer package receipt associated with it is the following:

com.apple.pkg.MRTConfigData_10_14.16U4071

To verify that you have this installed, here’s a one-line command to check for the latest installed MRT installer package:

To verify that com.apple.pkg.MRTConfigData_10_14.16U4071 does install 1.45.1.1562731315, here’s a one-line command to get the version number from the latest installed MRT installer package receipt:

To assist with getting information like this for Gatekeeper, MRT and XProtect, I’ve written a script that pulls the following information for each:

• Version number
• Installation date
• Installer package receipt identifier

For more information, please see below the jump.

As of Friday, July 12 2019, the script below is producing the following output for my Mac running macOS 10.14.5 with the latest MRT update installed:

As more security researchers look into the Zoom vulnerability issue, it now appears that Zhumu (Zoom’s affiliate for China) has a client for macOS with the same local webserver vulnerability as that previously discovered for Zoom’s and RingCentral’s clients for macOS.

For those wanting to manually remediate for all three clients, the following commands can be run:

The question at this point is: how many more Zoom variants are there out there? I hadn’t previously been aware of Zhumu or of Zoom’s business relationship with this company. Are there more?

I’ve updated my fix_zoom_vulnerability script to also address the Zhumu client. For more details, please see below the jump.

The script is available below and on my GitHub repo:

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

This script is also available as a payload-free package on my GitHub repo, available for download from the payload_free_package directory available from the link above.

Apple had released an MRT update on July 12th to cover the vulnerabilities disclosed for Zoom and RingCentral , but then additional Zoom variants popped up on the radar.

To fix all of the variants, Apple has released another MRT (Malware Removal Tool) update today. This fixes the vulnerabilities found in Zoom and its various white label versions which Zoom developed for third parties:

• Zoom
• RingCentral
• TelusMeetings
• BT Cloud Meetings
• Office Suite HD Meeting
• AT&T Video Meetings
• Biz Conf
• Huihui
• UMeeting
• Zhumu
• Zoom CN

This MRT update has the following version number:

1.46.1.1563225526

The installer package receipt associated with it is the following:

com.apple.pkg.MRTConfigData_10_14.16U4075

To verify that you have this installed, here’s a one-line command to check for the latest installed MRT installer package:

To verify that com.apple.pkg.MRTConfigData_10_14.16U4075 does install 1.46.1.1563225526, here’s a one-line command to get the version number from the latest installed MRT installer package receipt:

To assist with getting information like this for Gatekeeper, MRT and XProtect, I’ve written a script that pulls the following information for each:

• Version number
• Installation date
• Installer package receipt identifier

For more information, please see below the jump.

As of Tuesday, July 16 2019, the script below is producing the following output for my Mac running macOS 10.14.5 with the latest MRT update installed:

Suppressing Microsoft AutoUpdate’s Required Data Notice screen

As part of the latest update to Microsoft AutoUpdate app, a new screen has appeared which requires the logged-in user to click on it.

This screen is to notify users that Microsoft AutoUpdate collects diagnostic data for Microsoft and provides basic information on how to opt-out of the data collection. The overall point of the screen is to help Microsoft comply with the European Union’s General Data Protection Regulation (GDPR) and similar laws.

While this screen is fairly straightforward for an individual to deal with on their own Mac, it may cause challenges for computer labs because those facilities may remove and repopulate user home folders on each login. Since the setting which records that a user has seen the notification is stored in the user’s home folder, in the ~/Library/com.microsoft.autoupdate2.plist file, this may result in the lab’s users seeing this notification multiple times unnecessarily. To address this, Microsoft has made suppressing this screen possible by adding the following key and value to the com.microsoft.autoupdate2.plist file

• Key: AcknowledgedDataCollectionPolicy
• Value: RequiredDataOnly

This setting can be applied with a script or with a configuration profile. For more details, please see below the jump.

I’ve written a script and configuration profile to apply this setting. Either will work, but my personal preference would be to use the profile.

Script:

This script is also available on GitHub via the link below:

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

Profile:

This profile is also available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/master/DisableMAURequiredDataNotice

As part of some recent work, I needed to build a deployable installer package for an application named Zscaler. This application does not use an installer package, nor can it be installed as a drag-and-drop app. Instead, it uses a third party installer application to install.

This is exactly the kind of situation where I want to write an AutoPkg recipe to handle building a deployable installer package for me. As part of that, I had two bits of good news:

1. There was a publicly available download URL for the Zscaler installer app.
2. Zscaler has instructions for installing from the command line, so I could wrap up the installer application inside an installer application and use a postinstall script to run the installation process.

I had one bit of bad news:

The installer process included options for adding things like the Zscaler cloud instance which the app should talk to following the installation as well as various other options which probably shouldn’t be hardcoded into an Autopkg recipe. I especially shouldn’t be hardcoding my own organization’s credentials into a recipe which I was planning to share with other folks.

Normally, sensitive information is something I want to only have in an AutoPkg recipe override. Recipe overrides are locally-stored files that allow you to change certain input variables in AutoPkg recipes. Since the recipe overrides are stored locally on the Mac which is running AutoPkg and not shared with any other resources, the sensitive information is only made available to the AutoPkg installation running on that specific Mac. I’ve used this approach previously for the following:

Sensitive URLs: https://derflounder.wordpress.com/2017/06/12/autopkg-recipes-for-apple-enterprise-connect/
Signing AutoPkg-generated installer packages: https://derflounder.wordpress.com/2017/11/10/adding-installer-package-code-signing-to-autopkg-workflows/

This time though, I didn’t see a way to pass an AutoPkg recipe override’s variables to a postinstall script. I did have one idea though, which was using AutoPkg’s FileCreator processor to create a customized postinstall script. I had previously used the FileCreator processor in other AutoPkg recipes to create postinstall scripts, but those scripts were self-contained and didn’t use variables from the AutoPkg recipe.

That said, you never know what AutoPkg can do until you try it and sure enough the FileCreator processor was able to pass recipe variables as part of creating a file. For more details, please see below the jump.

I was able to leverage the ability to pass variables to create this script:

I then created a recipe override and added the following demo values from the Zscaler command line options page:

• cloudName: zscalertwo.net
• deviceToken: 123456789
• policyToken: 987654321
• userDomain: safemarch.com

The installer package postinstall script generated by this recipe override had the following contents:

In turn, this meant that only the Zscaler command-line options with actual values were run as part of the postinstall script:

Being able to pass variables this way means that the AutoPkg Zscaler .pkg recipe can be used by anyone. Whoever needs to plug in custom variables can do so as part of a recipe override, which allows them to keep their organization-specific information safe while still leveraging AutoPkg’s ability to automatically build installers for deployment.

This technique also has wider applications for anyone who needs to build custom postinstall scripts as part of an AutoPkg recipe because it means that customizable postinstall scripts can be generated on a per-override basis. For example, if you needed to support packaging for multiple organizations, it’s possible to have one core .pkg recipe along with a FileCreator-generated script which is flexible enough to accommodate whatever variables a particular override provides.

Going back to the example of Zscaler, if I needed to support three different organizations, all I would need is the one Zscaler .pkg recipe and three overrides. The overrides would have the different organization’s individual settings and running the overrides would result in three installers with organization-specific settings in the individual installer’s postinstall script.

For folks wanting to take a look at examples, I’ve posted .download, .pkg and .jss recipes for Zscaler to GitHub at the following locations:

https://github.com/autopkg/rtrouton-recipes/tree/master/Zscaler
https://github.com/autopkg/rtrouton-recipes/blob/master/JSS/Zscaler.jss.recipe

As part of working on an issue with Jamf Support, I needed to enable debug logging for the JAMFSoftwareServer.log log file on my Jamf Pro server. This is normally a pretty straightforward process:

1. Log into your Jamf Pro server.

2. Go to Management Settings: Jamf Pro Information: Jamf Pro Server Logs.

3. Click the Edit button.

4. Check the checkbox for Enable Debug Mode.

5. Click the Save button.

6. Verify that the log has changed into debug mode.

However, what do you do about Jamf Pro servers which are set to limited access? The admin console is disabled on limited access nodes, which means you can’t use the admin console’s functionality to enable debug logging. There is a way, but it means editing some Tomcat settings. For more details, please see below the jump.

To enable debug logging for limited access nodes, you need to edit the log4j.properties file, which manages logging for both the JAMFSoftwareServer.log and JAMFChangeManagement.log logfiles. The log4j.properties file is stored in the following location:

/path/to/tomcat_directory/webapps/ROOT/WEB-INF/classes/log4j.properties

To turn debug logging on:

1. Open the log4j.properties file.

2. Search for the following string:

log4j.rootLogger=INFO,JAMF

3. Change it to the following:

log4j.rootLogger=DEBUG,JAMF

4. Save changes to the log4j.properties file.

5. Once the change has been made, restart Tomcat.

To turn debug logging off:

1. Open the log4j.properties file.

2. Search for the following string:

log4j.rootLogger=DEBUG,JAMF

3. Change it to the following:

log4j.rootLogger=INFO,JAMF

4. Save changes to the log4j.properties file.

5. Once the change has been made, restart Tomcat.

The good folks at Penn State have posted the session videos from Penn State MacAdmins Conference 2019. The sessions slides are all accessible from the Penn State MacAdmins’ Resources page at the link below:

http://macadmins.psu.edu/conference/resources/

All session videos are available via the link below:

https://www.youtube.com/playlist?list=PLRUboZUQxbyUovbRrw99WWyli5PF9EtXk

I’ve linked my “Installer Package Scripting: Making your deployments easier, one !# at a time” session here:

The “macOS 10.15, the future of Mac administration and more, AMA” panel I co-hosted with Allen Golbig, Lisa Davies, Amanda Wuest, Jennifer Unger and Robert Hammen is linked here:

The “Empowering the Slack Powered Workplace” panel I participated in along with Tim Burke, Erin Merchant and Michael Norton is linked here:

Jamf Pro has the ability to push notifications to devices with Self Service installed. This function is enabled using a Jamf-specific service known as the Jamf Push Proxy.

To enable this service to work with your Jamf Pro server, you need to set up a push proxy server token using the process shown below:

1. Log into your Jamf Pro server as an administrator.
2. Go to Settings > Global Management > Push Certificates.

3. Click the New button.

4. Select the Get proxy server token from Jamf Authorization Server option and click the Next button.

5. Provide credentials for a Jamf Nation user account and click the Next button.

6. If successful, you should be notified that the proxy server token has been uploaded to your Jamf Pro server. Click the Done button.

7. The proxy server token should appear listed as Push Proxy Settings in the Push Certificates screen.

Once the Push Proxy service has been enabled for your Jamf Pro server, you can use the notifications options in your Self Service policies to provide notifications in Self Service and Notification Center when desired.

For more details, please see below the jump.

One thing to be aware of is that the push proxy server token has a very short life (one day) and needs to be renewed regularly. The credentials of the Jamf Nation account used to set up the push proxy server token are stored in the Jamf Pro database and used to renew the push proxy server token. This use of stored Jamf Nation credentials has two implications to be aware of:

1. If the password for that Jamf Nation account is changed or the account is closed, then the Jamf Pro server which is using those credentials will be unable to successfully renew the push proxy server token. This means that the renewal will fail and the certificate stops being renewed.
2. The Jamf Nation account’s credentials are stored in the database, which may be a security risk if those account credentials have access to other Jamf Nation resources.

To manage these risks, I would recommend setting up a separate Jamf Nation account and use it specifically for enrolling the Push Proxy service on your Jamf Pro server. One thing to be aware of is that the separate Jamf Nation account must have some assets associated with it, so I also recommend talking with Jamf Support as to the best way to manage this.

If you want to change the Jamf Nation account used with the Push Proxy service, you can fix this by deleting the current push proxy token and setting up a new one. You can do this using the process shown below:

1. Log into your Jamf Pro server as an administrator.
2. Go to Settings > Global Management > Push Certificates.

3. Click the Push Proxy Settings token.

4. Click the Delete button.

5. When asked to confirm, click the Delete button.

At this point, your existing push proxy token should be removed.

To set up a new one using the new Jamf Nation account, use the procedure described earlier to set up the new push proxy token.

A vital component of a Jamf Pro server setup is usually its LDAP connection to a directory service (usually an Active Directory server.) This connection allows the Jamf Pro server to not only leverage the directory service’s users and groups, but also automatically populate information about the owner of the device by doing a lookup in LDAP as part of a computer‘s or mobile device’s inventory update and assist with providing user-specific policies in Self Service.

As more folks move from using self-hosted Jamf Pro servers to now having Jamf host them in Jamf Cloud, this LDAP connection usually requires an LDAP proxy in order to securely connect a Jamf Cloud-hosted Jamf Pro instance to a company’s internally-hosted directory service. Jamf provides an LDAP proxy for this purpose in the form of the Jamf Infrastructure Manager (JIM). 

Because the LDAP connection is so vital, it’s just as vital that the JIM stay up and working all the time. To assist with this, I’ve written some scripts to assist with monitoring and reporting for a JIM running on Red Hat Enterprise Linux. For more details, please see below the jump.

I’ve written three scripts to assist with JIM monitoring:

• jim_check.sh – monitors the JIM and restarts it if needed.
• jim_report.sh – sends a report to a designated Slack channel
• install_jim_check_scripts_and_crontab.sh – installs the jim_check.sh and jim_report.sh scripts into /usr/local/bin and sets up a crontab entry to run the jim_check.sh script every ten minutes.

All three scripts are shown below and are also available on GitHub via the following link:

https://github.com/rtrouton/jamf_infrastructure_manager/tree/master/jim_monitoring

The jim_check.sh script checks the port that the JIM uses for incoming LDAP queries from its Jamf Pro server, to see if the LDAP proxy service is listening on that port. If nothing is listening on that port, the JIM process is automatically stopped and restarted. After the restart completes, the jim_report.sh script is triggered to provide information about the service stoppage.

The jim_report.sh script is designed to capture information from the /var/log/jamf-im.log and forward that information along with basic identifying information for the JIM to a Slack channel via a webhook.

The general idea is that the forwarded log entries should hopefully show whatever problem the JIM’s LDAP proxy service was having before it went offline and needed to be restarted.

The install_jim_check_scripts_and_crontab.sh script is designed to install both the jim_check.sh and jim_report.sh scripts into /usr/local/bin and also set up a cronjob for regular running on the jim_check.sh script.

Over the past year, I’ve been working with my colleague Charles Edge on a new book and I’m delighted to announce it’s now available for pre-ordering on Amazon:

Pre-order link: https://www.amazon.com/Apple-Device-Management-Managing-AppleTVs/dp/1484253876

This quality item is suitable for any gift-giving occasion, in addition to being the perfect something for your own use (perhaps as a doorstop.) Please order now.

In certain circumstances, like taking school tests or handling sensitive documents, it may be necessary to disable the ability to create screenshots or make screen recordings. For those who need to do this, it’s possible to set this with a profile.

PayloadType: com.apple.applicationaccess
Key: allowScreenShot
Type: boolean

Once a profile has been built and applied to a Mac running macOS Mojave, trying to create a screenshot or screen recording will result in the following message.

For more details, please see below the jump.

A sample profile is below and also available on GitHub via the following link:

https://github.com/rtrouton/profiles/tree/master/DisableScreenshotCreation

Recently, I was asked to create a configuration profile with an encrypted payload. This is a payload where the settings installed by the profile are not readable when you look at the .mobileconfig file. Instead, the payload with the settings is encrypted and are only readable once the payload contents are decrypted using the private key of a certificate which is also installed on the Mac in question.

In researching how to do this, I found that Apple’s documentation on encrypted payloads is very sparse and largely consists of the following (from https://developer.apple.com/documentation/devicemanagement/using_configuration_profiles):

Example commands for CMS encryption of the property list are not provided in Apple’s documentation, but it is possible to use /usr/libexec/mdmclient to encrypt profile payloads:

https://mosen.github.io/profiledocs/troubleshooting/mdmclient.html#encrypt

To see how this works, let’s go through the process of setting up a certificate which can be used for encrypting a profile followed by using that certificate to encrypt the profile. For more, please see below the jump.

Before we begin creating the certificate, I want to note that the certificate used in this example is going to be a self-signed root certificate. Using a self-signed root certificate is fine for prototyping and testing, but you should use a certificate issued by a trusted certificate authority if you’re using this method in production.

Creating the certificate

1. Run the following commands to generate a private key:

openssl genrsa -des3 -passout pass:x -out encryptprofiles.pass.key 2048

openssl rsa -passin pass:x -in encryptprofiles.pass.key -out encryptprofiles.key

Once the encryptprofiles.key file is generated, the encryptprofiles.pass.key file may be removed as it is no longer needed.

2. Run the following command to generate a certificate signing request (CSR):

openssl req -new -key encryptprofiles.key -out encryptprofiles.csr

You will be asked a number of questions. The one which ultimately matters in this case is the Common Name question, as that is the one which is the name assigned to the certificate. In this case, I am setting encryptprofiles.company.com as the Common Name for the certificate.

Note: The challenge password can be left blank.

3. Once the CSR has been generated, run the following command to create a public key using the private key and CSR:

openssl x509 -req -sha256 -days 365 -in encryptprofiles.csr -signkey encryptprofiles.key -out encryptprofiles.crt

4. Combine both the private key and public key into one text file named bothprivateandpublickeys.txt by running the following command:

cat encryptprofiles.key encryptprofiles.crt > bothprivateandpublickeys.txt

5. Run the following command to generate a .p12 file which uses the contents of the bothprivateandpublickeys.txt file to generate a .p12 archive file which contains both the private and public key:

openssl pkcs12 -export -in bothprivateandpublickeys.txt -out bothprivateandpublickeys.p12

You will be asked to set and verify an export password. You will need this password later, so make a note of it.

In this case, the following password is being used: password123

Creating a certificate profile

My next step was to create a configuration profile using ProfileCreator which included both the bothprivateandpublickeys.p12 file and the export password needed to unlock the .p12 file. This profile will import the .p12 file and use it to deploy the encryptprofiles.company.com certificate as a trusted root certificate.

Once built, the profile looks like this:

The final step is to install the profile, so that we can use it to encrypt another configuration profile’s payload. The profile installation can be performed via MDM, using the profiles command line tool or by double-clicking on the profile to install it.

In this case, I’m signing the certificate with my Developer ID Application signing certificate and then double-clicking to install it.

Encrypting a profile

Once the certificate profile is installed on a particular Mac, it should appear in the System keychain as a trusted root.

Once the certificate is showing up in Keychain Access as trusted, it can be used to encrypt profiles. To do this, run a command similar to the one shown below:

/usr/libexec/mdmclient encrypt "certificate_common_name_goes_here" /path/to/profile_to_encrypt_goes_here.mobileconfig

In my case, I’m running the following command to encrypt a configuration profile named Company WiFi.mobileconfig:

/usr/libexec/mdmclient encrypt "encryptprofiles.company.com" "/Users/username/Desktop/Company WiFi.mobileconfig"

A new profile should appear named Company WiFi.encrypted.mobileconfig.

The original Company WiFi.mobileconfig profile looks like this, with the profile’s settings listed under PayloadContent:

The new Company WiFi.encrypted.mobileconfig profile looks like this, with the profile’s settings encrypted and listed under EncryptedPayloadContent:

Installing an encrypted profile

Assuming the certificate profile is installed on a particular Mac, the encrypted profile can now be installed. The profile installation can be performed using the profiles command line tool or by double-clicking on the profile to install it.

If the certificate used to decrypt the profile is present and everything is working properly, the encrypted profile should install without a problem.

If there is a problem with decrypting the profile, the process will error because the Mac won’t be able to read the profile’s encrypted payload.

Notes on this process

• It is absolutely necessary for the certificate used to encrypt the profile to be deployed to the Mac receiving the encrypted profile and necessary for that certificate to include the private key.
• It is also necessary for the export password used to protect the .p12 file be provided, either in the profile itself or manually provided when the certificate profile is installed.
  • The reason is that the private key is used to decrypt the profile’s encrypted content and the export password is used to make that possible.
• The certificate must be deployed to the Mac receiving the encrypted profile before the encrypted profile is. If not, the encrypted profile won’t be readable by the Mac and the profile won’t install.

• You likely won’t be able to deploy the encrypted profile using an MDM server.
  • The reason is that when the profile was uploaded to the MDM server, the MDM server may try to read the profile and fail because it doesn’t have access the certificate used to decrypt the encrypted profile’s contents. This causes the upload process to halt and display an error. Instead, you will need to install the encrypted profile using the profiles command line tool.

As part of setting up Self Service policies in Jamf Pro, it’s nice to include a description for your customers of what they’re getting when they select a particular Self Service policy.

However, sometimes folks forget to add these descriptions and it can be hard to figure this out later which ones were missed without manually checking each policy.

To help with situations like this, I have a script which does the following:

1. Checks all policies on a Jamf Pro server.
2. Identifies which ones are Self Service policies which do not have descriptions
3. Displays a list of the relevant policies

For more details, please see below the jump.

The script is named Jamf_Pro_Detect_Self_Service_Policies_Without_Descriptions.sh. For authentication, the script can accept hard-coded values in the script, manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file.

The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

defaults write com.github.jamfpro-info jamfpro_url https://jamf.pro.server.goes.here:port_number_goes_here

To store the account username in the plist file:

defaults write com.github.jamfpro-info jamfpro_user account_username_goes_here

To store the account password in the plist file:

defaults write com.github.jamfpro-info jamfpro_password account_password_goes_here

When the script is run, you should see output similar to that shown below.

The script is available below, and at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/Jamf_Pro_Detect_Self_Service_Policies_Without_Descriptions

Jamf_Pro_Detect_Self_Service_Policies_Without_Descriptions.sh:

On the evening of Monday, September 23rd, a number of film and TV editors started reporting that their workstations were not rebooting successfully. The problem was initially blamed on the Media Composer software sold by Avid.

On September 24th, more instances were reported and it became clear that this was not an issue restricted to Macs with Media Composer installed. After extensive checking and testing, the folks in the MacAdmins Slack were able to narrow down the issue to an update to Google’s Keystone software, which Google uses to update Google Chrome and other Google products on macOS.

The now-pulled Keystone update attempts to remove the /var symlink, which is usually protected by Apple’s System Integrity Protection (SIP) security feature.

On Macs where SIP was disabled, this protection did not apply and the Keystone update was able to remove the /var symlink. This symlink is not a directory itself, but points to another directory (/private/var) which contains software necessary for the operating system to boot and function correctly, so removing the /var symlink rendered the affected Macs unbootable.

As mentioned previously, Google has pulled the problematic Keystone update and has published instructions on how to remediate affected Macs. For more details, please see below the jump.

Note: Remediation is only needed on Macs experiencing problems resulting from this Keystone update. If your Mac is able to boot, remediation is not needed.

To remediate on Macs running OS X 10.9.x – OS X 10.10.x, where SIP is not available:

1. Boot to Recovery
2. Identify the Mac’s boot drive using the following steps:

A. Go to the Apple menu.
B. Select Startup Disk…

C. Look for the highlighted drive. This is the startup disk.

D. Note the name of the startup disk.

Note: By default, Apple sets the name of the boot drive to Macintosh HD.

3. Quit the Startup Disk application.

4. Go to the Utilities menu
5. Select Terminal.

6. Enter the following commands:

Note: If the name of your boot drive is different from Macintosh HD, the first command should be the following:

chroot "/Volumes/Different Name Goes Here"

Use the actual name of the boot drive in the command where I have Different Name Goes Here.

7. Reboot your Mac and see if it now boots successfully.

To remediate on Macs running OS X 10.11.x – macOS 10.14.x, where SIP is available:

1. Boot to Recovery
2. Identify the Mac’s boot drive using the following steps:

A. Go to the Apple menu
B. Select Startup Disk…

C. Look for the highlighted drive. This is the startup disk.

D. Note the name of the startup disk.

Note: By default, Apple sets the name of the boot drive to Macintosh HD.

3. Quit the Startup Disk application.

4. Go to the Utilities menu
5. Select Terminal.

6. Enter the following commands:

Note: If the name of your boot drive is different from Macintosh HD, the first command should be the following:

chroot "/Volumes/Different Name Goes Here"

Use the actual name of the boot drive in the command where I have Different Name Goes Here.

7. Reboot your Mac and see if it now boots successfully.

One of the changes Apple is introducing in macOS Catalina is the notarization requirement for code in the following categories:

•  All apps signed after June 1st, 2019
•  Signed executable code which are undergoing first run checks (this check would be triggered by the executable having a com.apple.quarantine extended attribute.)

Note: Signed executable code can take many forms, including command-line binaries or other tools which don’t fit into the usual macOS app category. In this post, I’m going to be using “executable” or “executable code” in this post as shorthand for “It’s not an app, but you can sign, notarize and run it.”

Notarization is commonly thought of as Apple doing a malware scan on the app / executable in question, but it’s also more than that. Notarization also includes a code hardening process for the app or executable, which sets up the app or executable code to run in a protected environment. What protections are provided? According to Apple:

•  App / executable can’t create executable memory without the app / executable being associated with a code signature.
•  When the OS is reading code or data from drive storage, all the data being read in to the running app or executable must match the app /executable’s code signature.
•  Code which is modified in memory and which no longer match the app / executable’s code signature can’t be executed.
•  Protection provided against code injection and/or dylib hijacking.

While there are entitlements provided by Apple to allow apps / executables to bypass these protections, they’re embedded as part of the notarization process and can’t be changed later without breaking the code signature. Meanwhile, notarization is for the life of that particular app / executable code. It’s not just checked once, like has been the case with Gatekeeper’s code signature check for apps / executables on previous versions of macOS.

How does this relate to IT auditing and making it less painful? Well, imagine you had an auditor come to you and say “I need you to check and verify that all third-party apps used in your environment have been scanned for malware.”

Holy cow. That’s a huge requirement.

Or it was. Notarization provides exactly that capability and it can be verified on-demand using the stapler tool. Even better, since the OS is what’s requiring notarization for apps, it’s automatically handling compliance for you. Meanwhile, notarization’s protected environment limits considerably the ability of malware to hijack notarized apps. That likely would check a few more malware-related compliance boxes on the auditor’s checklist.

For an example of this, let’s take a look at the Australian Cyber Security Centre’s guidance for application whitelisting. For enforcement mechanisms, two of them are provided by macOS Catalina’s handling of notarized apps:

• Cryptographic hash rules
• Publisher certificate rules

The US’s National Institute of Standards and Technology provides similar guidance (please see Section 2.2.1 File and Folder Attributes of NIST SP 800-167):

This is not to say that you can hold up a “Notarized!” sign to the auditor, watch the auditor leave after just tossing the checklist aside and commence the post-audit party. But for those folks who have to undergo regular compliance auditing, I would recommend you examine your auditing requirements carefully to see which IT audit controls on your list now get handled automatically on macOS Catalina with its notarization requirements.

Now that macOS Catalina has been released, it’s become more difficult to access the macOS Mojave installer for those who still need it. Fortunately, Mojave has not been removed from the MAS and it is still available for download. Apple has a KBase article that shows how to access the macOS Mojave page in the Mac App Store, available via the link below:

https://support.apple.com/HT210190

To access the macOS Mojave page directly, please click on the link below:

https://itunes.apple.com/us/app/macos-mojave/id1398502828?ls=1&mt=12

That link should open the MAS and take you to the macOS Mojave download page.

The Mojave installer itself will download via the Software Update pane in System Preferences.

In the event that you’re blocked from downloading macOS Mojave, you should be able to download it in a virtual machine. I have a post on how to do this, available via the link below:

https://derflounder.wordpress.com/2017/02/21/downloading-older-os-installers-on-incompatible-hardware-using-vms/