The good folks at Penn State have begun posting the session videos from the Penn State MacAdmins Conference 2018. The sessions slides and currently-available videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:

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

As all the session videos have been posted to YouTube [https://www.youtube.com/user/psumacconf], I’ve linked my Providing the best Mac experience possible from the Mac CoE team with session here:

The Escaping the Tech Whisperer Trap session I co-hosted with Nikki Lewandowski is linked here:

Keeping up on Apple developer betas and other developer software releases is a necessary part of many Mac admins’ regular routine. It’s especially important during the period between WWDC in June and the annual OS release in the fall. Fortunately, Apple provides a way to help tracking developer releases easier by publishing a notification to the following address:

https://developer.apple.com/news/releases/

This publicly-accessible notification doesn’t discuss what’s included in the newly-released software and you will still need an Apple Developer Connection account in order to get the details. For many Mac admins though, having an easy and quick way to track if the latest developer beta has been released is valuable information in itself.

To make it even more convenient, Apple also offers a RSS feed for the Developer Releases page:

https://developer.apple.com/news/releases/rss/releases.rss

You can add this feed into your RSS reader and it’ll keep you up to date. If you use Slack, another approach is to use Slack’s ability to post content from an RSS feed to a Slack channel. For more details, please see below the jump:

To enable Slack to post from the Developer Releases RSS feed to a Slack channel, you’ll need to enable the RSS application on your Slack.

The procedure on how to do this is linked below:

https://get.slack.help/hc/articles/218688467-Add-RSS-feeds-to-Slack

Once you have the RSS application installed for your Slack instance, follow the procedure below:

1. Set up a channel in Slack to receive the content from the RSS feed.

For this example, I’ve set up a channel named #apple-developer-feed.

2. In the RSS application, click the Add RSS integration button.

3. In the Feed URL blank, enter the following URL:

https://developer.apple.com/news/releases/rss/releases.rss

4. Select the channel you want the RSS feed’s content to post to from the Post to Channel drop-down menu.

In this case, it’ll be posted to the #apple-developer-feed channel.

5. Once the RSS feed and channel have been properly set up, click the Subscribe to this feed button.

The RSS feed will now show as being posted to the selected channel.

Once this is configured, Slack will now post any new content from the RSS feed to the specified Slack channel.

In late 2017, Apple released the iMac Pro. Along with the new Secure Enclave protection provided by Apple’s T2 chip, the iMac Pro brought another notable development: It did not support booting from a network volume, otherwise known as NetBoot.

The one exception was Apple’s Internet Recovery, where Apple is providing a NetBoot-like service to provide access to macOS Recovery. The iMac Pro is still able to boot to Internet Recovery, which provides a way to repair the Mac or reinstall the operating system in situations where the Mac’s own Recovery volume is missing or not working properly.

With NetBoot not being available for the iMac Pro but still available for other models, it wasn’t yet clear if NetBoot-based workflows for setting up new Macs or rebuilding existing ones were on the way out. However, Apple’s release of of T2-equipped MacBook Pros in July 2018 which also could not use NetBoot has made Apple’s direction clear. As Apple releases new Mac models equipped with T2 chips and Secure Enclave, it is unlikely that these future Mac releases will be supporting NetBoot.

For Mac admins using NetBoot-based workflows to set up their Macs, what are the alternatives? Apple has been encouraging the use of Apple’s Device Enrollment Program, which leverages a company, school or institutions’ mobile device management (MDM) service. In this case, you would need to arrange with Apple or an Apple reseller to purchase Macs that are enrolled in your organization’s DEP.

When a DEP-enrolled Mac is started for the first time (or started after an OS reinstall), it is automatically configured to use your organizations’ MDM service and the device checks in with the MDM service. The MDM service then configures the Mac as desired with your organization’s software and configuration settings. A good example of what this process may look like can be seen here.

What if you don’t have DEP, or you don’t have MDM? In that case, you may still be able to leverage Recovery-based deployment methods, which would allow you install the desired software and configuration settings onto the Mac’s existing OS, or install a new OS along with software and configuration settings. For more details on these methods, please see below the jump.

To help facilitate deploying software and settings from the Recovery environment, Greg Neagle has released a couple of tools:

bootstrappr: https://github.com/munki/bootstrappr
installr: https://github.com/munki/installr

Both bootstrappr and installr can run in the macOS Recovery environment and work in similar ways. The main difference between the two is the following:

• bootstrappr: Installs one or more packages onto a target volume
• installr: Installs macOS and one or more additional packages onto a target volume

As an example of how bootstrappr works, please see below. In this case, I’ve set up a disk image using the instructions provided at the bootstrappr GitHub repo and copied it to an external drive named Provisioning.

On the disk image, I’ve included one installer package named First Boot Package Install, which was generated by my First Boot Package Install Generator tool.

1. Boot to macOS Recovery

2. Launch Terminal

3. Run the following command:

hdiutil mount /Volumes/Provisioning/bootstrap.dmg

The bootstrap disk image mounts as a new volume named bootstrap.

4. Run the following command:

/Volumes/bootstrap/run

5. Select the volume to install on (in this example, the volume is named Macintosh HD.)

The First Boot Package Install package included in the disk image is installed.

6. Once installation is completed, select the option to restart.

On restart, the First Boot Package Install package is able to run its own workflow, which is able to suppress the Apple Setup Assistant and run its assigned installation task. In this case, I’m only having it check for and install all available Apple software updates but it could be installing any desired package. This could include all software needed to set up a particular Mac, or installing a management agent to handle software installation and configuration.

Apple Remote Desktop (ARD) is a screen sharing and remote administration tool that just about every Mac admin uses at some point. Configuring access permissions for it can be done in several ways:

1. Using System Preferences’ Sharing preference pane to configure the Remote Management settings.
2. Using the kickstart command line utility to grant permissions to all or specified users
3. Using the kickstart command line utility to grant permissions to members of specified directories.

The last item may be the least-known method of assigning permissions, but it can be the most powerful because it allows ARD’s management agent to be configured once then use group membership to assign ARD permissions. For more details, please see below the jump.

As documented in the Apple Remote Desktop administrator guide, Apple’s directory-based permissions model looks like this:

In the past, these rights could be assigned via Apple’s Workgroup Manager using MCX, using a configuration like the one shown below:

However, this MCX-based method does not seem to work on macOS High Sierra. I have not yet been successful when assigning them using a management profile.

A secondary method using local groups on the Mac still works as of macOS High Sierra.

To configure ARD permission management via assignment to a local group, the following procedure should be used:

1. Create the following groups on your Mac:

com.apple.local.ard_admin
com.apple.local.ard_interact
com.apple.local.ard_manage
com.apple.local.ard_reports

2. Add the desired user(s) or groups to the relevant com.apple.local.ard_ group.

3. Configure ARD using the kickstart utility to recognize and use directory-based logins.

For example, the command shown below will enable the ARD management agent and configure it to use directory-based logins:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -clientopts -setdirlogins -dirlogins yes

Once configured, ARD permissions can be assigned by adding and removing from the relevant com.apple.local.ard_ groups. For example, adding a local user account named Administrator to the local com.apple.local.ard_admin group produces the following results.

Without any other configuration, the Administrator account now appears listed in the Remote Management settings.

The account also has the following ARD permissions assigned, with the permissions grayed out so that they can’t be changed:

• Generate reports
• Open and quit applications
• Change settings
• Copy Items
• Delete and replace items
• Send messages
• Restart and Shut down
• Control
• Observe
• Show being observed

Adding a local user account named User Name to the com.apple.local.ard_interact group produces the following results.

Without any other configuration, the User Name account now appears listed in the Remote Management settings.

The account also has the following ARD permissions assigned, with the permissions grayed out so that they can’t be changed:

• Control
• Observe
• Show being observed

To assist with creating these groups and assigning user accounts to them, I’ve written the following script. It does the following:

1. Allows a username and group to be specified for ARD permissions
2. Verifies that the username exists on the Mac
3. Creates all four ARD permissions management groups
4. Adds the specified user account to the specified management group
5. Turns on ARD’s management agent and configures it to use ARD’s directory-based management to assign permissions

The script is available below. It’s also available from GitHub using the following link:

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

As part of the pre-release announcements about macOS Mojave, Apple released the following KBase article:

Prepare your institution for iOS 12 or macOS Mojave:

https://support.apple.com/HT209028

As part of the KBase article, Apple included a Changes introduced in macOS Mojave section which featured this note:

You can allow apps to access certain files used for system administration, and to allow access to application data. For example, if an app requests access to your Calendar data, you can allow or deny the request. MDM administrators can manage these requests using the Privacy Preferences Policy Control payload, as documented in the Configuration Profile Reference.

What’s all this mean? For more details, see below the jump.

As part of macOS Mojave, Apple introduced new controls for accessing data in the individual user home folders. For more details about these changes, I recommend that you check out the following video and blog posts. Don’t worry about me, I’ll wait:

• Better Apps through Better Privacy: https://developer.apple.com/videos/play/wwdc2018/718/
• Apple Events Usage Description: https://indiestack.com/2018/08/apple-events-usage-description/
• macOS Mojave gets new APIs around AppleEvent sandboxing – but AEpocalyse still looms: https://www.felix-schwarz.org/blog/2018/08/new-apple-event-apis-in-macos-mojave
• A Looming Mac Automation Apocalypse?: https://sixcolors.com/link/2018/08/a-looping-mac-automation-apocalypse/

Back? OK, now that you’re familiar with what Apple was talking about with that section of the KBase, let’s discuss this section:

MDM administrators can manage these requests using the Privacy Preferences Policy Control payload, as documented in the Configuration Profile Reference.

What this means is that you may be able to whitelist your most common interactions and prevent them from displaying dialogs. Unfortunately, as of this date, Apple has provided only the following as documentation:

https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf (see the Privacy Preferences Policy Control Payload section.)

Apple refers to these as Privacy Preferences Policy Control Payload profiles, with a com.apple.TCC.configuration-profile-policy payload type. TCC stands for transparency consent and control and was discussed as part of the How iOS Security Really Works session at WWDC 2016:

https://developer.apple.com/videos/play/wwdc2016/705/?time=674

These profiles can only be deployed to macOS Mojave and must be deployed by an user-approved MDM solution.

While the current documentation doesn’t provide a lot of detail, based on my research, here is how the whitelist appears to work:

1. The item being whitelisted must be code-signed

As part of the profile, there is an entry for code signature so that the OS can verify that the whitelist entry matches up against the app requesting the action. How do you find out what the code signature of a particular app is? Run the following command against the application or other item that you want to whitelist:

codesign -dr - /path/to/Application.app

That said, there’s two ways that you can do this for third-party applications. As an example, if you’re using Jamf Pro 10.x to manage your Macs, the following application should be installed on your Mac:

/Library/Application Support/JAMF/Jamf.app

If you run the following command, you should get the code signature for the app:

codesign -dr - "/Library/Application Support/JAMF/Jamf.app"

There’s two ways you can add this information to the profile:

Example A:

identifier "com.jamf.management.Jamf" and anchor apple generic

Example B:

identifier "com.jamf.management.Jamf" and anchor apple generic and 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] = "483DWKW443"

Example A should be considered the least secure as it is very generic in how it reads the code signature, while Example B is the most secure because the full code signature is specified.

However, if Jamf ever needed to fundamentally change the code signature it was using for Jamf.app, Example A’s code signature would continue to match while Example B’s would not. Code signature fundamentals don’t change that often, but it is something to be aware of when creating the profiles.

One other thing to watch out for is multiple lines being returned by the code signature check, as I ran into this when checking an application produced by McAfee.

codesign -dr - "/Library/Application Support/McAfee/MSS/Applications/Menulet.app"

The needed code signing is what’s listed on the designated => line of output:

identifier "com.yourcompany.Menulet" and anchor apple generic and 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] = GT8P3H7SPW

2. The whitelist covers the parent process which is performing the action

Note: Here we’re heading off into territory that I can’t get confirmation about yet from Apple’s documentation. My research has lead me to the belief that the information below is right, but I don’t know for sure. Deploy appropriate levels of skepticism.

When creating the whitelist, you’re likely going to need to do a lot of testing to figure out what is actually calling an action that needs to be permitted by the user via a dialog window which appears. In many cases, you’ll need to whitelist the parent process which is asking for X, which in turn is running Y, which is executing Z and Z is what is actually causing the dialog window to appear.

A good example is when using Jamf’s Self Service to install software. A Self Service policy might include the following:

