Setting up an ad-hoc TCP listener for connection testing using Python’s web service
I recently needed to set up a connection test so that an outside vendor could verify that firewall rules had been set up correctly on both ends and that a connection which originated at a specific IP address on the vendor’s end was able to resolve a DNS address on our end and make a connection.
I remembered that Python has a simple way to set up a web server, so I decided to use this to create a script which creates a connection listener by setting up a web server on the desired port. For more details, please see below the jump.
Setting up software deployment groups using a Jamf Pro Extension Attribute
When setting up software for deployment, it’s usually a good idea to first send it out to a small percentage of the Macs in your environment. That way, if there’s a problem that wasn’t caught in testing, the amount of cleanup required is also small. If that initial deployment works, the software can then be sent out to greater percentages of the Mac population until all of them are eventually covered by the deployment.
This can be a pain to track manually though. New Macs come in, older ones are retired and keeping all Macs covered can turn into a significant investment of time. Fortunately, this is a task which can be automated and enable the Macs to assign themselves to deployment groups based on their machine UUID identifier. For more details, please see below the jump.
Identifying an AWS RDS-hosted database by its tag information
Recently, I was working on a task where I wanted to set up an automated process to create manual database snapshots for a database hosted in Amazon’s RDS service. Normally this is a straightforward process because you can use the database’s unique identifier when requesting the database snapshot to be created.
However in this case, the database was being created as part of an Elastic Beanstalk configuration. This meant that there was the potential for the database in question to be removed from RDS and a new one set up, which meant a new unique identifier for the database I wanted to create manual database snapshots from.
The Elastic Beanstalk configuration does tag the database, using a Name tag specified in the Elastic Beanstalk configuration, so the answer seemed obvious: Use the tag information to identify the database. That way, even if the database identifier changed (because a new database had been created), the automated process could find the new database on its own and continue to make snapshots.
One hitch: Within the AWS API, RDS lists only the following three API calls to interact with tags.
ListTagsForResource would seem to be the answer, but the hitch there is that you have to have the database’s Amazon Resource Name (ARN) identifier available first and then use that to list the tags associated with the database:
aws rds add-tags-to-resource --resource-name arn:aws:rds:us-east-1:123456789102:db:dev-test-db-instance --tags Key=Name
I was coming at it from the other end – I wanted to use the tag information to find the database. RDS’s API doesn’t support that.
Fortunately, the RDS API is not the only way to read tags from an RDS database. For more details, please see below the jump.
Using the Jamf Pro API to report on which Macs are assigned to a particular person
Every so often, it may be necessary to generate a report from Jamf Pro on which computers are assigned to a particular person. To assist with this task, I’ve written a script which uses the Jamf Pro Classic API to search through the computer inventory records and generate a report in .tsv format.
For more details, please see below the jump.
Codesigning, untrusted certificate authorities and why certain apps aren’t launching
A number of folks noticed that certain older applications they use on macOS stopped working as of August 24th, 2021. As of this date, this appears to affect the following applications among others:
Note: This list is not complete, it’s just the ones I’m aware of as of August 24, 2021.
Why this is happening goes back to an episode in 2018, where Symantec had to get out of the PKI certificate issuing business because of a number of issues discovered with how Symantec had been issuing certificates.
As part of these issues, Apple issued an advisory that a number of Symantec Certificate Authority (CA) root certificates were to be distrusted by Apple on a timeline which concluded with the full distrust of Symantec CAs on February 25, 2020.
While this primarily affected website operators, Symantec also issued certificates from the affected Symantec CAs which were used to provide code signing for applications. An example of this is RSA SecurID Software Token 4.2.1.
Update 8-26-2021: RSA has released RSA SecurID Software Token 4.2.2 to resolve the issue with RSA SecurID Software Token 4.2.1. For more details, please see the link below:
In the case of SecureID, this app relies on Qt Core for user interface support and ships copies of the QT Core framework along with the SecureID app. SecurID stores this in the following location:
/Library/Frameworks/stauto32.framework
If you take a look at the installer, you can see where the files are supposed to go.
However, the actual file which is causing the issue is buried further down in the following location:
/Library/Frameworks/stauto32.framework/Versions/4/QtCore.cire
This file is important because the QT Core framework is shipped without Apple’s code signing, which is to say that QT is not using an Apple Developer ID signing certificate to sign QT Core. Instead, QT ships a code signing certificate chain and that information is stored in the QtCore.cire file.
One of the certificates in the code signing certificate chain is using VeriSign Class 3 Public Primary Certification Authority – G5 as its root certificate authority (root CA). That root CA is one of the Symantec CAs which is no longer trusted by Apple.
To summarize: the SecureID app has a component which is signed by a not-trusted certificate. This is causing SecureID to not trust that component, which then prevents the app from launching correctly.
Why is this happening now?
Apple released updates on August 23, 2021 for both XProtect (now version 2150) and Malware Removal Tool (now version 1.82). My assumption is that XProtect’s update included instructions to no longer accept code signing from the distrusted Symantec CAs. XProtect checks executable code on launch, so it would be working with Gatekeeper to detect and block the no-longer-trusted code signing.
What should you do?
See if your vendor has released an updated version of the app which is having problems. If they haven’t yet, I recommend contacting them to make sure they’re aware of the problem.
Hat tip to all the folks working on this issue in the MacAdmins Slack for helping diagnose the issue and why it is happening.
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.
Recent Comments