Downloading and installing macOS Big Sur via macOS Recovery’s Terminal
Every so often, you may find yourself in a situation where you need to reinstall macOS Big Sur and everything is failing on you. Installing from macOS Recovery? Not working via the usual methods. Building a USB installer? Left the flash drive in your other pants. Using DFU mode and Apple Configurator on an Apple Silicon Mac? You need a second Mac to use this process and you just have the one Mac available.
For those situations, there’s one more option when you’ve exhausted all of the others. For more details, please see below the jump.
Signing AutoPkg-built packages using a .sign recipe
For those that need to sign their AutoPkg-generated installer packages with a signing certificate, the PkgSigner processor is available to assist with this. When I originally started using this processor, I was building the signing part directly into .pkg recipes, but my teammate @jaharmi came up with a better and more modular idea: the .sign recipe.
The .sign recipe uses the PkgSigner processor and is designed to be placed in the AutoPkg workflow between a .pkg recipe and a.jss recipe for JSSImporter, a .munki recipe for Munki or other recipes used to upload an installer package to a deployment tool. In this case, the .pkg recipe would be a parent recipe for the .sign recipe. In turn, the .sign recipe would be used as the parent recipe for whatever came next in the workflow.
For those who want to use .sign recipes, there is an example recipe available via the link below:
https://github.com/autopkg/rtrouton-recipes/blob/master/SharedProcessors/Example.sign.recipe
If you want to use the PkgSigner processor hosted from my AutoPkg recipe repo, first verify that AutoPkg is installed on the Mac you’re using. Once verified, run the following command:
autopkg repo-add rtrouton-recipes
Videos from Penn State MacAdmins Campfire Sessions 2021
The good folks at Penn State have been 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=PLRUboZUQxbyUEsp4L7hPYdWpFwXK53Zmt
I’ve linked my SAP in the Haus – How SAP transitioned its global workforce to working from home session here:
Packaging a SAP GUI installer application for macOS
One of the recent changes for the macOS version of SAP GUI for Java is that both SapMachine Java 11 and OpenJFX 11 are now bundled with SAP GUI, so it is no longer required to have Java installed on your machine in order for SAP GUI to work. This change has also been extended to the SAP GUI installer, which is now available as a notarized installer application as of SAP GUI 7.70.
You can run this installer on a Mac which does not have Java already installed and it will install SAP GUI for Java with SapMachine Java 11 and OpenJFX 11 installations embedded inside the SAP GUI application.
Note: As of SAP GUI 7.70 rev 2, Rosetta 2 is required if installing on an Apple Silicon Mac so Rosetta needs to be installed and running before installing SAP GUI.
The installer application is available for download to customers via a link on the announcement blog post:
https://blogs.sap.com/2021/03/16/ann-sap-gui-for-java-7.70-available-for-download/
When you click the download link, you will see two choices:
- DMG
- JAR
The DMG download will provide the notarized installer application and the JAR download will provide the Java .jar installer that SAP GUI has traditionally used on macOS. I’ve discussed how to package the .jar installer in previous posts, so this post is going to focus on the new installer application contained inside the DMG download.
For more details, please see below the jump.
Monitoring Startup Security settings on Apple Silicon Macs
To help maintain the security of the Apple Silicon Macs in your environment, it’s helpful to be able to monitor what the Startup Security settings are for those Macs.
For this task, the reporting functions of the bputil tool are available. Normally, Apple wants you to avoid the bputil tool like you would a swarm of bees. As part of that, the following warning is displayed by bputil:
| username@computername ~ % bputil -d | |
| This utility is not meant for normal users or even sysadmins. | |
| It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. | |
| It is possible to make your system security much weaker and therefore easier to compromise using this tool. | |
| This tool is not to be used in production environments. | |
| It is possible to render your system unbootable with this tool. | |
| It should only be used to understand how the security of Apple Silicon Macs works. | |
| Use at your own risk! | |
| The tool requires running as root | |
| username@computername ~ % |
However, the bputil -d command is safe to use as it displays the contents of the current security policy’s settings. When the default Full Security security mode is enabled, running the bputil -d command with root privileges should display content similar to what’s shown below:
| username@computername ~ % sudo bputil -d | |
| Password: | |
| This utility is not meant for normal users or even sysadmins. | |
| It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. | |
| It is possible to make your system security much weaker and therefore easier to compromise using this tool. | |
| This tool is not to be used in production environments. | |
| It is possible to render your system unbootable with this tool. | |
| It should only be used to understand how the security of Apple Silicon Macs works. | |
| Use at your own risk! | |
| Current OS environment: | |
| OS Type : macOS | |
| Local Policy Nonce Hash (lpnh): 7E1ED4512B6DF2A284C6343E469C1F1459453E4898E770CF37A8F3B1D9C000E0DA0C5C5F0546AB70984BEC3A9870DD9E | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Recovery OS Policy Nonce Hash (ronh): 6CF5EB6318AF551C5A23B8D3B2E4196AAA372B523E4F412C375CF6B39DCFED28F9B4E9881BF348886F9B9A14E918AA69 | |
| Current local policy: | |
| Signature Type : BAA | |
| Unique Chip ID (ECID): 0xD793810C0291E | |
| Board ID (BORD): 0x26 | |
| Chip ID (CHIP): 0x8103 | |
| Certificate Epoch (CEPO): 0x1 | |
| Security Domain (SDOM): 0x1 | |
| Production Status (CPRO): 1 | |
| Security Mode (CSEC): 1 | |
| OS Version (love): 21.1.268.5.8,0 | |
| Volume Group UUID (vuid): 2D85CA09-A291-47CA-A68A-66CB2D3BDF70 | |
| KEK Group UUID (kuid): AC09E9D5-36DC-10C9-4312-E6DAA3753224 | |
| Local Policy Nonce Hash (lpnh): 7E1ED4512B6DF2A284C6343E469C1F1459453E4898E770CF37A8F3B1D9C000E0DA0C5C5F0546AB70984BEC3A9870DD9E | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Next Stage Image4 Hash (nsih): 443560FD2BE056BC9527452729EEC1A1BB22BA2DA456B278624DEF822DE9F7A64F0303B64ED811405B4039475F8A623D | |
| User Authorized Kext List Hash (auxp): absent | |
| Auxiliary Kernel Cache Image4 Hash (auxi): absent | |
| Kext Receipt Hash (auxr): absent | |
| CustomKC or fuOS Image4 Hash (coih): absent | |
| Security Mode: Full (smb0): absent | |
| User-allowed MDM Control: Disabled (smb3): absent | |
| DEP-allowed MDM Control: Disabled (smb4): absent | |
| SIP Status: Enabled (sip0): absent | |
| Signed System Volume Status: Enabled (sip1): absent | |
| Kernel CTRR Status: Enabled (sip2): absent | |
| Boot Args Filtering Status: Enabled (sip3): absent | |
| 3rd Party Kexts Status: Disabled (smb2): absent | |
| username@computername ~ % |
Here’s what bputil -d will return if the Startup Security settings are configured as follows:
- Reduced Security: Enabled
- Allow user management or kernel extensions from identified developers: Enabled
- Allow remote management of kernel extensions from identified developers: Enabled
| username@computername ~ % sudo bputil -d | |
| Password: | |
| This utility is not meant for normal users or even sysadmins. | |
| It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. | |
| It is possible to make your system security much weaker and therefore easier to compromise using this tool. | |
| This tool is not to be used in production environments. | |
| It is possible to render your system unbootable with this tool. | |
| It should only be used to understand how the security of Apple Silicon Macs works. | |
| Use at your own risk! | |
| Current OS environment: | |
| OS Type : macOS | |
| Local Policy Nonce Hash (lpnh): 987619CF88732BB0FB0CCC476302DFE84EB1C1F7B92E8CBEC4B124D9F76B3DBACD8787E5DEBB8A3F70576639CE74F727 | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Recovery OS Policy Nonce Hash (ronh): 6CF5EB6318AF551C5A23B8D3B2E4196AAA372B523E4F412C375CF6B39DCFED28F9B4E9881BF348886F9B9A14E918AA69 | |
| Current local policy: | |
| Signature Type : BAA | |
| Unique Chip ID (ECID): 0xD793810C0291E | |
| Board ID (BORD): 0x26 | |
| Chip ID (CHIP): 0x8103 | |
| Certificate Epoch (CEPO): 0x1 | |
| Security Domain (SDOM): 0x1 | |
| Production Status (CPRO): 1 | |
| Security Mode (CSEC): 1 | |
| OS Version (love): 21.1.284.5.5,0 | |
| Volume Group UUID (vuid): 2D85CA09-A291-47CA-A68A-66CB2D3BDF70 | |
| KEK Group UUID (kuid): AC09E9D5-36DC-10C9-4312-E6DAA3753224 | |
| Local Policy Nonce Hash (lpnh): 987619CF88732BB0FB0CCC476302DFE84EB1C1F7B92E8CBEC4B124D9F76B3DBACD8787E5DEBB8A3F70576639CE74F727 | |
| Remote Policy Nonce Hash (rpnh): 88EB8429C516B53BBCA49EC7C0D58C3F27F2890D23E176264B2178EE2A865327CFD06ED94834EE6FF7D145FB39245B59 | |
| Next Stage Image4 Hash (nsih): 1FAC4F6723D591DD6FAEC1DDB7D84C0AB28782096F8F2570EDA1F3CC41DECBE883A59BC4C3C962484E283F4E11549CB6 | |
| User Authorized Kext List Hash (auxp): absent | |
| Auxiliary Kernel Cache Image4 Hash (auxi): absent | |
| Kext Receipt Hash (auxr): absent | |
| CustomKC or fuOS Image4 Hash (coih): absent | |
| Security Mode: Reduced (smb0): 1 | |
| User-allowed MDM Control: Enabled (smb3): 1 | |
| DEP-allowed MDM Control: Disabled (smb4): absent | |
| SIP Status: Enabled (sip0): absent | |
| Signed System Volume Status: Enabled (sip1): absent | |
| Kernel CTRR Status: Enabled (sip2): absent | |
| Boot Args Filtering Status: Enabled (sip3): absent | |
| 3rd Party Kexts Status: Enabled (smb2): 1 | |
| username@computername ~ % |
Note: This reporting function does not require macOS Recovery and works while booted from regular macOS.
To check the Startup Security settings, the following status codes should be checked:
- smb0
- smb2
- smb3
In the Startup Security Utility app in macOS Recovery, the following settings correspond to the status codes listed above:
- smb0: Full Security / Reduced Security
- smb2: Allow user management of kernel extensions from identified developers
- smb3: Allow remote management of kernel extensions from identified developers
For more details, please see below the jump.
Slides from the “SAP In The Haus” session at Penn State MacAdmins 2021
For those who wanted a copy of my talk from Penn State MacAdmins 2021, here are links to the slides in PDF and Keynote format.
AutoPkg recipes for OS X Lion and OS X Mountain Lion OS installers now available
Now that Apple has made direct download links available for Lion and Mountain Lion, I’ve written AutoPkg .download and .pkg recipes for the following OS X installers:
These recipes will download the disk images linked to the relevant KBase articles, extract the installer packages stored inside the disk images and rename the disk images and installer packages with the OS name and version number.
One thing to be aware of is that the downloaded installers do not themselves install the relevant version of OS X. Instead, they install the Install.app for that version of OS X into the /Applications directory.
Another thing to know is that the downloaded installers are signed using Software Update signing certificates which expired in 2019. As of June 30th, 2021, I do not know if Apple is planning to re-sign the installers with the current Software Update signing certificate.
One of the consequences of this is that I cannot use AutoPkg’s code signature verification as part of the AutoPkg recipes, since AutoPkg’s current code signature verification will error when it hit the expired certificates. If Apple does choose to re-sign these certificate with valid non-expired signing certificates, I’ll add code signature verification to the recipes.
If you do need to use these installers, setting the system clock on your Mac to a date and time before the October 24th 2019 expiration date will allow these certificates to appear as valid again and any expiration-related issues should go away.
The AutoPkg recipes are available via the links below:
OS X Lion: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXLion
OS X Mountain Lion: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXMountainLion
Backing up Self Service bookmarks for Jamf Pro 10.30.0 and later
A while ago, I wrote a post on how to back up your Jamf Pro Self Service bookmarks. I’ve been using that process to back up my bookmarks and it’s been working fine until after my upgrade to Jamf Pro 10.30.0. At that point, my script stopped working. When I checked into it and talked with some colleagues, it became apparent that Jamf had made a change with how they stored bookmark information for Self Service.
In 10.29.x and earlier, Jamf had stored bookmarks as individual plist files in the following location:
/Library/Application Support/JAMF/Self Service/Managed Plug-ins
In 10.30.x and later, the /Library/Application Support/JAMF/Self Service/Managed Plug-ins directory has disappeared.
Jamf now stores bookmark information inside an XML file named CocoaAppCD.storedata in the user’s home folder at the following location:
~/Library/Application Support/com.jamfsoftware.selfservice.mac/CocoaAppCD.storedata
Inside the CocoaAppCD.storedata file, the bookmarks are stored as XML objects similar to what is shown below:
| <object type="SSBOOKMARK" id="z169"> | |
| <attribute name="url" type="string">https://www.bananas.com</attribute> | |
| <attribute name="priority" type="int64">5</attribute> | |
| <attribute name="displayinbrowser" type="bool">1</attribute> | |
| <attribute name="name" type="string">Bananas.com</attribute> | |
| <attribute name="jssdescription" type="string">Bananas.com</attribute> | |
| <attribute name="installstatus" type="int64">0</attribute> | |
| <attribute name="id" type="int64">2</attribute> | |
| <attribute name="iconurl" type="string">https://ics.services.jamfcloud.com/icon/hash_95740013589cddd19b2192016788dd9e91e735f8ff5213f92005f4eb92ac16b6</attribute> | |
| <attribute name="compliance" type="bool">0</attribute> | |
| <attribute name="buttontext" type="string">Open</attribute> | |
| </object> |
Fortunately, I was able to figure out a way to do the following:
- Parse the document for the bookmark XML objects.
- Split them out into individual XML files.
- Name the files using the title of the Self Service bookmark.
For more details, please see below the jump.
Jamf Pro deprecating the ability to issue a Tomcat certificate from the Jamf Pro built-in certificate authority
As part of the release of Jamf Pro 10.30, the following entry was added to the Deprecations section of the Jamf Pro Release Notes:
Functionality to issue the Tomcat SSL/TLS certificate from Jamf Pro’s built-in certificate authority — Jamf Pro’s functionality to issue the Tomcat SSL/TLS certificate from the JSS built-in certificate authority (CA) will be discontinued in a future release of Jamf Pro. The release version for this change has not been determined.
Before this change occurs, it is recommended that all on-premise Jamf Pro instances leveraging this functionality switch to a publicly trusted third-party CA to issue the Tomcat SSL/TLS certificate. This will prevent the potential loss of MDM communication from Jamf Pro to enrolled devices.
If needed, a Tomcat SSL/TLS server certificate for Jamf Pro may be issued from an internal certificate authority. The JSS built-in CA will maintain its current ability to manually issue server certificates to other servers.
For shops which use Jamf Pro’s built-in certificate authority to create the SSL certificate used by the Tomcat web application, this means that at some point in the near(ish) future, you will need to plan to use a certificate for your Jamf Pro server which is no longer being issued by your Jamf Pro server’s built-in certificate authority.
For more details, please see below the jump.
Session videos from MacDevOps YVR 2021 now available
The MacDevOps YVR folks have posted the session videos for from MacDevOps YVR 2021, including the video for my Ride on the Release Train session.
For those interested, all of the the MacDevOps YVR 2021 session videos are available on YouTube. For convenience, I’ve linked my session here.
Recent Comments