1. The policy which installs the software.
2. A notification that tells you “Hey, the software’s installed”
3. A script that pops up its own dialog window to say “Hey, we’ve installed this software but it’s unlicensed and we need you to now enter the license code you got from the help desk.”

Jamf has a couple of applications involved in this process to help it go smoothly:

/usr/local/jamf/bin/jamf
/usr/local/jamf/bin/jamfAgent

The notification and dialog window may trigger a dialog window which asks you if you want to allow a particular thing to happen. Depending on which application triggered it, you may see a notification that jamf (or jamfAgent) is the one requesting it. However, it may seem senseless: that “Hey, the software’s installed” notification is clearly an AppleScript dialog; why isn’t AppleScript the one being referred to as the requester?

The reason is that whichever application was named was the process that started the chain of events going. If jamfAgent is the one referenced, that means that the jamfAgent process is the process that asked AppleScript “Hey, mind showing that to my friend sitting between the keyboard and chair? Thanks.” So in this situation, even though it’s ultimately an AppleScript dialog window that appears, you would need to whitelist /usr/local/jamf/bin/jamfAgent.

3. There are filesystem permissions and there are application permissions

There are a number of dictionary keys available to the whitelist profiles:

• AddressBook
• Calendar
• Reminders
• Photos
• Camera
• Microphone
• Accessibility
• PostEvent
• SystemPolicyAllFiles
• SystemPolicySysAdminFiles
• AppleEvents

For whitelisting things like dialog messages and allowing access to data, there are two that seem to matter most:

• SystemPolicyAllFiles
• AppleEvents

SystemPolicyAllFiles allows the whitelisted application access to all protected files. As an example, your antivirus software may pop up dialog messages like crazy because it’s trying to scan areas of your home folder that Apple has now marked as protected. Once you identify the process which is actually running the scan and whitelist it using SystemPolicyAllFiles, the scans should now succeed without dialog messages because the scanning process has now been authorized by the whitelist to go into those areas.

AppleEvents allows the whitelisted application the ability to send an AppleEvent to an otherwise restricted application. For example, you may have a script which includes the following command:

osascript -e 'display dialog "Hey there!" with title "Hello"'

You may get a dialog window requesting permission to let osascript control the Finder. If you add an entry to your whitelist for /usr/bin/osascript, to authorize it to be able to send AppleEvents to com.apple.Finder, now you won’t get the permission request because now osascript is authorized to send requests to the Finder.

Creating the profiles

When creating my own profiles, I found a great tool created by Carl Ashley:

https://github.com/carlashley/tccprofile

This tool allowed me to plug in what I needed to whitelist and generated a profile for me. For example, I wanted to generate a profile for McAfee Endpoint Security with the following criteria:

Full Disk Access:

/Library/Application Support/McAfee/MSS/Applications/Menulet.app
/usr/local/McAfee/fmp/bin/fmpd

Note: /usr/local/McAfee/fmp/bin/fmpd is the McAfee file scanner

Able to send restricted AppleEvents:

/Library/Application Support/McAfee/MSS/Applications/Menulet.app – Send AppleEvents to SystemEvents, SystemUIServer and Finder

I was able to use the following command with the tccprofile tool to generate the profile I needed:

However, there was a problem with the profile because of McAfee’s extra code-signing line.

Once the profile was edited to remove the extra code signature information, the profile was ready to go.

Reference Examples

Since this is a new area for Mac admins, I’ve posted several profiles for reference at the following location:

https://github.com/rtrouton/privacy_preferences_control_profiles

All were generated by the tccprofile tool and I’ve included README files that describe the individual profiles and the commands used to create the profile in question.

On September 13th, Jamf released a new KBase article for Jamf Pro customers who hosted Jamf Pro themselves instead of hosting in Jamf Cloud:

On-Prem Jamf Pro Customers Upgrading to 10.7.0: https://www.jamf.com/jamf-nation/articles/552/on-prem-jamf-pro-customers-upgrading-to-10-7-0

In the KBase article, Jamf provides a couple of MySQL commands to run:

select computer_group_id,criteria,criteria_display from smart_computer_group_criteria where criteria not in (select computer_group_name from computer_groups) and search_field="Computer Group";

select computer_group_id,criteria,criteria_display from smart_computer_group_criteria where binary criteria not in (select binary computer_group_name from computer_groups) and search_field="Computer Group";

If either query returned data, the KBase directs you to contact Jamf Support. This was my output:

What had happened? For more details, please see below the jump.

When I looked at the list, the fact that all of the results returned Testing rang a bell. I’m using JSSImporter, which uses .jss AutoPkg recipes to upload software to my Jamf Pro server. By default, most .jss AutoPkg recipes create smart groups which include the following criteria:

Computer Group: Member of: Testing

However, there is not a static or smart group named Testing on my Jamf Pro server, so that meant the smart groups generated by my .jss AutoPkg recipes contain Computer Group criteria which isn’t valid. This is the issue that Jamf Pro 10.7 has difficulty with and what the MySQL queries were meant to find.

So the fix is to do one of two things:

• Identify the relevant smart groups and either remove or update the criteria.
• Delete the relevant smart groups.

In my case, I’m not actually using the smart groups generated by JSSImporter and my .jss recipes. My own fix for this issue was to do the following:

A. Update the .jss recipes used with my Jamf Pro server to remove the section which creates smart groups.

B. Delete the existing smart groups from my Jamf Pro server.

C. Run a complete AutoPkg run to verify the following:

i. My JSSImporter-created policies now showed no scoping (previously, they were scoped to the smart groups)
ii. The smart groups were not recreated on my Jamf Pro server.

Once I did that and deleted the JSSImporter-created smart groups from my Jamf Pro server, I re-ran the MySQL commands and received the following results back:

I confirmed with Jamf Support that the output above indicated that the problem was fixed.

Note: I have not edited my publicly-available .jss AutoPkg recipes to remove the section which creates smart groups. If you’re using my .jss recipes and want to remove the section which creates smart groups, please do the following:

1. Make copies of the .jss recipes in question.
2. Assign the copies a new and unique AutoPkg recipe identifier
3. Remove the following section of the .jss recipe:

For those who wanted a copy of my Amazon Web Services talk at at the MacSysAdmin 2018 conference, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MSA2018AWSPDF

Keynote – http://tinyurl.com/MSA2018AWSKeynote

Since I’ve started working for my current employer, my colleagues and I have occasionally received the following question from various Mac admins:

“I’m using SAP in my environment. How do I deploy the Mac software for SAP?”

When we’ve followed up for more details, the “Mac software for SAP” usually means the SAP GUI software. SAP GUI comes in two flavors:

• SAP GUI for Windows
• SAP GUI for Java

SAP GUI for Java supports the following operating systems:

• openSUSE
• Fedora
• macOS
• Microsoft Windows
• AIX
• Ubuntu

The SAP GUI for Java is what’s available for macOS, so how to get it and deploy it? For more details, please see below the jump.

Pre-requisite

SAP GUI is a Java application, so Java must be installed before proceeding further. As of October 11, 2018, I recommend installing the latest Oracle Java 8 JDK for macOS.

The Java JDK can be downloaded from the following website:

https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Getting the SAP GUI for Java software

1. Go to the following link:

https://support.sap.com/en/my-support/software-downloads.html

2. Click on Support Packages & Patches

3. Click on Access Downloads

4. Select By Category

5. Select SAP Frontend Components

6. Select SAP GUI for Java

7. Click on the latest SAP GUI for Java

As of October 11, 2018, this will be SAP GUI for Java 7.50

8. Verify that the Items Available to Download drop-down menu is set to MAC OS

9. Select and download the latest available PlatinGUI .jar file.

Building configuration files

Along with the SAP GUI application, you can also prepare a set of pre-configured settings files for SAP GUI. These configuration files are described as part of the documentation for SAP GUI, in the Administration: Configuration Files section

Once you have your connections and settings files configured the way you want them, export them and name them as follows:

Connections: connections.template
Settings: settings.template

If you have additional exported settings, also follow the .template naming scheme.

Once you have your .template files ready, use the following Java command to create a file named templates.jar:

jar -cf /path/to/templates.jar /path/to/filename1.template /path/to/filename2.template /path/to/filename3.template

