babgond

As part of testing macOS Big Sur 11.0.0, I’ve updated my create_macos_vm_install_dmg script. For more details, please see below the jump.

Downloading the script:

The create_macos_vm_install_dmg script is available from the following location:

https://github.com/rtrouton/create_macos_vm_install_dmg

Using the script:

Once you have the script downloaded, run the create_macos_vm_install_dmg script with two arguments:

1. The path to an Install macOS.app.
2. An directory to store the completed disk image in.

Example usage:

If you have a macOS Big Sur Beta installer available, run this command:

/path/to/create_macos_vm_install_dmg.sh "/Applications/Install macOS Beta.app" /path/to/output_directory

If you had chosen to not create the .iso file, this should produce a .dmg file inside output_directory that’s named something similar to macOS_1100_installer.dmg.

(Note: the WWDC beta identifies itself as 10.16, so a disk image of Big Sur’s WWDC beta will be named macOS_1016_installer.dmg.)

If you chose to create the .iso disk image, you should have two files inside the chosen directory: macOS_1100_installer.dmg and macOS_1100_installer.iso

Creating a VM with the OS installer disk image using VMware Fusion 11.x

1. Launch VMWare Fusion 11.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on Use another disc or disc image…

5. Select your macOS installer disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

6. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

• Operating System: Apple OS X
• Version: macOS 10.15

7. In the Finish window, select Customize Settings if desired. Otherwise, click Finish.

8. Save the VM file in a convenient location.

The VM is now configured and set to use the macOS installer disk image. To install macOS, start the VM and then run through the normal installation process when prompted.

This week, I’m attending Apple’s WWDC 2020 conference from the comforts of home. As part of this, I’m taking notes during the labs and session videos. Due to wanting to stay on the right side of Apple’s NDA, I’ve been posting my notes to Apple’s developer forums rather than to here.

To make it easier for Mac admins to access them, I’ve set up a post in the forums where I’ve linking the various forum posts with my notes. It’s available via the link below:

https://developer.apple.com/forums/thread/650135

As part of macOS Catalina, Apple introduced Activation Lock for Macs. As on iOS, Activation Lock is an anti-theft feature designed to prevent activation of a Mac if it’s lost or stolen.

Activation Lock on Macs does have some requirements in order for it to work. The Mac must:

• Run macOS Catalina or later
• Use the Apple T2 Security chip
• Two-factor authentication must be enabled on the Apple ID used for enable Activation Lock.
• Secure Boot must be enabled with Full Security settings and Disallow booting from external media selected.

Once these requirements are satisfied, Activation Lock is automatically enabled when Apple’s Find My service is enabled.

However, having Activation Lock turn on when Find My is enabled can lead to situations where it’s enabled by an employee on company-owned equipment. When this happens, companies, schools or institutions need a way to bypass Activation Lock without needing to know anything about the Apple ID used by the employee.

To provide this bypass, Apple has made it possible for companies, schools and institutions to use their MDM solution to clear Activation Lock. For more details, please see below the jump:

In order to clear Activation Lock using a MDM, the Mac in question needs to be supervised, which has the following requirements. The Mac must:

• Use macOS Catalina or later
• Be enrolled with an MDM
• MDM must be using Apple’s Automated Device Enrollment service via Apple Business Manager or Apple School Manager.

If a Mac is supervised and managed via Jamf Pro 10.20.0 or later, an Activation Lock bypass code is automatically generated and stored as part of the computer’s inventory. It’s available in the computer’s inventory listing, under the Management section.

Note: This Activation Lock bypass code capability is not exclusive to Jamf Pro; it’s available to all MDM solutions. If your MDM solution does not yet support it, ask your vendor to add this support.

To use the Activation Lock bypass code, please use the following procedure:

1. Get the bypass code from Jamf Pro.

2. Boot to macOS Recovery or Internet Recovery .
3. Make sure your Mac is able to communicate with the Internet and the required Apple services.
3. At the Activation Lock screen, go to the Recovery Assistant menu and select Activate with MDM key…

4. Enter the bypass code and click the Next button.

Once the bypass code has been accepted, the Mac should clear the activation lock and activate.

To illustrate, I’ve made a video showing the described process.

With WWDC 2020 only a couple of weeks away, a number of folks are preparing to run the new beta version of macOS. While some will choose to go all-in and run the new OS on their main boot drive, others will prefer to install the new OS onto an external drive. However, for Macs equipped with T2 chips, there’s an extra step involved with allowing your Mac to boot from an external drive. For more details, please see below the jump.

Apple has a KBase article describing how to use the Startup Security Utility in macOS Recovery [] to allow booting from external media (AKA an external drive.) This KBase article is available via the link below:

About Startup Security Utility: https://support.apple.com/HT208198

To open Startup Security Utility:

1. Boot to macOS Recovery
2. Authenticate if requested.

3. Under the Utilities menu, select Startup Security Utility.

4. If requested to authenticate, click the Enter macOS Password button.

5. Choose an administrator account and provide the account’s password.

Once authenticated, select the Allow booting from external or removable media option.

To illustrate, I’ve made a video showing the described process.

The good folks at Penn State have begun posting session videos from the Penn State MacAdmins Campfire Sessions to YouTube. As they become available, you should be able to access them via the link below:

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

I’ve linked my “Introduction to MDM and Configuration Profiles” session here:

My colleague Anthony Reimer’s “Things I Learned from the Autopkg Maintainers” session is likewise available here:

Every so often, I need to delete a bunch of Jamf Pro policies at once. One convenient way I’ve found to do this is to assign all the policies I want to delete to one category which doesn’t have any other policies assigned to it. Once assigned, I can then use the API to delete them all at once.

To assist with this task, I’ve been using a script written by Jeffrey Compton but over time I found that I wanted more functionality. To meet my own needs, I took Jeffery’s original idea and written my own script to target the policies in a particular Jamf Pro category. For more details, please see below the jump.

This script is designed to do the following:

1. List all categories on a Jamf Pro server.
2. Allow a category to be specified.
3. List all policies (if any) associated with that category.
4. Confirm that all policies in that category should be deleted.
5. Delete all policies in that category.

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.

You’ll be requested to enter the name of a category.

You’ll be asked to confirm that you want to delete the relevant policies.

Once confirmed, the policies will be deleted.

The script is available from following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/Jamf-Pro-Delete-All-Policies-In-Specified-Category

In my career, I’ve run across a lot of terrible installers in a variety of forms. The one I ran across today though is noteworthy enough that I want to point it out because of the following reasons:

1. It’s an installer application. I have opinions on those.
2. It’s for a security product where, as part of the installation, you need to provide the username and password for an account on the Mac which has:

• Administrator privileges
• Secure Token

Note: I have no interest in talking to the vendor’s legal department, so I will not be identifying the vendor or product by name in this post. Instead, I will refer to the product and vendor in this post as “ComputerBoat” and leave discovery of the company’s identity to interested researchers.

For more details, please see below the jump.

To install ComputerBoat, you will need the following:

1. The ComputerBoat installer application.
2. A configuration file for the ComputerBoat software.
3. The username and password of an account with the following characteristics:

• Administrator privileges
• Secure Token

Once you have those, you can run the following command to install ComputerBoat:

Why it necessary to provide the username and password of an account with admin and secure token? So this product can set up its own account with admin privileges and a Secure Token!

Why is it necessary for this product to set up its own account with admin privileges and a Secure Token? I have no idea. Even if it is absolutely necessary for that service account to exist, there is no sane reason why an application’s service account needs a Secure Token. In my opinion, there are only three reasons why a service account may need to have Secure Token.

1. To add the service account to the list of FileVault-enabled users.
2. To enable the service account to create other accounts which have Secure Tokens themselves.
3. To enable the service account to rotate FileVault recovery keys.

All of those reasons have serious security implications. Even more serious security implications are brought up by the fact that this vendor thought requesting the username and password of an account with admin and secure token was an acceptable part of an installation workflow. To further illustrate this, here’s a sample script which the vendor provided for installation using Jamf Pro:

Here, the installation workflow is as follows:

1. Use curl to download a compressed copy of the ComputerBoat installer’s configuration file in .zip format.
2. Use ditto to unzip the dowloaded configuration file into a defined location on your Mac.
3. Use ditto to unzip the downloaded installer into the same defined location on this Mac.
4. Run a directory listing of the defined location.
5. Remove extended attributes from the uncompressed ComputerBoat installer application.
6. Using credentials for an admin account with Secure Token, install the ComputerBoat software and set up a new account with a Secure Token to act as the application’s service account.
7. Checks to see if it can run a command to get the newly-installed application’s version number.

• A. If the version number comes back, the install succeeded. 
• B. If nothing comes back, the installation is reported as having failed.

The only defense I can think of for the vendor is that it says “Sample” in the description. That may imply that the vendor built this as a proof of concept and may be trying to subtly encourage their customer base to develop better solutions for deploying the ComputerBoat software on Macs. On the other hand, I received this script on the customer end of the transaction. That meant that someone at the vendor thought this was good enough to give to a customer. Either way, it’s not a good look.

Why is this script problematic?

Security problems

1. You need to supply the username and password on an account on the Mac with admin privileges and Secure Token using a method that other processes on the computer can read. This leaves open the possibility that a malicious process will see and steal that username and password for its own ends.
2. The script is set to run in debug mode, thanks to the set -x setting near the top of the script. While this may be helpful in figuring out why the installation process isn’t working, the verbose output provided by debug mode will include the username and password of the account on the Mac with admin privileges and Secure Token.

Installation problems

1. Without supplying the username and password on an account on the Mac with admin privileges and Secure Token, the installation process does not work.

If you’re deploying this security application to your fleet of Macs, that means that the vendor has made the following assumptions:

• You have an account with admin privileges and Secure Token on all of your Macs which share the same username and password.
• You’re OK with providing these credentials in plaintext, either embedded in the script or provided by a Jamf Pro script parameter in a policy.

2. Without providing a separate server to host the ComputerBoat installer’s configuration file, the installation process does not work.

• If you’re deploying this software, the vendor apparently did not think of using Jamf Pro itself as the delivery mechanism for this configuration file. Hopefully you’ve got a separate web server or online file service which allows for anonymous downloading of a file via curl.

3. Without figuring out a way to get the installer into the same location as the downloaded configuration file, the installation process does not work.

• Overlooked by the installation script is this question: How does the installer get to the location defined in the script as $COMPUTERBOATEPM_INSTALL_TMP ? The script assumes it’ll be there without including any actions to get it there or checking that it is there.

There are further issues with this script, but they fall into the category of quirks rather than actual problems. For example, I can’t figure out the purpose of the following lines:

ls -al $COMPUTERBOATEPM_INSTALL_TMP
xattr -d $COMPUTERBOATEPM_INSTALL_TMP/Install\ ComputerBoat\ EPM.app

Neither command seems to do something useful. The first one will list the contents of the directory with the configuration file and the installer application, but then that information isn’t captured or used anywhere. The second removes extended attributes from the ComputerBoat installer application, but the reason for this removal isn’t explained in any way.

You can draw conclusions about a vendor and their product quality by looking at how that vendor makes it possible to install their product. In examining this installation process, especially considering this is for a product intended to improve security in some way, I have drawn the following conclusions:

1. The vendor has not invested resources in building macOS development or deployment expertise.
2. The vendor is unwilling or unable to avoid compromising your security with their product’s installation process.
3. The vendor is not serious about developing or maintaining a quality product for macOS.

When you see installation practices like this, I recommend that you draw your own conclusions on whether this is a vendor or a product you should be using.

For those who wanted a copy of my MDM and profiles talk from Penn State MacAdmins 2020, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/PSUMac2020PDF
• Keynote: https://tinyurl.com/PSUMac2020Keynote

With COVID-19’s disruption of travel and public gatherings, a number of Mac admin conferences have made the choice to move to an online format. This change has meant that a number of conferences which previously required paying for tickets and travel costs have now become either much cheaper or free.

For those interested, here is the current list of conferences being held online between June and October 2020:

Penn State MacAdmins
Link: https://macadmins.psu.edu/campfire-sessions-2020/
Dates: June 4, 11, 18, 30 and July 9, 16, 23, 30
Cost: Free

MacDevOps YVR
Link: https://mdoyvr.com
Dates: June 10 – 12
Cost: CAD $135 (USD $97.74 as of May 29, 2020)

Apple WWDC
Link: https://developer.apple.com/wwdc20/
Dates: June 22 – 26
Cost: Free

Jamf Nation User Conference
Link: https://www.jamf.com/events/jamf-nation-user-conference/2020/
Dates: September 29 – October 1
Cost: Free

MacSysAdmin
Link: https://www.macsysadmin.se
Dates: October 2020 (exact dates not yet posted.)
Cost: Not yet announced

I recently saw an issue where several computers in Jamf Pro were showing up with the same serial number listed in their inventory records. This made it difficult to work with this serial number using the API because Jamf Pro Classic API calls may fail if we’re referencing the serial number in the API call and more than one inventory record exists with that serial number.

First off, how can this happen? Aren’t serial numbers supposed to be unique? They are, but there’s two instances where serial numbers may unfortunately be associated with more than one Mac.

Hardware repair:

When you send a Mac out for repair and the logic board is replaced as part of the repair, the Mac’s existing serial number is flashed onto the replacement logic board.

However, both the old and new logic boards have separate Unique Device Identifiers (UDID) associated with them. When enrolling a device into Jamf Pro, it is possible for a new inventory record to be set up if a device has:

• The same serial number listed in as an existing inventory record
• A UDID not found in other inventory records

Parallels macOS virtual machine:

macOS virtual machines set up by Parallels Desktop and other Parallels hypervisor products use the same serial number as the Mac which is running the Parallels hypervisor software. These VMs will likewise have separate Hardware UDIDs associated with them.

So what to do with these duplicate records? My recommendation is to delete them from your Jamf Pro server when you find them, especially if you do a lot of work using the API. To help with this task, a script has been developed to identify and delete unwanted duplicates. For more details, please see below the jump.

This script downloads all computer inventory records from a Jamf Pro server. The list of records is then parsed for inventory records with the same Apple serial number as at least one other record.

Once the duplicate serial numbers are identified, the script takes the following actions:

1. Loop through the duplicate serial number list and get all of the associated Jamf Pro computer IDs
2. Loop through the Jamf Pro IDs and identify the IDs with the most recent enrollment dates.
3. Verify that the individual Jamf Pro IDs are associated with Macs, as opposed to virtual machines running macOS.
4. Loop through the list of identified Macs with Jamf Pro IDs and delete all Macs except for the one with the most recent enrollment date.
5. Create a report in tab-separated value (.tsv) format which contains the following information about the deleted Macs.

• Jamf Pro ID
• Manufacturer
• Model
• Serial Number
• Hardware UDID

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 which looks similar to this.

The report generated in tab-separated value (.tsv) format should be openable natively by both Microsoft Excel and Apple Numbers.

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

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