The Jamf Pro Push Proxy service, service token renewal and Jamf Nation credentials

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.

Session videos now available from Penn State MacAdmins Conference 2019

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:

Enabling debug logging for the JAMFSoftwareServer log on Jamf Pro limited access nodes

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.

Building customized postinstall scripts for AutoPkg recipes

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.

Suppressing Microsoft AutoUpdate’s Required Data Notice screen

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.

Additional Zoom remediation from Apple via MRT

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.

Zhumu vulnerability and remediation

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.

Note that Zhumu, the Chinese version of Zoom (same app, just runs from China servers) is equally vulnerable. Process is ZhumuOpen, port is 19433 – Hope someone pushes them to fix that, too.

— Steve Mushero (@stevemushero) July 9, 2019

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.