For example, if I have a settings.template file and a trustClassification.template file stored in my home folder, I would use the following Java command to create a templates.jar file on my user account’s Downloads folder:

jar -cf /Users/username/Downloads/templates.jar /Users/username/settings.template /Users/username/trustClassification.template

The .template files are stored inside the templates.jar file:

If the templates.jar file is in the same directory as the PlatinGUI .jar file when the installation process is run, the .template files will be installed along with the SAP GUI application and stored in SAP GUI.app/Contents/Resources.

When a user launches the SAP GUI application, if they do not already have an ~/Library/Preferences/SAP directory, the settings.template and trustClassification.template files will be copied to the ~/Library/Preferences/SAP directory with the following filenames:

• ~/Library/Preferences/SAP/settings
• ~/Library/Preferences/SAP/trustClassification

Building the SAP GUI installer

Pre-requisites:

• Packages
• SAP GUI for Java installer (this is the PlatinGUI .jar file)
• templates.jar file (optional)

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

2. In this case, I’m naming the project SAP GUI 7.50 rev4.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

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

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Tag section:

Identifier: set as appropriate (for my installer, I’m using com.sap.pkg.SAPGUI750rev4)
Version: set as appropriate (for my installer, I’m using 7.50.04 )

In the Post-installation Behavior section:

On Success: should be set to Do Nothing

In the Options section:

Require admin password for installation should be checked
Relocatable should be unchecked
Overwrite directory permissions should be unchecked
Follow symbolic links should be unchecked

5. Select the Payload tab. Nothing here should be changed from the defaults.

6. Select the Scripts tab. Under the Additional Resources section, add the following file:

The SAP GUI for Java installer (this is the PlatinGUI .jar file)

If you have a templates.jar file, also add that file.

7. The last part is telling the SAP GUI for Java installer to run with the correct options selected. For this, you’ll need a postinstall script.

See below the postinstall script being used for this installer package:

Once created, select the postinstall script and add it to the project.

8. Build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by installing it on a test machine which has the following:

• Java installed
• Does not have the SAP GUI client installed

The end result should be that the SAP GUI client installs into /Applications.

If a templates.jar was included with the installer, the SAP GUI configuration template files specified by the templates.jar file should also be installed.

The documentation from MacSysAdmin 2018 is available, with the session slides and videos being accessible from the link below:

http://documentation.macsysadmin.se

The video of my session is available for download from here:

• Getting started with Amazon Web Services: http://docs.macsysadmin.se/2018/video/Day4Session4.mp4

I also like to thank Tycho Sjögren and Apoio AB for inviting me to speak again at this year’s MacSysAdmin.

With Java 8 approaching the end of its lifecycle, Oracle has made some changes to the Oracle JDK license that will affect Java 11’s JDK. As of Oracle Java JDK 8, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping
• Production

As of Oracle Java JDK 11, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping

Notice that Production has dropped off the list? If you use Oracle Java JDK 11 for production use, Oracle is now expecting payment. For the complete details, please see the license agreement (relevant sections highlighted below):

If you don’t want to or can’t pay Oracle, what are the available options?

1. Keep using Oracle Java JDK 8

Oracle will continue to provide updates for Java 8 until January 2019, so a short-term solution is to keep using JDK 8 until support ends. This is only a short term solution however. If you want to continue using Java 8 past January 2019, you may need to start paying Oracle in order to get access to continuing Java 8 support.

2. Migrate from Oracle Java JDK to OpenJDK

In addition to its commercial offering, Oracle has an open-source Java available named OpenJDK. As of Java 11, Oracle will be providing functionally identical JDK builds to both the commercially licensed Oracle JDK and the open-source OpenJDK. For more details, please see below the jump:

An important difference between Oracle JDK 11 and OpenJDK 11 for Mac admins is the following:

• Oracle JDK: Oracle will provide an installer package for macOS
• OpenJDK: Oracle does not provide an installer for macOS at this time.

OpenJDK builds for macOS are currently available as zip and tar.gz files. The JDK files need to be uncompressed and moved into the following location on macOS:

/Library/Java/JavaVirtualMachines

Once uncompressed into /Library/Java/JavaVirtualMachines, the JDK build should be stored in a directory named for the specific OpenJDK version. The directory and all enclosed files need to have the following permissions set:

macOS should automatically pick up the new Java version once added to /Library/Java/JavaVirtualMachines.

To display information about it, run the following command:

java -version

To help address the current lack of an installer package for OpenJDK 11, I’ve written several AutoPkg recipes:

The .pkg recipe will create an installer package which does the following:

1. Removes any existing OpenJDK 11 builds from /Library/Java/JavaVirtualMachines using a preinstall script
2. Installs the latest OpenJDK 11 build with the correct permissions into /Library/Java/JavaVirtualMachines

The preinstall script used is available below:

For those who wanted a copy of my Mac management talk at at Jamf Nation User Conference 2018, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/JNUC2018SAPPDF

Keynote – http://tinyurl.com/JNUC2018SAPKeynote

Apple recently released an overview document for its new T2 chip, which includes how the new T2 chip-equipped Macs have new protections against brute force attacks. This protection only applies if FileVault is enabled and is similar in concept to how iOS devices set with passcodes are protected against brute force attacks.

On iOS, if an incorrect passcode is entered more than five times, a one minute delay is set.

After the sixth try, the delay is now five minutes and the delays get longer from there until the device has the 10th wrong passcode entered and the device wipes.

On Apple iOS devices with a Secure Enclave, those delays are enforced by the Secure Enclave processor. Similarly, the T2 chip-equipped Macs also have a Secure Enclave processor which is managing access attempts and introducing delays.

For Macs with Secure Enclave, the enforcement looks like this:

• 30 unlock attempts via using the password at the login window or target disk mode
• 10 unlock attempts via using the password in Recovery Mode
• 30 unlock attempts for each enabled FileVault recovery mechanism
• iCloud recovery
• FileVault personal recovery key
• FileVault institutional recovery key

The maximum number of unlock attempts is 90, regardless of the mix of methods used. After 90 attempts, the Secure Enclave processor will no longer process any requests to do the following:

• Unlock the volume
• Decrypt the volume
• Verify the password / recovery key

Delays are also imposed on macOS between attempts.

So what happens after 90 attempts? Does the Mac lock forever and become a paperweight?

After checking with AppleCare Enterprise, the answer is that the Mac will not be a paperweight, but that the Mac’s boot drive will need to be erased before it can be used again. This approach helps make sure that the Mac is still usable, but also ensures that the encrypted data stored on the boot drive is no longer recoverable.

For more information about brute force protection for encrypted iOS and macOS devices, I recommend checking out Apple’s currently available white papers:

• iOS: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf
• macOS: https://www.apple.com/mac/docs/Apple_T2_Security_Chip_Overview.pdf

Jamf has posted the session videos for from Jamf Nation User Conference 2018, including the video for my “Providing the Best Mac Experience Possible, From the Mac CoE Team with ” session.

For those interested, all of the the JNUC 2018 session videos are available on YouTube. For convenience, I’ve linked my session here.

When working with configuration profiles on Jamf Pro, I prefer to download and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the profiles
2. I can track changes to the profiles

Up until recently, this had been a manual process for me where I would download the profiles in question from the server and then upload them to my source control tool.

My process looked like this:

1. Download the profiles from the Jamf Pro server using the Download button.

2. Remove the code-signing and formatting the profile using a process similar to the one described in the link below:

https://macmule.com/2015/11/16/making-downloaded-jss-configuration-profiles-readable/

3. Move the profile to the correct directory in my source control repo.
4. Review changes and commit to the repo.

However, as I’ve started using profiles more, this process got cumbersome and I wanted to automate at least the download part of the process. After some work, I was able to build two scripts which do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the configuration profiles.
2. Download each profile using its Jamf Pro ID number
3. Decode and format the profile
4. Identify the display name of the profile
5. Save the profile as Display Name Here.mobileconfig to a specified download directory.

For more details, please see below the jump.

I’ve written two scripts for this purpose:

• Jamf_Pro_Mac_Configuration_Profile_Download.sh – This script is designed to download and handle macOS configuration profiles
• Jamf_Pro_Mobile_Device_Configuration_Profile_Download.sh – This script is designed to download and handle iOS and tvOS configuration profiles

For authentication, the scripts 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

Both scripts run in similar ways, with the main difference being which kind of profiles are being downloaded.

To download macOS profiles:

/path/to/Jamf_Pro_Mac_Configuration_Profile_Download.sh

To download iOS and tvOS profiles:

/path/to/Jamf_Pro_Mobile_Device_Configuration_Profile_Download.sh

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

The profiles themselves will be stored in either a user-specified directory or, if no directory is specified, a directory created by the script.

The scripts are available below, and at the following addresses on GitHub:

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

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

Jamf_Pro_Mac_Configuration_Profile_Download.sh:

Jamf_Pro_Mobile_Device_Configuration_Profile_Download.sh:

When working with smart and static groups on Jamf Pro, especially more complex smart groups, I prefer to download then and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the groups
2. I can track changes to the groups
3. If needed, I can make a change to a smart group and upload via the API instead of having to edit in the web console.

Up until recently, I didn’t have a good process for handling this but I was able to develop a way as part of working with an engineer from Jamf. After some work, I was able to build two scripts which do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the smart and static groups.
2. Download each group as an XML file using its Jamf Pro ID number.
3. Format the downloaded XML.
4. Identify the display name of the group.
5. Identify if it was a smart or static group.
6. Save the downloaded XML as Group Name Here.xml to a specified download directory, based on whether it was a smart or static group.

For more details, please see below the jump.

I’ve written two scripts for this purpose:

• Jamf_Pro_Computer_Group_Download.sh – This script is designed to download and handle macOS smart and static groups
• Jamf_Pro_Mobile_Device_Group_Download.sh – This script is designed to download and handle iOS and tvOS smart and static groups.

For authentication, the scripts 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

Both scripts run in similar ways, with the main difference being which kind of profiles are being downloaded.

To download macOS smart and static groups:

/path/to/Jamf_Pro_Computer_Group_Download.sh

To download iOS and tvOS smart and static groups:

/path/to/Jamf_Pro_Mobile_Device_Group_Download.sh

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

