babgond

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:

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:

1. I have an off-server backup for the graphic files.
2. I can track changes to the Self Service policy icons.

To help me manage this, I have a script which does the following:

1. Use the Jamf Pro Classic API to identify which policies are Self Service policies with icons.
2. Download each Self Service icon’s graphic file using the URI for each file.
3. 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.

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

When the script runs, you should see output similar to that shown below.

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

I’ve also included support for using Bearer Tokens for authentication for the Jamf Pro Classic API, which is a feature available on Jamf Pro 10.35.0 and later. This is enabled by default, so the script will try to get a Bearer Token and use it for authentication.

If you’re using this script with Jamf Pro 10.34.2 and earlier, please set the NoBearerToken variable in the script as follows:

NoBearerToken="yes"

This will set the script to use Basic Authentication instead of Bearer Tokens for authentication to the Classic API.

The script is available below, and at the following addresses on GitHub:

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

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:

https://aws.amazon.com/about-aws/whats-new/2022/01/instance-tags-amazon-ec2-instance-metadata-service/

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

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:

For Intel Macs equipped with T2 chips, here are the relevant model identifiers:

For more details, please see below the jump.

To create a smart group that contains the list of all Intel Macs equipped with Secure Enclave, I’ve created the following smart group XML file:

Jamf Pro smart group containing model identifiers for Intel Macs with Secure Enclave:

To narrow down if the Mac has a T1 or T2 chip installed, I also created the following smart group XML files:

Jamf Pro smart group containing model identifiers for Intel Macs with T1 chips:

Jamf Pro smart group containing model identifiers for Intel Macs with T2 chips:

These smart group XML files can be imported into a Jamf Pro server via Jamf’s Classic API. To upload it using the Classic API, download the XML file to a convenient location, then run the command shown below (substituting as appropriate):

For on-premise Jamf Pro servers, this API command will be similar to what’s shown below:

For Jamf Cloud-hosted Jamf Pro servers, this API command will be similar to what’s shown below:

If the smart group was successfully uploaded, you should next see output similar to that shown below:

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:

The command shown below will handle obtaining the token using Basic Authentication on macOS Big Sur and earlier:

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:

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 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.

Please see below for the updated script:

I’ve updated the original script with the corrected API validation check, but otherwise left it unaltered. That script is available below:

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.

For the Classic API, here’s what’s required for authentication using Basic 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 using Basic Authentication:

For the Classic API using Bearer Token authentication, 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 Classic API call process using Bearer Token authentication:

The differences in authentication are significant enough that I’ve written shell scripting functions to handle the following tasks for Bearer Token authentication:

• 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.

Please see the link below for more information on this topic:

https://derflounder.wordpress.com/2021/12/10/obtaining-checking-and-renewing-bearer-tokens-for-the-jamf-pro-api/

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.

When I was planning out this project, I knew I would need certain components:

1. A computer
2. A display
3. A keyboard and mouse
4. An arcade fightstick controller.

For the computer part, I knew I could accomplish my goals using software available for the Raspberry Pi:

• MagicMirror
• RetroPie

However, using a Raspberry Pi meant that I would have to source the Raspberry Pi and display separately. Instead, I decided to look into an older iMac running Ubuntu. When I did my research, I found that the folks at Free Geek in Portland, OR were selling a nearly pristine 2013 21.5 inch iMac with a 250 GB SSD and 16 GBs of RAM for $168.75 on eBay. Even with $60 for shipping, that was cheaper than purchasing a Raspberry Pi 4 and a comparable display.

As an aside, this is the second iMac I’ve bought from the good folks at Free Geek (the first was a 2015 iMac I bought in 2020 for a family member) and what I’ve received has consistently been exactly what I thought I was buying 

So now I had the following:

• Apple iMac 14,1 (21.5″, 2013)
• Processor: 2.7 GHz Quad-Core i5 (I5-4570R)
• Memory: 16 GB RAM
• Storage: 256 GB SSD

However, I wanted to make it simple to switch between the status board and the arcade. Rather than try to manage it all on the same boot drive, I decided to attach two external SSDs, set up a dual-boot configuration and then just start up from the appropriate drive when needed. To accomplish this, I bought two of the following drives:

• PNY Elite USB 3.1 240GB

I only needed enough space for Ubuntu and either the status board or arcade software, so 240 GBS of space was more than enough. Both connected via USB 3 connections, which the iMac supports.

My next component to support the actual computer was a keyboard and mouse. For that, I chose the following:

• Microsoft Wireless All-In-One Media Keyboard

This gave me a compact wireless keyboard with an integrated trackpad which didn’t require drivers. This allowed me to use the keyboard and mouse even when the computer needed to boot to EFI or other conditions where the OS hadn’t fully loaded yet.

The last component I needed was the arcade fightstick controller, which I would use when playing games. The research I did specifically for the Star Wars arcade game indicated that I should get one with a trackball for best results, so after doing more research on fightsticks with integrated trackballs, I chose the following:

• Atari Arcade Fightstick USB Dual Joystick 2 Player Game Controller

After that, I installed the latest version of Ubuntu Desktop LTS, which as of December 2021 meant Ubuntu 20.04.3 LTS, onto both external drives.

Once that was done, I configured GRUB with the following configuration:

• Always boot to boot menu
• Remember the last drive booted from and automatically have it selected in the boot menu
• Wait fifteen seconds, then boot to selected drive

The reason I chose this was that I was planning to set up automated system software updates and pre-authorizing reboots if needed by a software update. By configuring GRUB to remember the last drive booted from and booting from it after 15 seconds, that would allow the software update process to happen normally even if a reboot was needed. Meanwhile, fifteen seconds should be more than enough time to me to choose another drive if I’m sitting in front of the Mac.

Now I had Ubuntu installed on two separate boot drives and could set them up as desired. Now I needed to configure each separately according to their function:

Status Board

For the status board Ubuntu boot drive, I installed MagicMirror to drive the status board. The instructions I followed to install and configure MagicMirror are available via the links below:

• https://docs.magicmirror.builders/getting-started/installation.html#manual-installation
• https://docs.magicmirror.builders/configuration/introduction.html
• https://docs.magicmirror.builders/configuration/autostart.html#using-pm2

More information about installing and configuring MagicMirror on Ubuntu is available via the link below:

• https://github.com/iamjprince/MagicMirror-Ubuntu

Arcade

For the arcade Ubuntu boot drive, I installed RetroPie. The instructions I followed to install and configure RetroPie are available via the links below:

• https://retropie.org.uk/docs/Debian/

I wanted to set RetroPie (otherwise known as EmulationStation) to start up at boot, so I followed the directions available via the link below to configure the Start EmulationStation at Boot setting:

• https://retropie.org.uk/docs/FAQ/#how-do-i-boot-to-the-desktop-or-kodi

The last part was configuring my Atari Arcade Fightstick to correctly work with Ubuntu. By default, the RetroPie software will only see the fightstick’s one set of controls and not both. To fix this, you need to set the following setting for the Atari Arcade Fightstick:

usbhid.quirks=0x16c0:0x05e1:0x040

To improve the trackball performance, you also need to set the following setting:

usbhid.mousepoll=1

However, where you set this setting is going to be different between Ubuntu (which I’m using) and RetroPie on a Raspberry Pi (which most other folks are using.) For a Raspberry Pi, you should set these settings in the following file:

/boot/cmdline.txt

For Ubuntu, these need to be added to the GRUB_CMDLINE_LINUX_DEFAULT line of your GRUB configuration, as shown below:

GRUB_CMDLINE_LINUX_DEFAULT="usbhid.quirks=0x16c0:0x05e1:0x040 usbhid.mousepoll=1 quiet splash"

In the context of the overall GRUB configuration, it looks like this:

In the end, I’m pretty happy with the end result. Here’s a look at the status board running MagicMirror and the MagicMirror modules which I configured:

Here’s a look at RetroPie up and running:

Last but not least, playing the Star Wars arcade game:

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:

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.

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:

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.

The folks at Jamf jumped on this issue and they’ve put together a list of how this affects their products which use the log4j logging tool:

To summarize, Jamf found that the main product which was vulnerable was Jamf Pro. To protect Jamf Cloud-hosted instances, Jamf was able to implement security controls on their end to mitigate the vulnerability. These controls allowed Jamf to block remote attempts to use the vulnerability without needing to upgrade everyone to a new version of Jamf Pro.

For folks hosting their own Jamf Pro instances, Jamf has released Jamf Pro 10.34.1. For folks in a position to upgrade, upgrading to Jamf Pro 10.34.1 is the best answer. This version of Jamf Pro includes the fixed 2.15.0 version of log4j and installs the following files:

• 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

These files are located in the following directories on platforms which support running Jamf Pro Server:

• Linux:
  • /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/lib/

• Windows:
  • C:\Program Files\JSS\Tomcat\webapps\ROOT\WEB-INF\lib\

• macOS:
  • /Library/JSS/Tomcat/webapps/ROOT/WEB-INF/lib/

If for some reason it is not possible to upgrade to Jamf Pro 10.34.1 at this time and your Jamf Pro Server is not hosted in Jamf Cloud, it is also possible to mitigate the vulnerability by manually copying the updated version of the log4j tools into place. Jamf has a technical article posted which describes this process. If you are not able to upgrade to 10.34.1 and you’re hosting Jamf Pro outside of Jamf Cloud, I strongly recommend following this article to get the updated log4j.jar files in place as soon as possible.

Note: Something very important to know is that these logging tools are replaced as part of a normal Jamf Pro upgrade, so if you’re not upgrading to Jamf Pro 10.34.1 or later, this fix would need to be re-applied for each upgrade.

If you’re upgrading from an older version of Jamf Pro and need to upgrade to certain vulnerable versions along the way to getting to the latest version, you will need to repeat manually re-adding the non-vulnerable log4j.jar files as part of each upgrade.

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:

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:

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.

I’ve written a script which includes the four functions listed below:

• GetJamfProAPIToken: Obtains the Bearer Token using the username and password of a Jamf Pro account.
• APITokenValidCheck: Runs an API call using the current Bearer Token which displays the authorization details associated with the current API user. The API call will only return the HTTP status code.
• CheckAndRenewAPIToken: Uses APITokenValidCheck to verify if the current Bearer Token is valid by checking the HTTP status code. If it is, the current Bearer Token will be used to get a new Bearer Token. If not, GetJamfProAPIToken is run to get a new Bearer Token using the username and password of a Jamf Pro account.
• InvalidateToken: Uses APITokenValidCheck to verify if the current Bearer Token is valid by checking the HTTP status code. If it is, the current Bearer Token will be used to invalidate itself.

invisible invisible

invisible invisible

Update – 1-5-2022: Updated script is available via the link below:

https://derflounder.wordpress.com/2022/01/05/updated-script-for-obtaining-checking-and-renewing-bearer-tokens-for-the-classic-and-jamf-pro-apis

invisible invisible

invisible invisible

The script is available below: