Packaging SAP GUI for macOS with Java 11 support

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.

Backing up macOS scripts from Jamf Pro

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.

Downloading macOS High Sierra from the Mac App Store

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/

Backing up smart and static groups from Jamf Pro

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.

Backing up configuration profiles from Jamf Pro

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.

Session videos from Jamf Nation User Conference 2018 now available

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.

T2, FileVault and brute force attack protection

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