• The current list of the Jamf Pro user accounts on a Jamf Pro server
• The permissions assigned to those user accounts
• Whether those permissions are assigned directly to the account, or if they are permissions assigned to the account because it is a member of a Jamf Pro user group.

For more details, please see below the jump.

The script is named Jamf_Pro_Local_Account_Permissions_Report.sh and is available via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_Local_Account_Permissions_Report

This script connects to the Jamf Pro Classic API on a Jamf Pro server and reports which Jamf Pro user accounts have which permissions assigned, along with how those permissions are assigned (direct assignment to the user account, or via membership in a user group.)

Three items are required to use this script:

• The URL of the appropriate Jamf Pro server.
• An API client on the Jamf Pro server with sufficient privileges to read the necessary information from the Jamf Pro Classic API.
• The client secret for the relevant API client on the Jamf Pro server.

If setting up an API client with limited rights, here are the required API role privileges for the API client on the Jamf Pro server:

• Read Accounts

The report should include the following information:

• Account Name
• Account ID
• Account Enabled / Disabled
• Privilege Category
• Privilege Name
• Assignment Type

In this example, I have the following Jamf Pro user accounts set up on a Jamf Pro server:

• backup_admin_user_failover
• computer_deletion_service_account
• it_audit_service_account
• jamfpro-enroll

How permissions are assigned to the user accounts:

• backup_admin_user_failover: Member of the Administrator Permissions Group, which has the Administrator privileges set assigned to the group.
• computer_deletion_service_account: Permissions are directly assigned to the user account.
• it_audit_service_account: Member of the Auditor Permissions Group, which has the Auditor privileges set assigned to the group.
• jamfpro-enroll: Member of the Enrollment Permissions Group, which has the Enrollment privileges set assigned to the group.

With the example conditions, you should see similar output to what’s shown below when using the Jamf_Pro_Local_Account_Permissions_Report.sh script to generate a report:

As part of the script’s run, a report will be generated and you’ll be notified of where it is stored. The report will be in TSV format and appear similar to what’s shown below:

My practice has been to set them up on a per-task basis, which I’ve found can lead to an increasing number of API clients. At the same time, for auditing purposes, it’s useful to know which API clients are using which API roles as API roles determine the permissions that the API clients have.

To help me keep track of this, I’ve written a script which reports the following:

• The current list of the enabled and disabled API clients on a Jamf Pro server
• Which API roles are being used by the API clients.

For more details, please see below the jump.

The script is named API_Client_Role_Reporting.sh and is available via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/API_Client_Role_Reporting

This script connects to the Jamf Pro API on a Jamf Pro server and reports which API clients are assigned to which API client roles.

Three items are required to use this script:

• The URL of the appropriate Jamf Pro server.
• An API client on the Jamf Pro server with sufficient privileges to read the necessary information from the Jamf Pro API.
• The client secret for the relevant API client on the Jamf Pro server.

If setting up an API client with limited rights, here are the required API role privileges for the API client on the Jamf Pro server:

• Read API Integrations
• Read API Roles

In this example, I have the following API roles set up on a Jamf Pro server:

In turn, the following API clients have been also set up and assigned to those API roles:

With the example conditions, you should see similar output to what’s shown below when using the API_Client_Role_Reporting.sh script to generate a report:

As part of the script’s run, a report will be generated and you’ll be notified of where it is stored. The report will be in TSV format and appear similar to what’s shown below:

https://www.youtube.com/playlist?list=PLmBOyWhgnnx8rv3KJeCkSmDzyi7Jw5IR_

For convenience, I’ve linked my session here.

Update – May 13 2026: Apple has posted a KBase article that specifies which Mac models have this new option available:

• Mac mini introduced in 2024 or later.

• Mac Studio introduced in 2025 or later.

• iMac introduced in 2024 or later.

This setting does not appear to be manageable via MDM or DDM management as of this time, but it can be managed via the pmset command line tool. For more details, please see below the jump.

In the pmset man page , there is an autorestartatconnect setting which is listed as controlling this behavior. The autorestartatconnect setting can be set to an integer value of 0 or 1.

To turn on automatic restart on power connect, the following command should be run with root privileges:

To verify that the setting has been set, run the following command and see if it returns a value of 1.