Jamf Pro server installer for macOS retirement planned for March 2022
To follow up on my earlier post on the Jamf Pro Server Installer for macOS being retired, Jamf has added the following to the Deprecations and Removals section of the Jamf Pro 10.35.0 release notes:
Support ending for the Jamf Pro Server Installer for macOS—Support for using the Jamf Pro Installer for macOS will be discontinued in a future release (estimated removal date: March 2022). Mac computers with Apple silicon are not supported by the Jamf Pro Installer for macOS. If you want to migrate your Jamf Pro server from macOS to Jamf Cloud, contact Jamf Support via Jamf Account. If you want to keep your server on premise, you can migrate your Jamf Pro server from macOS to one of the following servers: Red Hat Enterprise Linux, Ubuntu, or Windows. For more information, see the Migrating to Another Server article.
For those folks who are running on-premise Jamf Pro servers on Macs, I strongly recommend contacting Jamf Support and plan a migration if you haven’t already. As of January 14th, 2022, Jamf’s published support for running Jamf Pro includes the following OS, database and Java versions:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Recommended Configuration: | |
| Operating Systems: | |
| Windows Server 2019 | |
| Ubuntu Server 20.04 LTS | |
| Red Hat Enterprise Linux 7.x | |
| Database software versions: | |
| MySQL 8.0 – InnoDB | |
| Amazon Aurora (MySQL 5.7 compatible) | |
| MySQL 5.7.13 or later – InnoDB | |
| Java version: | |
| OpenJDK 11 | |
| Minimum Supported: | |
| Operating Systems: | |
| Windows Server 2016 | |
| Windows Server 2012 R2 | |
| Ubuntu Server 18.04 LTS | |
| macOS 10.15 | |
| macOS 10.14 | |
| Database software versions: | |
| MySQL 5.7.13 – InnoDB | |
| MySQL 5.7.13 on Amazon RDS – InnoDB | |
| Java version: | |
| Oracle Java 11 |
Backing up Self Service icon graphic files from Jamf Pro
While working with Self Service policies on Jamf Pro, I prefer to download the graphic files used for the Self Service icons and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:
- I have an off-server backup for the graphic files.
- I can track changes to the Self Service policy icons.
To help me manage this, I have a script which does the following:
- Use the Jamf Pro Classic API to identify which policies are Self Service policies with icons.
- Download each Self Service icon’s graphic file using the URI for each file.
- Save the downloaded graphics file to a specified download directory, using a filename format like shown below:
policy_name_here-jamf_pro_policy_id_here-graphics_file_name_here
As part of the download process, any spaces are removed from the graphic file’s file names and the policy names. Any colons ( : ) are likewise replaced with dashes ( – ) to prevent problems for the macOS filesystem.
For more details, please see below the jump.
Amazon Web Services’s new EC2 metadata tag option doesn’t allow spaces in tag names
Beginning on January 6th, Amazon Web Services added a new option to include your instance’s tags as part of the instance’s metadata when the instance is launched:
By including this data in the instance metadata, this information no longer needs the DescribeInstances or DescribeTags API calls to retrieve tag information. For shops which use tag information extensively, this will cut down on the number of API calls you need to make and allow tag retrieval to scale better.
There is one limitation: tags stored in metadata cannot have spaces. If you have the “tags in metadata” option enabled and you have a tag with spaces in it, you’ll see a message similar to the one below:
‘Tag Name Here’ is not a valid tag key. Tag keys must match pattern ([0-9a-zA-Z-_+=,.@:]{1,255}), and must not be a reserved name (‘.’, ‘..’, ‘_index’)
This was an issue for me yesterday because I’m using AWS’s Patch Manager to keep my instances updated and that uses the following tag:
Patch Group
This tag must be used by patching groups and is referenced in the documentation this way:
Patch groups require use of the tag key Patch Group. You can specify any tag value, but the tag key must be Patch Group.
https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-group-tagging.html
The result was that I set up a new instance yesterday with my tags, including the Patch Group tag, and received the following message when I tried to launch the instance:
‘Patch Group’ is not a valid tag key. Tag keys must match pattern ([0-9a-zA-Z-_+=,.@:]{1,255}), and must not be a reserved name (‘.’, ‘..’, ‘_index’)
I put in a ticket to AWS Support and the fix is the following:
When setting up new EC2 instances, make sure that the Allow tags in metadata setting under the Advanced Details section is set to Disabled.
This turns off including your instance’s tags with the instance’s metadata as part of the instance’s launch. This addresses the issue because tag information will not be added to your instance’s metadata and thus removes the metadata tagging limitations from the instance creation process. Now your tags can include spaces again, though you’re also back to having to retrieve tag information via the API.
On Monday, January 10th 2022, the Allow tags in metadata setting was set to Enabled by default. However, I suspect AWS got enough support calls about this particular issue that they made a change to the default settings. As of Tuesday, January 11th 2022, the Allow tags in metadata setting is now set to Disabled by default.
Identifying Intel Macs with Secure Enclave using Jamf Pro
Identifying Intel Macs with Secure Enclave using Jamf Pro
As part of a recent task, I needed to identify using Jamf Pro which Macs in our environment have Secure Enclave and which Macs do not. For Intel Macs, having Secure Enclave means that you have one of the following Macs:
Macs with the Apple T1 Security Chip
- MacBook Pro (13-inch with Touch Bar, Late 2016)
- MacBook Pro (15-inch with Touch Bar, Late 2016)
- MacBook Pro (13-inch with Touch Bar, Mid-2017)
- MacBook Pro (15-inch with Touch Bar, Mid-2017)
Macs with the Apple T2 Security Chip
- iMac (Retina 5K, 27-inch, 2020)
- iMac Pro
- Mac Pro (2019)
- Mac Pro (Rack, 2019)
- Mac mini (2018)
- MacBook Air (Retina, 13-inch, 2020)
- MacBook Air (Retina, 13-inch, 2019)
- MacBook Air (Retina, 13-inch, 2018)
- MacBook Pro (13-inch, 2020, Two Thunderbolt 3 ports)
- MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports)
- MacBook Pro (16-inch, 2019)
- MacBook Pro (13-inch, 2019, Two Thunderbolt 3 ports)
- MacBook Pro (15-inch, 2019)
- MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports)
- MacBook Pro (15-inch, 2018)
- MacBook Pro (13-inch, 2018, Four Thunderbolt 3 ports)
Jamf Pro doesn’t have a specific “this Mac has Secure Enclave” inventory identifier, so I decided to use Apple’s documentation on which Intel Mac models have Secure Enclave to build Jamf Pro smart groups with model identifiers. With Apple’s move to Apple Silicon processors, this list of models should not be added to in the future.
For Intel Macs equipped with T1 chips, here are the relevant model identifiers:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| MacBookPro13,2 | |
| MacBookPro13,3 | |
| MacBookPro14,2 | |
| MacBookPro14,3 |
For Intel Macs equipped with T2 chips, here are the relevant model identifiers:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| iMac20,1 | |
| iMacPro1,1 | |
| MacPro7,1 | |
| Macmini8,1 | |
| MacBookAir8,1 | |
| MacBookAir8,2 | |
| MacBookAir9,1 | |
| MacBookPro15,1 | |
| MacBookPro15,2 | |
| MacBookPro15,3 | |
| MacBookPro15,4 | |
| MacBookPro16,1 | |
| MacBookPro16,2 | |
| MacBookPro16,3 | |
| MacBookPro16,4 |
For more details, please see below the jump.
Updated script for obtaining, checking and renewing Bearer Tokens for the Classic and Jamf Pro APIs
Following my earlier posts on obtaining, checking and renewing Bearer Tokens for the Jamf Pro API and the deprecation of Basic Authentication for the Jamf Pro Classic API, @bryson3gps reached out to let me know there was a simpler way to get the Bearer Token which didn’t require the prior encoding of the username and password credentials in base64 format.
The command shown below will handle obtaining the token using Basic Authentication on macOS Monterey and later:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| curl -X POST -u username:password -s https://server.name.here/api/v1/auth/token | plutil -extract token raw – |
The command shown below will handle obtaining the token using Basic Authentication on macOS Big Sur and earlier:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| curl -X POST -u username:password -s https://server.name.here/api/v1/auth/token | python -c 'import sys, json; print json.load(sys.stdin)["token"]' |
This allows the following functions to be collapsed into one command:
- Encoding the username and password in base64 format
- Obtaining a Bearer Token using Basic Authentication
- Storing the Bearer Token (if command is used in a variable.)
He also pointed out that I was using an incorrect API call for the validation check which uses HTTP status codes. What I had:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| /usr/bin/curl –write-out %{http_code} –silent –output /dev/null "${jamfpro_url}/api/v1/auth/keep-alive" –request POST –header "Authorization: Bearer ${api_token}" |
While this worked, it was using the keepalive endpoint with a POST request, which is used to invalidate tokens and issue new ones. I’ve updated to use this instead:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| /usr/bin/curl –write-out %{http_code} –silent –output /dev/null "${jamfpro_url}/api/v1/auth" –request GET –header "Authorization: Bearer ${api_token}" |
This API call sends a GET request to the auth endpoint, which returns all the authorization details associated with the current Bearer Token. This will work for the validation check and won’t trigger accidental invalidation of the existing Bearer Token.
With this in mind, the process of obtaining Bearer Tokens is now simplified. This affects the deprecation of the Classic API for Jamf Pro 10.35.0 and later by changing the workflow from this:
To this:
I’ve incorporated these changes into an updated script with functions for obtaining, checking and renewing Bearer Tokens for the Classic (for Jamf Pro 10.35.0 and later) and Jamf Pro APIs. For more details, please see below the jump.
Basic Authentication deprecated for the Jamf Pro Classic API
As part of the release of Jamf Pro 10.35, the following note was added to the Deprecations and Removals section of the Jamf Pro 10.35.0 Release Notes:
Basic authentication — Jamf will discontinue support for Basic authentication in the Classic API in a future release of Jamf Pro (estimated removal date: August-December 2022) for enhanced security. Jamf will provide additional information at a later date. To disable Basic authentication before support is removed, contact Jamf Support via Jamf Account.
To help folks prepare for this change, as of Jamf Pro 10.35.0, both Basic Authentication and using Bearer Tokens generated by the Jamf Pro API can be used for Jamf Pro Classic API authentication. This is noted in the New Features and Enhancements section of the Jamf Pro 10.35.0 release notes:
You can now use the Classic API to authenticate using Basic authentication or a Bearer Token retrieved through the /v1/auth/token Jamf Pro API endpoint for enhanced security. For information on Bearer Token authentication, see the Jamf developer resources: https://developer.jamf.com/jamf-pro/docs/classic-api-authentication-changes
For more details, please see below the jump.
2021 Holiday Vacation Project
Like a lot of folks, I took some time off around the holidays. Before then, I decided I wanted to accomplish a couple of things while I was off.
- Goal 1: Set up a personal status board for my office, where at a glance I could find useful information.
- Goal 2: Figure out how to be able to play the Star Wars arcade game whenever I wanted to.
I’m happy to say that I was able to accomplish my goal by December 31st, 2021. For more details, please see below the jump.
Preventing user and location inventory information from being changed by the jamf binary’s recon verb
You can allow or prevent local administrators on the computer from changing User and Location inventory information in Jamf Pro with the jamf binary by using the Allow local administrators to use the jamf binary recon verb to change User and Location inventory information in Jamf Pro checkbox. This is a feature which first appeared in Jamf Pro 10.20.x, but may not be well known.
This setting is enabled by default and can be configured by navigating to Settings > Computer Management > Inventory Collection in Jamf Pro.
What this setting affects are the following options associated with the jamf binary’s recon verb:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| -endUsername | |
| -realname | |
| -position | |
| -building | |
| -department | |
| -phone | |
| -room |
Why disable this setting? If you have workflows which leverage the user and location information stored in Jamf Pro, being able to change this setting from a managed Mac using the jamf binary’s recon verb may have security implications. In particular, PKI certificate authorities set up in Jamf Pro may use the user and location information stored in Jamf Pro to issue certificates to managed Macs.
In the context of certificates used for authentication, being able to change the user and location stored in Jamf Pro from the managed Mac’s end may mean that an enduser with the ability to run the jamf binary’s recon verb may be able to get authentication certificates for someone other than themselves assigned to their Mac.
If you do not have any workflows that use the recon verb’s options specified above, my advice is that you disable this setting and remove the ability of managed Macs to change the user and location information stored in Jamf Pro using the jamf binary’s recon verb.
Remediating Log4Shell on Jamf Pro
On Thursday, December 9th 2021, a vulnerability was discovered in the popular Java logging library (log4j) which allowed for Remote Code Execution (RCE) by logging a certain string. This vulnerability has been dubbed Log4shell:
How bad is this? I’ll let the below video of a Minecraft server being changed into a DOOM server via this vulnerability speak to how a remote attacker could use Log4shell to give you a bad day:
It’s bad. It’s hard to overstate how bad. My colleague Ben Toms has a good write up on this issue here:
https://macmule.com/2021/12/11/jamf-pro-and-log4shell-cve-2021-44228
To address this vulnerability, the log4j folks have released an updated version of the logging tool which is not vulnerable. It’s log4j 2.1.5 and is available for download via the link below:
https://logging.apache.org/log4j/2.x/download.html
Update 12-15-2021:
Log4j 2.16.0 has been released to address remaining vulnerabilities in 2.15.0 by completely disabling Java Naming and Directory Interface (JNDI) lookups by default. It can be downloaded via the link below:
https://logging.apache.org/log4j/2.x/download.html
Insecure JNDI lookups are what enable the Log4Shell vulnerability, so having JNDI disabled by default in addition to 2.16.0’s removal of its message lookups functionality fixes the vulnerability .
Jamf has stated that they have evaluated CVE-2021-45046, which prompted the release of 2.16.0, and the results of their evaluation are that it does not appear that the conditions which are covered by CVE-2021-45046 should occur with Jamf’s products.
As of December 15th 2021, Jamf has not provided guidance on updating from log4j 2.15.0 to log4j 2.16.0
The files to download are one of the following two:
- Apache log4j 2 binary (tar.gz)
- Apache log4j 2 binary (zip)
Both have the same contents, the main difference is how they are compressed. Once downloaded and uncompressed, you should have the following files:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| LICENSE.txt | |
| NOTICE.txt | |
| RELEASE-NOTES.md | |
| log4j-1.2-api-2.15.0-javadoc.jar | |
| log4j-1.2-api-2.15.0-sources.jar | |
| log4j-1.2-api-2.15.0.jar | |
| log4j-api-2.15.0-javadoc.jar | |
| log4j-api-2.15.0-sources.jar | |
| log4j-api-2.15.0.jar | |
| log4j-appserver-2.15.0-javadoc.jar | |
| log4j-appserver-2.15.0-sources.jar | |
| log4j-appserver-2.15.0.jar | |
| log4j-cassandra-2.15.0-javadoc.jar | |
| log4j-cassandra-2.15.0-sources.jar | |
| log4j-cassandra-2.15.0.jar | |
| log4j-core-2.15.0-javadoc.jar | |
| log4j-core-2.15.0-sources.jar | |
| log4j-core-2.15.0-tests.jar | |
| log4j-core-2.15.0.jar | |
| log4j-couchdb-2.15.0-javadoc.jar | |
| log4j-couchdb-2.15.0-sources.jar | |
| log4j-couchdb-2.15.0.jar | |
| log4j-docker-2.15.0-javadoc.jar | |
| log4j-docker-2.15.0-sources.jar | |
| log4j-docker-2.15.0.jar | |
| log4j-flume-ng-2.15.0-javadoc.jar | |
| log4j-flume-ng-2.15.0-sources.jar | |
| log4j-flume-ng-2.15.0.jar | |
| log4j-iostreams-2.15.0-javadoc.jar | |
| log4j-iostreams-2.15.0-sources.jar | |
| log4j-iostreams-2.15.0.jar | |
| log4j-jcl-2.15.0-javadoc.jar | |
| log4j-jcl-2.15.0-sources.jar | |
| log4j-jcl-2.15.0.jar | |
| log4j-jdbc-dbcp2-2.15.0-javadoc.jar | |
| log4j-jdbc-dbcp2-2.15.0-sources.jar | |
| log4j-jdbc-dbcp2-2.15.0.jar | |
| log4j-jmx-gui-2.15.0-javadoc.jar | |
| log4j-jmx-gui-2.15.0-sources.jar | |
| log4j-jmx-gui-2.15.0.jar | |
| log4j-jpa-2.15.0-javadoc.jar | |
| log4j-jpa-2.15.0-sources.jar | |
| log4j-jpa-2.15.0.jar | |
| log4j-jul-2.15.0-javadoc.jar | |
| log4j-jul-2.15.0-sources.jar | |
| log4j-jul-2.15.0.jar | |
| log4j-liquibase-2.15.0-javadoc.jar | |
| log4j-liquibase-2.15.0-sources.jar | |
| log4j-liquibase-2.15.0.jar | |
| log4j-mongodb3-2.15.0-javadoc.jar | |
| log4j-mongodb3-2.15.0-sources.jar | |
| log4j-mongodb3-2.15.0.jar | |
| log4j-mongodb4-2.15.0-javadoc.jar | |
| log4j-mongodb4-2.15.0-sources.jar | |
| log4j-mongodb4-2.15.0.jar | |
| log4j-slf4j-impl-2.15.0-javadoc.jar | |
| log4j-slf4j-impl-2.15.0-sources.jar | |
| log4j-slf4j-impl-2.15.0.jar | |
| log4j-slf4j18-impl-2.15.0-javadoc.jar | |
| log4j-slf4j18-impl-2.15.0-sources.jar | |
| log4j-slf4j18-impl-2.15.0.jar | |
| log4j-spring-boot-2.15.0-javadoc.jar | |
| log4j-spring-boot-2.15.0-sources.jar | |
| log4j-spring-boot-2.15.0.jar | |
| log4j-spring-cloud-config-client-2.15.0-javadoc.jar | |
| log4j-spring-cloud-config-client-2.15.0-sources.jar | |
| log4j-spring-cloud-config-client-2.15.0.jar | |
| log4j-taglib-2.15.0-javadoc.jar | |
| log4j-taglib-2.15.0-sources.jar | |
| log4j-taglib-2.15.0.jar | |
| log4j-to-slf4j-2.15.0-javadoc.jar | |
| log4j-to-slf4j-2.15.0-sources.jar | |
| log4j-to-slf4j-2.15.0.jar | |
| log4j-web-2.15.0-javadoc.jar | |
| log4j-web-2.15.0-sources.jar | |
| log4j-web-2.15.0.jar |
The ones relevant to Jamf Pro are the following:
- log4j-1.2-api-2.15.0.jar
- log4j-api-2.15.0.jar
- log4j-core-2.15.0.jar
- log4j-slf4j-impl-2.15.0.jar
For more details, please see below the jump.
Obtaining, checking and renewing Bearer Tokens for the Jamf Pro API
I’ve recently begun looking into uses for the Jamf Pro API, the API which Jamf makes available for Jamf Pro in addition to the Classic API. The two APIs handle authentication differently and for folks coming over to using the Jamf Pro API from the Classic API, the extra steps involved may be a surprise.
For the Classic API, here’s what’s required for authentication:
- One step process.
- Only username and password needed to authenticate an API call.
- Username and password can be in plaintext.
- No tokens are used.
Example Classic API call process:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Provide username and password as part of the API call: | |
| /usr/bin/curl -su username_here:password_here" -H "Accept: application/xml" https://server.name.here/JSSResource/packages/id/2 |
For the Jamf Pro API, here’s what’s required for authentication:
- Multi-step process involving multiple API calls.
- Username and password only used to get authentication token, known as a Bearer Token. The Bearer Token is subsequently used for authentication.
- Username and password must be base64-encoded.
- Bearer Tokens are valid for 30 minutes maximum.
- Introduces need to validate authentication Bearer Tokens before making an API call.
Example Jamf Pro API call process:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Get username and password encoded in base64 format and stored as a variable in a script: | |
| encodedCredentials=$(printf username_here:password_here | /usr/bin/iconv -t ISO-8859-1 | /usr/bin/base64 -i -) | |
| # Use encoded username and password to request a token with an API call and store the output as a variable in a script: | |
| authToken=$(/usr/bin/curl https://server.name.here/api/v1/auth/token –silent –request POST –header "Authorization: Basic ${encodedCredentials}”) | |
| # Read the output, extract the token information and store the token information as a variable in a script: | |
| api_token=$(/usr/bin/plutil -extract token raw -o – – <<< “$authToken”) | |
| # Verify that the token is valid and unexpired by making a separate API call, checking the HTTP status code and storing status code information as a variable in a script: | |
| api_authentication_check=$(/usr/bin/curl –write-out %{http_code} –silent –output /dev/null https://server.name.here/api/v1/auth –request GET –header "Authorization: Bearer ${api_token}") | |
| #Assuming token is verified to be valid, use the token information to make an API call: | |
| /usr/bin/curl –silent -H "Accept: application/xml" –header "Authorization: Bearer ${api_token}" https://server.name.here/JSSResource/packages/id/2 |
The differences in authentication are significant enough that I decided to write functions for shell scripting to handle the following tasks for the Jamf Pro API:
- Obtaining Bearer Token.
- Verifying that current Bearer Token is valid and unexpired.
- Renewing Bearer Tokens by using current Bearer Token to authenticate the issuing of a new Bearer Token. (This renewal process creates a new Bearer Token and invalidates the old Bearer Token.)
- Invalidating current Bearer Token.
For more details, please see below the jump.
Der Flounder 
Recent Comments