Archive

Archive for the ‘Jamf Pro API’ Category

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…

Using the Jamf Pro API to report on which Macs are assigned to a particular person

August 26, 2021 Leave a comment

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.

Read more…

Updated Jamf Pro MDM lock script to add reporting feature

June 1, 2021 1 comment

Previously, I’d written a script to manage sending device lock commands using the Jamf Pro Classic API. After writing it, I thought that it would be a good idea if the script could also generate a report that could be handed off to others so I forked the script and updated it to generate a report in .tsv format. Since others might prefer the original script without the automatically generated report, I left that one alone and have made the forked copy into its own script. For more details, please see below the jump.

Read more…

Using the Jamf Pro API to send device lock commands via MDM to multiple Macs

May 28, 2021 2 comments

Most Mac admins have had this conversation at one point or another over the course of their careers:

“$Very Important Person left their Mac behind in a cab! What do we do?”
“OK, no worries. We can send a command to lock the computer or have it erase itself. Do you want it locked or wiped?”

At that point, the admin pulls up their MDM admin console and depending on what the response was (lock or wipe), send out the appropriate MDM command accompanied by a PIN code. Once received, the Mac will then turn itself into a paperweight which does or doesn’t erase itself.

Doing these one at a time is a pretty straightforward process. For example, here’s how it looks in Jamf Pro to send a device lock command via MDM:

1. Log into Jamf Pro using an account which can send lock commands via MDM.
2. Go to the appropriate computer inventory record.

Screen Shot 2021 05 28 at 2 48 00 PM

3. Select the Management tab.

Screen Shot 2021 05 28 at 2 48 01 PM

4. In the Management Commands section of the Management tab, click the Lock Computer button.

Screen Shot 2021 05 28 at 1 57 43 PM

5. Enter the PIN code which will later be used to unlock the Mac. If desired, you can also enter a message which will appear on the lock screen.

Screen Shot 2021 05 28 at 1 58 56 PM

6. Click the Lock Computer button.

Screen Shot 2021 05 28 at 1 58 57 PM

7. Click the OK button in the confirmation window.

Screen Shot 2021 05 28 at 1 59 42 PM

 

Once the device lock command has been sent, the Lock Computer button’s text should temporarily change to Command Sent.

Screen Shot 2021 05 28 at 1 59 49 PM

 

For a small number of machines (10 or less), the method outlined above works fine. But once you get beyond that number, this process gets time-consuming and unwieldy. Fortunately, there is also a way to use the Jamf Pro Classic API to send device lock commands. For more details, please see below the jump.

Read more…

Workaround for timeouts when deleting installer packages from Jamf Pro

April 22, 2021 Leave a comment

I use AutoPkg and JSSImporter to keep my Jamf Pro server updated with the latest installers for the software used by my shop. However, this means that I usually have a large number of no-longer-needed installers stored in my Jamf Pro server’s distribution point and I need to periodically clear the obsolete packages out by deleting them. Recently, as part of removing 500+ unneeded packages from Jamf Pro using a script, I noticed the following behavior occurring:

1. Run an API command similar to the one below:

username@computername ~ % /usr/bin/curl -su username:'password' "https://jamf.pro.server.here/JSSResource/packages/id/1213" -X DELETE

2. Long pause (around 60 seconds)
3. Receive the following output:

<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>

4. Check the package and it has been deleted from Jamf Pro.

The 504 Gateway Time-out error indicated that either the load balancer in front my Jamf Pro server was timing out before the API command could report success or failure. I was seeing this behavior when running the API commands manually or as part of a script, so I decided to see if I saw the same behavior when deleting the package from the Jamf Pro admin console. When I checked, I did.

I sent in a support request to Jamf to ask about this and there is a PI open for this:

PI-009627: Having a large amount of packages uploaded to a distribution point can cause various timeouts

For others experiencing this issue, while Jamf addresses this product issue, the workaround for the timeout issue is (if possible) to increase the timeout value. In my case, increasing the load balancer timeout from 60 seconds to 120 addressed the timeout issue and allowed my API and GUI package deletions to complete successfully without timing out.

Note: This does not fix the issue of the package deletion taking a while. It just makes sure that the deletion command, either via the API or using the GUI in the admin console, doesn’t timeout before reporting success or failure.

Categories: Jamf Pro, Jamf Pro API

Using the Jamf Pro API to mass-delete obsolete packages and scripts

April 16, 2021 2 comments

If you’re using AutoPkg and tools like jamf-upload or JSSImporter to automate the uploading of packages and scripts to your Jamf Pro server, it may be necessary to periodically delete a large number of now-obsolete installer packages or scripts from your server. To help with this, I’ve written a couple of scripts to help automate the deletion process by using a list of Jamf IDs and the API to perform the following tasks:

  1. Delete the relevant installer packages or scripts.
  2. Generate a report of which packages or scripts were deleted.

For more details, please see below the jump.

Read more…

Clearing failed MDM commands on Jamf Pro

September 25, 2020 Leave a comment

For a variety of reasons, MDM commands sent out from an MDM server can fail to run correctly on a Mac. Many times, these MDM commands will not be re-sent unless the failure is cleared. With the failure cleared, the MDM server will not have a record of sending the MDM command and should try again.

On Jamf Pro, there’s a couple of ways you can clear failed MDM commands. The first is a manual process which uses the Jamf Pro admin console. The second uses the Jamf Pro Classic API and can be automated. For more details, please see below the jump.

Read more…

%d bloggers like this: