Archive

Archive for the ‘Scripting’ Category

Payload-Free Package Creator 2.4 now available

April 3, 2022 Leave a comment

Payload-Free Package Creator.app, an Automator application that allows the selection of an existing script and then create a payload-free package that runs the selected script, has been updated to version 2.4.

The functionality and operations of the app have not changed from Payload-Free Package Creator 2.3. The main change is that Payload-Free Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Payload-Free Package Creator 2.4, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Payload-Free-Package-Creator

Simple Package Creator 1.5 now available

April 2, 2022 Leave a comment

Simple Package Creator.app, an Automator application that will allow the selection of a self-contained application and creates an installer package that enables the installation of the application with pre-set permissions into /Applications, has been updated to version 1.5.

The functionality and operations of the app have not changed from Simple Package Creator 1.4. The main change is that Simple Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Simple Package Creator 1.5, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Simple-Package-Creator

autopkg-conductor updated to support both JamfUploaderSlacker and Slacker AutoPkg processors

February 12, 2022 Leave a comment

As part of my preparations for Jamf’s planned authentication changes to the Classic API, I’ve been working more with the JamfUploader AutoPkg processors for Jamf Upload. These processors have emerged as a successor to JSSImporter, the original tool available to upload installer packages and other components to Jamf Pro using AutoPkg.

As part of my work with Jamf Upload, I’ve also updated my autopkg-conductor script to allow the use of either Jamf Upload’s JamfUploaderSlacker AutoPkg processor or JSSImporter’s Slacker AutoPkg processors. For more details, please see below the jump.

Read more…

Backing up Self Service icon graphic files from Jamf Pro

January 12, 2022 Leave a comment

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.

Read more…

Updated script for obtaining, checking and renewing Bearer Tokens for the Classic and Jamf Pro APIs

January 5, 2022 8 comments

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:


curl -X POST -u username:password -s https://server.name.here/api/v1/auth/token | plutil -extract token raw –

view raw

gistfile1.txt

hosted with ❤ by GitHub

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


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"]'

view raw

gistfile1.txt

hosted with ❤ by GitHub

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:


/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}"

view raw

gistfile1.txt

hosted with ❤ by GitHub

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:


/usr/bin/curl –write-out %{http_code} –silent –output /dev/null "${jamfpro_url}/api/v1/auth" –request GET –header "Authorization: Bearer ${api_token}"

view raw

gistfile1.txt

hosted with ❤ by GitHub

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:

Screen shot 2022 01 04 at 5 09 20 pm

To this:

Screen Shot 2022 01 05 at 9 43 06 AM

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.

Read more…

Basic Authentication deprecated for the Jamf Pro Classic API

January 4, 2022 7 comments

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.

Screen Shot 2022 01 04 at 11 54 23 AM

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

Screen Shot 2022 01 04 at 11 54 52 AM

For more details, please see below the jump.

Read more…

Obtaining, checking and renewing Bearer Tokens for the Jamf Pro API

December 10, 2021 1 comment

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:


# 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

view raw

gistfile1.txt

hosted with ❤ by GitHub

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:


# 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

view raw

gistfile1.txt

hosted with ❤ by GitHub

Screen Shot 2021-12-10 at 9.39.57 AM

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.

Read more…

Running Jamf Pro actions from outside Jamf Pro

November 1, 2021 2 comments

Every so often, I need to have Jamf Pro perform actions where it’s difficult to arrange the timing and task order I want using the options available from the Jamf Pro server’s end. An example of this would be following an OS upgrade. I want the following:

  • Update the computer inventory record in Jamf Pro as soon as possible that the OS upgrade has occurred.
  • Don’t interfere with any other processes that Jamf Pro may be running at that time.

To address this, I want to use the following workflow:

  1. Make sure the Jamf Pro agent hasn’t run anything for at least the last five minutes.
  2. Enforce the Jamf Pro agent’s management framework
  3. Send the Jamf Pro server an updated inventory.

To run these tasks, I’m using a self-destructing LaunchDaemon and script. For more details, please see below the jump.

Read more…

Silently uninstalling system extensions on macOS Monterey and earlier

October 26, 2021 9 comments

As part of the move from using kernel extensions to system extensions, there is an issue which can be a problem for Mac admins: Uninstalling a system extension from the command line usually involves a GUI window popping up and requesting admin authorization.

Screen Shot 2021 10 26 at 8 25 37 AM

This can be a problem for admins because it requires the logged-in user to:

  • Have admin rights.
  • Understand what the dialog is telling them.
  • Be willing to enter admin credentials when prompted.

For macOS Monterey, this issue has been addressed by the addition of the RemovableSystemExtensions property to the com.apple.system-extension-policy profile payload. This is used to identify system extensions which can be deactivated without requiring admin authorization.

Screen Shot 2021 10 26 at 11 41 26 AM

However, the RemovableSystemExtensions property is new in macOS Monterey and does not apply to macOS Big Sur and earlier. In the past, Mac admins have dealt with this issue through user education, providing warnings like the one shown below, or (in macOS 11.3 and later) removing the profile which authorized the system extension. In the latter case, removing authorization will also unload the system extension.

Screen Shot 2021 10 26 at 8 24 59 AM

However, there is a way to bypass the admin authorization. For more details, please see below the jump.

Read more…

Setting up an ad-hoc TCP listener for connection testing using Python’s web service

September 14, 2021 1 comment

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.

Read more…

Categories: Linux, macOS, Scripting, Unix
%d bloggers like this: