Forcing Jamf Pro 10.17.1 to Not Use TLSv1.3 – Known Issue

Update: This issue is documented in Jamf’s Known Issues page identified as PI-007522

After upgrading our Jamf Pro server to 10.17.1, I was going through and updating a number of our PreStage Enrollments and noted that the sync was failing to complete. Normally when I’ve had issues with Jamf Pro communicating to DEP (now Automated Device Enrollment) all that’s been needed is to download a new MDM server token from Apple School Manager (or Business Manager) and upload it into our MDM. However, this time it did not resolve our communication issues.

A short call with Jamf Support later and the culprit was how the new version of Jamf Pro was attempting to communicate with DEP: via TLSv1.3. As it turns out, Apple hasn’t yet implemented 1.3, so the fix was to force Tomcat to use 1.1 or 1.2.

To do this, we completed the following in CentOS:

# 1) Remotely connect and navigate to Jamf Pro Server's Tomcat ../bin directory

cd /usr/local/jss/tomcat/bin

# 2) Make a copy of the 'setenv.sh' file

cp setenv.sh /desired/backup/location/setenv.sh.backup

# 3) Edit the original setenv.sh file in your editor of choice, adding the
# following line ABOVE the existing 'export CATALINA_OPTS=...' line

export JAVA_OPTS="$JAVA_OPTS -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2"

# 4) Save the file and restart your Jamf Pro service

jamf-pro server restart

Note: Initially, after adding this new line to the file the Jamf Pro service failed to start. This was due to the fact that when the command was shared with me it contained a smart quote rather than regular quotes ".

Suppressing the macOS Software Update Alert Icon via Configuration Profile in Jamf Pro

This builds on a previous post about suppressing the alert icon that appears on the System Preferences app when macOS sees available software updates.

If you are using Jamf Pro as your MDM, you are not likely to see the addition of the necessary preference to suppress this alert, as it’s not documented by Apple. However, because the preference lives within com.apple.systempreferences.plist, which is an Apple-supported payload for restricting access to preference panes in System Preferences, in order to manage this preference natively you have to make the profile read-only by code-signing it outside of Jamf.

If you happen to have a locally mirrored Apple Software Update Server like we do, you can still benefit from managing this preference via profile. Even though you control what updates are available and when, per this post if your Macs do not automatically check for updates then they are not getting security updates, like XProtect. As such, you’ve needed to remove the config-data type attribute in order for these to appear as regular updates and be installed.

At JNUC 2019, there was a good presentation on how to update and sign profiles outside of Jamf Pro. While you can certainly use a self-signed certificate as demonstrated in the video, you might consider creating an Apple Developer account instead so you can get a fully trusted certificate chain. If you’re an EDU institution like we are, you can actually get this for free after jumping through a few hoops. After paying an upfront $100 for the account, you can request to get reimbursed as an education institution and once approved, you will be refunded and all subsequent annual renewal costs will be waived. Once you have a Developer account, you can create and download your cert and install it in your Mac keychain.

With the certificate in your keychain, you can most efficiently create the necessary profile with ProfileCreator, as the preference key necessary to suppress this alert is readily available. With the app downloaded, click in the search field at the bottom left and search for ‘System’. From the list on the left, select the payload titled ‘System Preferences’.

In the main window, click the ‘Add’ button at the top right to add the payload to the profile. Next, select the ‘Other’ menu option to reveal the preference key we need. Click the plus button to the left of the preference to add it to the payload. Once added, it will look like the image below. If you have any difficulty with these steps, consult the ProfileCreator wiki.

While you can click the plus button to explicitly define a value of 0 for the com.apple.preferences.softwareupdate preference pane bundle ID (this will be supplied automatically if added), leaving the preference blank is enough.

Click the XML button at the top right to verify that the AttentionPrefBundleIDs dictionary key is both present and empty.

Lastly, click the ‘General’ payload from the top left to give your profile a title, description, and importantly to set the scope of the profile to System. While the AttentionPrefBundleIDs key is handled at the user-level com.apple.systempreferences.plist file, setting the profile to system will work and ensure any user on the Mac does not see this alert icon.

With all this done, you can export your profile. If this is your first time using ProfileCreator, you will also need to enable some settings to allow it to access and use your certificate to sign the profile. More information can be found here from the wiki.

After entering admin credentials to sign the profile, you should have a signed configuration profile which Jamf cannot alter.

Thankfully, the com.apple.systempreferences payload allows multiple profiles and/or payloads to manage preferences without creating a conflict, so any existing Restrictions payloads in profiles you’ve already created in Jamf won’t be affected. All that’s left is to upload your signed profile.

Once uploaded into Jamf Pro, you will notice that there are no payloads listed along the left side as you normally would see. This is normal. Add a computer scope for your profile, save it, and watch that pesky red alert icon disappear!

Note: In my experience, you either need to reboot the machine after the profile is installed or run a killall cfprefsd && killall Dock to no longer see the alert icon.

PPPC & TeamViewer 15 Changes for Mac

TL;DR

The TeamViewer_Desktop code signature has changed as of version 15.0.8397 in both TeamViewer and TeamViewer Host. As of version 15.1.3937, the path to this binary has also changed. If you use MDM to manage PPPC allowances, this will need to be updated for both apps. These differences are bolded below:

  • Old Path: /Applications/TeamViewer.app/Contents/Helpers/TeamViewer_Desktop
  • New Path: /Applications/TeamViewer.app/Contents/MacOS/TeamViewer_Desktop
  • Old Signature: anchor apple generic and identifier "$(PRODUCT_BUNDLE_IDENTIFIER)" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = H7UGFBUGV6)
  • New Signature: anchor apple generic and identifier "com.teamviewer.Desktop" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = H7UGFBUGV6)

More Info:

Back in October, I observed something strange with TeamViewer 14 (and TeamViewer Host). As a result of macOS security changes with Privacy Preferences Policy Control (PPPC), TeamViewer had added a new binary – TeamViewer_Desktop – in order to allow remote control. This binary lived in the app, and per TeamViewer’s documentation indicates it cannot be added manually. To allow this access across our fleet, we had to add the path of this binary as well as its code signature to our MDM. However, running codesign -dr- on the binary revealed the following signature:

anchor apple generic and identifier "$(PRODUCT_BUNDLE_IDENTIFIER)" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = H7UGFBUGV6)

Normally, code signatures include a unique bundle identifier for the app / binary with the signature. For example, the TeamViewer app code signature starts with anchor apple generic and identifier "com.teamviewer.TeamViewer" where com.teamviewer.TeamViewer is the bundle id.

For the TeamViewer_Desktop binary, the identifier is "$(PRODUCT_BUNDLE_IDENTIFIER) … which looks a lot like a script variable. After speaking with TeamViewer support, we were able to confirm that this was an error with their build process where the actual bundle identifier should have been entered. This error exists in all 14.X versions of TeamViewer and TeamViewer Host.

As of the TeamViewer 15.0.8939 release, this error has been finally been addressed:

anchor apple generic and identifier "com.teamviewer.Desktop" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = H7UGFBUGV6

And as of the version15.1.3937, location of the binary has changed as well. As a result, if you are defining the binary path in your MDM both the code signature and path must be updated. In case you missed it in the TL;DR section:

  • Old Path: /Applications/TeamViewer.app/Contents/Helpers/TeamViewer_Desktop
  • New Path: /Applications/TeamViewer.app/Contents/MacOS/TeamViewer_Desktop