The groups themselves will be stored in either a user-specified directory or, if no directory is specified, a directory created by the script. They will be sorted by whether the individual group is a smart or static group.

The scripts are available below, and at the following addresses on GitHub:

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

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

Jamf_Pro_Computer_Group_Download.sh:

Jamf_Pro_Mobile_Device_Group_Download.sh:

Now that macOS Mojave has been released, it’s become more difficult to access the macOS High Sierra installer for those who still need it. Fortunately, High Sierra 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 High Sierra page in the Mac App Store, available via the link below:

https://support.apple.com/HT208969

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

https://itunes.apple.com/us/app/macos-high-sierra/id1246284741?ls=1&mt=12

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

In the event that you’re blocked from downloading macOS High Sierra, 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/

When working with scripts for managing Macs on Jamf Pro, I prefer to download then and back them up to GitHub or a similar internal source control tool. The reason I do this is the following:

1. I have an off-server backup for the scripts
2. I can track changes to the scripts

While I’ve usually had copies of the scripts stored elsewhere, sometimes I would make changes to the scripts on Jamf Pro and then not update the offline copy of the scripts with my changes. Being able to download them from my Jamf Pro server would mean that I could always have a copy of the latest version of the script in production.

To help me with this, I’ve written a script to do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the scripts.
2. Download each script using its Jamf Pro ID number as raw XML.
3. Format the downloaded XML
4. Identify the display name of the script
5. Extract the script from the downloaded XML
6. Save the script as Display Name Goes Here to a specified download directory.

For more details, please see below the jump.

For authentication, the download 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

To run the download script:

/path/to/Jamf_Pro_Computer_Script_Download.sh

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

The downloaded scripts themselves will be stored in either a user-specified directory or, if no directory is specified, a directory created by the script.

The download 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_Computer_Script_Download

Jamf_Pro_Computer_Script_Download.sh:

A while back, I wrote a post on building a SAP GUI installer for macOS, where SAP GUI needed to have Oracle’s Java 8 JDK as a pre-requisite. Since then Oracle has made an announcement that the use of Oracle’s Java 11 JDK is no longer free if you’re using it for production work.

One of the consequences of that decision by Oracle is that SAP GUI 7.50 rev 5 is the first version of SAP GUI to support Java 11. However, the SAP GUI developers are now recommending the use of OpenJDK 11 in place of Oracle’s Java JDK 11. More specifically, the SAP GUI folks are recommending the use of SAP’s own SapMachine Java JDK 11 release.

Meanwhile, a Java library named JavaFX used by SAP GUI is no longer being bundled as part of Java 11. Instead, JavaFX has been split off into its own open source project called OpenJFX and is now a separate install.

What do SapMachine JDK 11 and JavaFX have in common? Among other things, neither have a native installer for macOS. Instead, each is distributed via compressed files.

Installation is performed by uncompressing into the following directory on macOS:

/Library/Java/JavaVirtualMachines

That said, SAP GUI also still works with Oracle’s Java JDK 8 as of the release of SAP GUI 7.50 rev 5. JavaFX is bundled with Java JDK 8, so installing Oracle’s Java JDK 8 handles both the Java and JavaFX requirements.

With all the changes, how should SAP GUI now be packaged for installation? Without question, the main challenge for deployment here is going to be the Java component. In my testing, which was limited to “Launch SAP GUI and see if it runs”, I found SAP GUI 7.50 rev 5 is able to run on the following Java releases:

• Oracle Java JDK 8 Update 191
• Oracle Java JDK 11.0.1
• OpenJDK 11.0.1
• SapMachine JDK 11.0.1.13

If using any Java 11 release, OpenJFX will need to be installed for SAP GUI to successfully run.

With this in mind, it’s possible to build a package that does the following:

1. Detects if Java is installed
2. Detects if JavaFX is installed
3. If Java is not installed, install the latest release of SapMachine JDK.
4. If JavaFX is not installed, install the latest release of OpenJFX.
5. Verifies that both Java and JavaFX are installed.
6. If both Java and JavaFX are installed, install SAP GUI

For more details, please see below the jump.

For information on how to get and configure the SAP GUI installer, please see my earlier post on the topic as these details have not changed.

Downloading SapMachine Java 11 JDK

As of SAP GUI 7.50 rev 5, SAP GUI supports Java 11, with the preferred Java 11 release being the latest SapMachine OpenJDK 11 release. SapMachine is maintained and supported by SAP, so it is the OpenJDK 11 release best supported by SAP for SAP GUI.

To get the latest SapMachine OpenJDK 11 release, use the link below:

https://github.com/sap/SapMachine/releases/latest

Download the sapmachine-jdk-version_number_here_osx-x64_bin.tar.gz file.

Downloading JavaFX

As of Java 11, the JavaFX libraries used by SAP GUI are no longer bundled as part of the Java JDK. Instead, they must be downloaded and installed separately.

To get the latest OpenJFX release, use the link below:

https://gluonhq.com/products/javafx/

Download the JavaFX Mac OS X SDK .zip file.

Building the SAP GUI installer

The SAP GUI installer can perform the following tasks:

• Installing the latest Java on an as-needed basis
• Installing the latest JavaFX on an as-needed basis
• Installing the SAP GUI software
• Installing the SAP GUI connection and settings files

Pre-requisites

• Packages
• The latest SapMachine Java 11 JDK release
• The latest OpenJFX Java release
• SAP GUI for Java installer
• templates.jar file (optional)

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

2. In this case, I’m naming the project SAP GUI 7.50 rev5.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

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

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Tag section:

Identifier: set as appropriate (for my installer, I’m using com.sap.pkg.SAPGUI750rev5 )
Version: set as appropriate (for my installer, I’m usings 7.50.05 )

In the Post-installation Behavior section:

On Success: should be set to Do Nothing

In the Options section:

Require admin password for installation should be checked
Relocatable should be unchecked
Overwrite directory permissions should be unchecked
Follow symbolic links should be unchecked

7. Select the Payload tab. Nothing here should be changed from the defaults.

8. Select the Scripts tab.

Under the Additional Resources section, add the following files:

• The latest SapMachine Java 11 JDK release
• The latest OpenJFX Java release
• The latest SAP GUI for Java installer (this is the PlatinGUI .jar file)

If you have a templates.jar file, also add that file.

The last part is telling the SAP GUI for Java installer to run. For this, you’ll need a preinstall script and postinstall script.

Here’s the preinstall script being used for this installer package:

If not already selected, select the preinstall script and add it to the project.

Here’s the postinstall script being used for this installer package:

If not already selected, select the postinstall script and add it to the project.

9. Build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by installing it on a test machine which has the following:

• Does not have the SAP GUI client installed

The end result should be that the SAP GUI client installs into /Applications. If a templates.jar was included with the installer, the SAP GUI configuration specified by the templates.jar file should also be installed.

Depending on whether Java is installed on this test machine or not, the following actions should take place:

• If Java 8 JDK is installed on the test Mac, neither SapMachine JDK 11 or JavaFX should be installed by the SAP GUI installer.
• If Java 11 JDK and Open JavaFX are installed, neither SapMachine JDK 11 or JavaFX should be installed by the SAP GUI installer.
• If Java 11 JDK is installed, only Open JavaFX should be installed by the SAP GUI installer.
• If Java is not installed, both SapMachine JDK 11 and Open JavaFX should be installed by the SAP GUI installer.

While working with extension attributes on Jamf Pro, I prefer to download then and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the extension attributes
2. I can track changes to the extension attributes

To help me manage this, I have two scripts which do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the extension attributes.
2. Download each extension attribute as an XML file using its Jamf Pro ID number.
3. Format the downloaded XML.
4. Identify the display name of the extension attribute.
5. Identify if it was a String, Integer or Date extension attribute.
6. If it’s a macOS or Windows extension attribute and it has a script, extract the script.
7. Save the downloaded XML or script as Extension Attribute Name Here to a specified download directory, based on whether it was a String, Integer or Date extension attribute.

For more details, please see below the jump.

I’ve written two scripts for this purpose:

• Jamf_Pro_Computer_Extension_Attribute_Download.sh – This script is designed to download and handle macOS extension attributes.
• Jamf_Pro_Mobile_Device_Extension_Attribute_Download.sh – This script is designed to download and handle iOS and tvOS extension attributes.

For authentication, the scripts 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

Both scripts run in similar ways, with the main difference being which kind of extension attributes are being downloaded. One notable difference is that the macOS extension attributes may download scripts, while the iOS and tvOS extension attributes will only ever be XML files.

To download macOS extension attributes:

/path/to/Jamf_Pro_Computer_Extension_Attribute_Download.sh

To download iOS and tvOS extension attributes:

/path/to/Jamf_Pro_Mobile_Device_Extension_Attribute_Download.sh

When run, you should see output similar to that shown below (in this case, Jamf_Pro_Computer_Extension_Attribute_Download.sh is being run.)

The extension attributes themselves will be stored in either a user-specified directory or, if no directory is specified, a directory created by the script.

The scripts are available below, and at the following addresses on GitHub:

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

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

Jamf_Pro_Computer_Extension_Attribute_Download.sh:

Jamf_Pro_Mobile_Device_Extension_Attribute_Download.sh:

When working with computer management policies on Jamf Pro, especially more complex policies, I prefer to download then and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the policies
2. I can track changes to the groups
3. If needed, I can make a change to a policy and upload via the API instead of having to edit in the web console.

Up until recently, I didn’t have a good process for handling this but after some work, I was able to build a script which does the following:

1. If any policies were previously downloaded, back up existing downloaded policies into a .zip file
2. Download the policy information as XML
3. Properly format the downloaded XML
4. Identify the display name of the policy.
5. Identify the category of the policy.
6. Save the downloaded XML as Policy Name Here.xml to a specified download directory, based on the category that the policy is in.

The reason the script archives previously downloaded policies are the following:

1. In case something goes wrong with the download, I still have the previously archived copy.
2. The script can clear out the existing download directory and have only the latest version of the policy stored inside.

For more details, please see below the jump.

The script I’ve written is named Jamf_Pro_Computer_Policy_Download.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

The policies themselves will be stored in either a user-specified directory or, if no directory is specified, a directory created by the script. When the script is run, you should see output similar to that shown below.

If no download directory is specified:

If a download directory is specified and has existing contents:

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_Computer_Policy_Download

Jamf_Pro_Computer_Policy_Download.sh: