babgond

As a follow-up to my previous post for managing Background Security Improvements (BSIs) using Jamf Pro’s Blueprints, it looks like I misunderstood what one of the management options was actually doing. As part of my prior post, I had said that in order to set this:

• Background Security Improvements will be automatically installed

You needed to do the following in the Blueprint’s Software Update Settings component:

1. Go to the Background Security Improvements section
2. Select the following options to apply the desired settings:

• Background Security Improvements updates will be installed:
  • Select Allow for Background Security Improvements installation

That enables an installation option, but not the automatic installation option. For more details, please see below the jump.

What installation option is being enabled? As it turns out, what’s enabled is the logged-in user’s ability to manually select installing the BSI update. You can see this by setting the Background Security Improvements installation setting to Allow.

Once that’s been set and deployed to devices, look at System Settings: Privacy & Security: Background Security Improvements on a device that the setting has been deployed to. If there’s a BSI available to install, you’ll see it listed there along with an Install button.

Next, let’s set Background Security Improvements installation to Restrict and deploy the settings to devices.

Now when we look at System Settings: Privacy & Security: Background Security Improvements on a managed device, that section and its Install button have disappeared.

That means that the only install option available now is the automatic install option. Where’s that managed from? That is also managed in the Software Update Settings component, but in a different section. To set management for automatic installation of BSI updates:

1. Go to the Install Actions section
2. Select the following options to apply the desired settings:

• Automatic installs of available security updates:
  • Select Always

When those settings are deployed to devices, you can go to System Settings: Privacy & Security: Background Security Improvements on a managed device and see that the Automatically Install setting is enabled and grayed out. There should also be a message that the setting is managed by your organization.

You can also disable automatic installation of BSIs, but a very important thing to be aware of is that the Automatic installs of available security updates setting is managing all background security updates for macOS, not only BSIs. This includes updates for Gatekeeper, XProtect and verifying the firmware that your Mac uses. Please keep that in mind if you want to disable automatic installs of BSIs.

If you’ve considered this information and still want to disable automatic installs of BSI updates, you can do so by using the following process:

1. Go to the Install Actions section
2. Select the following options to apply the desired settings:

• Automatic installs of available security updates:
  • Select Never

When those settings are deployed to devices, you can go to System Settings: Privacy & Security: Background Security Improvements on a managed device and see that the Automatically Install setting is disabled and grayed out. There should also be a message that the setting is managed by your organization.

As part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to manage software updates. Jamf Pro’s Blueprints leverages this capability to support to support managing software updates, including Background Security Improvements. Let’s see how this works using the following software update configuration as an example:

• Background Security Improvements will be automatically installed
• Background Security Improvements can be removed

For more details, please see below the jump.

As of Jamf Pro 11.25.2, there is not a Blueprints template available for creating blueprints which manage software update settings so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. You should see an unconfigured Blueprint. Click where it says Untitled blueprint and provide a name.

For this example, I’m using Background Security Improvements Management Settings.

5. Scroll down in the list on the left-hand side of the browser window to locate the Software Update Settings component.

6. Click on the Software Update Settings component and drag the Software Update Settings component to the Components in this blueprint section.

7. Once added to the Components in this blueprint section, click anywhere on the Software Update Settings component to open it for editing.

8. At this point, you will see the software update management settings. From there, scroll down to the Background Security Improvements section and click the Configure button.

In the Background Security Improvements section, select the following options to apply the following desired settings:

• Background Security Improvements updates will be installed:
• Select Allow for Background Security Improvements installation
• Background Security Improvements updates can be removed:
• Select Allow for Background Security Improvements removal

Once all choices have been made and verified, click the Update button.

You should now see the following items set to Enabled:

• Background Security Improvements installation
• Background Security Improvements removal

9. Once all the settings choices have been made and verified, click the Save changes button.

10. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the arrow button.

11. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Background Security Improvements Settings Deployment Group.

12. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

18. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Background Security Improvements Management Settings Blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it.

When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section. If you’re deploying a software update configuration via Blueprints, you should see a Software Update listing for Software Update Settings in the Device Declarations section.

If you click on the Software Update Settings listing, you should see the details of what is being managed. In the case of our example where we are setting Background Security Improvements to be automatically installed and allowing the removal option, you should see the the following entries set to On:

• Enable
• Enable Removal

As part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to deploy MDM configuration profiles using DDM as the delivery mechanism in place of using MDM to deliver the profiles. Jamf Pro’s Blueprints leverages this capability to support managing the settings for the built-in application firewall on macOS. Let’s see how this works with the following settings for the firewall:

• Firewall enabled
• Stealth mode enabled
• User changes to the firewall disabled

For more details, please see below the jump.

As of Jamf Pro 11.25.2, there is not a Blueprints template available for creating blueprints which manage firewall settings so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints.

3. Click the Create blueprint button.

4. You should see an unconfigured Blueprint. Click where it says Untitled blueprint and provide a name.

For this example, I’m using Firewall Management Settings.

5. Scroll down in the list on the left-hand side of the browser window to locate the Firewall component.

Note: The Firewall component is listed as being the Legacy Payload type. In Blueprints, a Legacy Payload type indicates that this is an MDM configuration profile being delivered via DDM.

6. Click on the Firewall component and drag the Firewall component to the Components in this blueprint section.

7. Once added to the Components in this blueprint section, click anywhere on the Firewall component to open it for editing.

8. At this point, you will see the firewall management settings (with one exception which will be covered in following steps.) To apply the desired settings, select the following options and set them to True:

• EnableFirewall
• EnableStealthMode

9. Once all the settings choices have been made and verified, click the Save changes button.

10. The remaining setting (disabling the ability for the user to make changes to the firewall) is in the separate Security Preferences component.

Scroll down in the list on the left-hand side of the browser window to locate the Security Preferences component.

11. Click on the Security Preferences component and drag the Security Preferences component to the Components in this blueprint section.

12. Once added to the Components in this blueprint section, click anywhere on the Security Preferences component to open it for editing.

13. At this point, you will see the Security Preferences management settings. To apply the desired setting, select the following option and set it to True:

• Do not allow firewall

14. Once all the settings choices have been made and verified, click the Save changes button.

15. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the arrow button.

16. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Firewall Settings Deployment Group.

17. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

18. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Firewall Management Settings Blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying a legacy profile via Blueprints, you should see a Profiles section in Device Declarations. In the Profiles section, there is a listing with a name that matches the name of the blueprint which was deployed. In the case of our example, the listing shows Firewall Management Settings.

If you click on the Firewall Management Settings listing, you should see the details of what is being managed.

Note: The MDM profiles delivered via Blueprints are not signed. This is mentioned in the documentation available via the link below:

https://learn.jamf.com/en-US/bundle/jamf-pro-blueprints-configuration-guide/page/Blueprint_Builder.html

You can also verify that the firewall is turned on and not editable by the user by going to System Settings: Network: Firewall. It should display a message that the setting has been configured by a profile.

One of the capabilities of mobile device management (MDM) on macOS is that you can use MDM commands to deploy installer packages, via the InstallEnterpriseApplication MDM command. If you’re using Jamf Pro for your MDM management, the Jamf Pro API can be used to run this MDM command, allowing you to send out InstallEnterpriseApplication commands to deploy installer packages. For more details, please see below the jump.

The relevant Jamf Pro API endpoint is the v1/deploy-package endpoint. Here are the required API permissions for using it:

API permissions using user account authentication:

Jamf Pro Server Objects:

• Computers: Read, Update

Jamf Pro Server Actions:

• Send Computer Remote Command to Install Package
• Send MDM command information in Jamf Pro API
• View MDM command information in Jamf Pro API

API permissions using API client authentication:

• Read Computers
• Update Computers
• Send Computer Remote Command to Install Package
• Send MDM command information in Jamf Pro API
• View MDM command information in Jamf Pro API

Installer packages deployed using this method would need to be signed and built as a distribution-style package. I have a blog post describing the details available via the link below:

https://derflounder.wordpress.com/2023/10/24/preparing-installer-packages-for-installation-using-mdm-commands/

If you look at the Jamf Pro API documentation available with Jamf Pro, using the v1/deploy-package Jamf Pro API endpoint to successfully deploy a package requires sending a JSON block containing a manifest for the package along with some additional information on whether or not the package is set to be managed and which devices to install it on. Let’s take a look at the essential components of this block, using an example provided as part of the Jamf API documentation:

This has several parts, so let’s break it down by section:

Manifest:

This is providing the MDM command’s information about the package to be installed. Here are the essential parts you need to provide as part of the manifest:

• URL: The installer package will need to be hosted on an available location which allows anonymous HTTPS downloads (i.e. downloading via HTTPS without requiring authentication.)
• Hash: This is a unique, fixed-length string generated by running an file’s data (in this case an installer package) through a cryptographic algorithm like MD5 or SHA256.
• Hash Type: This is the cryptographic algorithm being used. Either MD5 or SHA256 is supported.

Note: The hash type description must use capitalization. No lowercase letters allowed in this use case.

• Bundle ID: For an installer package, this is the unique, reverse-DNS identifier (for example, com.example.app) used to identify macOS installer packages.
• Bundle Version: For an installer package, this is the version of the installer package. Packages with the same package identifier are compared using this version, to determine if the package is an upgrade or downgrade.
• Title: This is the title of the package being installed
• Size in Bytes: This is the size in bytes of the installer package.

For more information on the topic of creating a manifest for installer packages deployed using the InstallEnterpriseApplication MDM command, please see the link below:

https://www.dersoldat.org/?p=1456

Next, there’s the choice to install as managed or not:

The installAsManaged configuration option defines if the installer package is defined as installing a managed app or not installing a managed app. For the most part, this defines whether or not the MDM would be able to uninstall the app following installation using the InstallEnterpriseApplication MDM command.

The default configuration for the InstallAsManaged configuration option is false, so unless you know you will need to define it as true, this configuration option does not need to be included as part of the API call.

For Mac admins, here are the considerations to keep in mind for this option:

installAsManaged = true:

• The MDM server can install, track and remove the app installed by the installer package.

installAsManaged = false:

• The MDM server is only deploying the installer package and does not track anything afterwards.

Of course, if you’re choosing to deploy an installer package, you need to define what devices you’re installing it on. That’s the next two parts of the configuration:

This allows you to define the individual Jamf Pro ID numbers of the devices you want to install on.

This allows you to define the device static or smart group containing the devices you want to deploy the installer package to.

Here’s an example API command to install a package named MyGreatInstaller.pkg as unmanaged from an S3 bucket named 75d831079efb4d02ada44eed4f8ae093 on individual devices with Jamf Pro device IDs 102, 103 and 104:

In this example, the JSON block being sent looks like this:

Here’s an example API command to install a package named MyGreatInstaller.pkg as unmanaged from an S3 bucket named 75d831079efb4d02ada44eed4f8ae093 on all devices in a Jamf Pro device group with Jamf Pro ID 37:

In this example, the JSON block being sent looks like this:

Once the API command is sent, there are two possible HTTP status codes which indicate the API command ran successfully:

• HTTP 200
• Meaning: Package deployment MDM command was successfully processed.

• HTTP 202
• Meaning: Package deployment MDM command was queued up for processing.

Here’s an example of a successful API response from an installer package deployment to a device with the Jamf Pro ID of 67:

Every so often, I need to delete one or multiple computers from a Jamf Pro server. This can be accomplished in the Jamf Pro admin console, but it can also be accomplished via the Jamf Pro API’s computers-inventory API endpoint. For more details, please see below the jump.

The API command to delete a computer inventory record from a Jamf Pro server should look similar to this:

I was able to use the API information discussed above to create a script which:

1. Deletes specified computer inventory records.
2. Generates a report of the Macs whose computer inventory records were deleted.

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

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

The script is designed to take in a set of Jamf Pro ID numbers in a plaintext file, where the Jamf Pro ID numbers correspond the Macs you want to delete. The script can also accept one Jamf Pro ID number as input, if a plaintext file containing Jamf Pro ID numbers is not available.

Three items are required to use these scripts:

• The URL of the appropriate Jamf Pro server.
• The username of an account on the Jamf Pro server with sufficient privileges to delete computers from the Jamf Pro server.
• The password for the relevant account on the Jamf Pro server.

Jamf Pro account privileges required by the Jamf Pro server account referenced above:

Jamf Pro Server Objects:

• Computers: Read, Delete

If you want to delete multiple computers at once from Jamf Pro, you will also need to provide a plaintext file containing the Jamf Pro IDs of the computer you wish to delete. The plaintext file should look similar to this:

Once the specified items are available, the scripts can be run using the following commands:

To use Delete_Computers_From_Jamf_Pro.sh to delete one computer:

To use Delete_Computers_From_Jamf_Pro.sh to delete multiple computers:

When using Delete_Computers_From_Jamf_Pro.sh to delete one computer, you should see output that looks like this:

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:

When using Delete_Computers_From_Jamf_Pro.sh to delete multiple computers, you should see output that looks like this:

The corresponding report will appear similar to what’s shown below:

In addition to the scripts described above which use user accounts for authentication, there are also matching scripts which use API client authentication available on GitHub via the links above. 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:

• Computers Read
• Computers Delete

As part of developing Self Service+, Jamf built in functionality which originally came from their Jamf Connect tool. Among the functionality added to the Self Service+ app is Jamf Connect’s ability to serve as a privilege elevation tool. This means that Self Service+ can be used as a privilege elevation tool for those shops who are interested in providing and managing admin privileges to standard user accounts on macOS. For more details, please see below the jump.

One thing that’s important to know is that this privilege elevation functionality will not manage an account which already has admin privileges. It is designed to manage an account which has standard user privileges, by promoting that account to have admin privileges and then (if configured to do so) demote that account back to having standard user privileges. Jamf has documentation available which covers this topic, which is available via the link below:

https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Privilege_Elevation_Local_Accounts.html

The privilege elevation settings are documented here:

https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Menu_Bar_App_Preferences.html#reference-7936

Some of the privilege elevation functionality is dependent on Jamf Connect and an identity provider, but there are several settings which can be set independently for Self Service+ and do not depend on Jamf Connect or an identity provider:

For example, you can configure Self Service+ to act as a privilege elevation tool for standard users with the following settings configured:

• Standard users can elevate to having admin privileges using the Self Service+ menubar icon.
• Elevated users will be demoted back to standard user privileges after fifteen minutes.
• User will see a countdown clock appearing in the Self Service+ menubar icon.
• Elevated users can choose to be demoted back to standard user privileges before the fifteen minute deadline using the Self Service+ menubar icon.

The profile shown below will enforce these settings:

Here’s how this looks for a logged-in standard user on macOS Tahoe 26.3.0 with the Self Service+ app installed:

You can also request privilege elevation and demotion within the Self Service+ app. Here’s how this looks for a logged-in standard user on macOS Tahoe 26.3.0 with the Self Service+ app installed:

You will be able to see notifications of when privilege elevation began and ended in the Self Service+ app.

This information is also logged to the unified system logs, with documentation on how to gather that data available via the link below:

https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Managing_Privilege_Elevation_with_Logs.html

Back in November 2025, Jamf released options for automatically upgrading the OS version of a Mac to the latest version of macOS that a particular Mac can support. However, this upgrade option meant that the Mac could potentially be upgraded to a new major version of macOS as part of the upgrade process.

For example, applying this software update declaration to a Mac running macOS Sequoia 15.7.1 would not upgrade it to the latest version of Sequoia, which is 15.7.3 as of February 5, 2026. Instead the Mac would be upgraded to the latest version of macOS available, which is macOS Tahoe 26.2 as of February 5, 2026.

To address this, now there is an option for updating the OS version to the latest minor version of the OS that the Mac is currently running. Using the example above, now a software update declaration can be applied to update a Mac running macOS Sequoia to the very latest version of macOS Sequoia, but not upgrade the Mac to now run macOS Tahoe.

For those familiar with Jamf Pro’s managed software update functionality, the new software update declaration functionality provides the following update options:

• Download and schedule to install
• Latest minor version

The Latest minor version functionality in the managed software update functionality tells the managed Mac to download and install the latest update available to the current version of macOS that a particular Mac is running. The Blueprints software update declaration option provides that same experience, where you can do the following:

• Set that you want the managed Macs to update their OS version using the latest update for the current version of macOS that the Mac is running.
• Set a deadline that you want to have your Macs updated by.

For more details, please see below the jump.

For this example, I have the goal of updating managed Macs to the latest available update for the current version of macOS that the individual Macs are running.

I want to have them all updated within one day of the release of new updates for the current macOS running on the individual Macs, with the install time set as being 6:00 PM (18:00)

I can set up a Blueprint in Jamf Pro to deploy a software update declaration to enforce this using the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click on Update software to latest version.

4. Give it a name when prompted. For this example, I’m using Update macOS version.

5. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Managed Software Update Deployment Group.

6. In the Software Updates section, I’m choosing the following settings:

• Enforcement type:
• Latest OS version
• Check the Ignore major versions checkbox (this setting is what restricts your Mac to updating to the latest update available for the current version of macOS that a particular Mac is running.)
• Days after release to enforce update:
• 1
• Install at (local device time):
• 18:00

7. Once all the information has been entered and verified to be correct, click the Save button.

8. Click the Deploy button to deploy the changes to the Macs you want to manage.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Update macOS version Blueprint as being deployed.

Note: The options available via Blueprints for software declarations are the ones Apple has specified for software update declarations. For more information about this topic, please see the following link:

https://support.apple.com/guide/deployment/software-update-declarative-configuration-depca14ecd4d/web

For this example, I’m deploying this Blueprint to a Mac which is running macOS Tahoe 26.0.1. As mentioned previously, as of February 5, 2026, the latest version of macOS Tahoe is macOS 26.2.

On your managed devices that are not yet up to date with all updates for the current version of macOS being run by the Mac, you can verify that the new software update declaration has been deployed by clicking on the enrollment profile, then scrolling to the bottom. In the case of this example, you should see a Device Declarations section with a listing for Software Update.

Because 26.0.1 has 26.1 and 26.2 as subsequent updates, Required Software Update listings for both 26.1 and 26.2 appear. However the Mac will only install 26.2 since that is the latest update for macOS Tahoe.

The user logged into the macOS 26.0.1 Mac should also be prompted to install macOS 26.2 right away, since the declaration is enforcing installing the update at one day after the macOS update’s release date and macOS Tahoe 26.2 was released on December 12, 2025.

On your managed Macs that are fully up to date, you will not see the Software Update declaration appearing on the enrollment profile. This is because the Mac is already fully updated and there is nothing for the Mac to do in response to the deployed software update declaration.

As part of the software testing cycle, Mac admins may choose to delay making Apple’s macOS updates generally available to their fleet while they’re testing to make sure all the software used on their organization’s Macs works correctly on new versions of macOS. To assist with this, Apple has made available deferral settings for Apple’s Software Update on macOS, where you can choose to defer the following for up to 90 days:

• Major OS upgrades: An upgrade is a major macOS release with a new name (for example, macOS Sequoia 15 to macOS Tahoe 26).
• Minor OS updates: An update is a minor release within the same macOS version, such as Tahoe 26.0 to 26.2.
• Non-OS updates: These are software updates provided by Apple that are not covered by the prior two categories.

For those who need to know when deferral periods end, Apple has them available for the current shipping OS via the link below:

https://support.apple.com/guide/deployment/about-software-updates-depc4c80847a/web (see the Software release dates section.)

One example of a deferral choice is delaying the release of a new major version of macOS. In this scenario, a Mac admin may want to delay release because mandatory security software for their environment has not yet been certified by the software vendor as being compatible with the new version of macOS. You can use Blueprints in Jamf Pro to distribute these tokens, using the Software Update Settings component in Blueprints.

Let’s take a look on how to deploy deferral settings using using the following software update configuration as an example:

• What’s deferred: Major OS upgrades
• How long: 90 days

For more details, please see below the jump.

As of Jamf Pro 11.24.0, there is not a Blueprints template available for creating blueprints which manage software update settings so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. You should see an unconfigured Blueprint. Click where it says Untitled blueprint and provide a name.

For this example, I’m using Apple 90 Day Deferral.

5. Scroll down in the list on the left-hand side of the browser window to locate the Software Update Settings component.

6. Click on the Software Update Settings component and drag the Software Update Settings component to the Declaration group section.

7. Once added to the Declaration group section, click anywhere on the Software Update Settings component to open it for editing.

8. At this point, you will see all available Software Update settings which are available for all Apple platforms. To apply the desired deferral settings, select the following option:

Deferrals

Click the associated Configure button.

Check the checkbox for Number of days to defer a major macOS software update.
Enter the following value in the entry blank:

90

This will configure major OS upgrades to be deferred for the maximum amount of time, which is 90 days following the release of the major OS upgrade.

Once all choices have been made and verified, click the Update button.

9. Once all the settings choices have been made and verified, click the Save button.

10. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the arrow button.

For this example, I’m selecting a static group named macOS 90 Day Deferral Group. Once the desired smart and/or static groups have been set and verified for the scope, click the Save button.

11. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

12. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Apple 90 Day Deferral Blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying a software update configuration via Blueprints, you should see a Software Update Settings listing for Software Update in the Device Declarations section.

If you click on the Software Update Settings listing, it should report the following:

• Major period: 90

As part of my work, I occasionally need to pull information from the unified system log, either directly on a Mac or from a sysdiagnose file, using the log command line tool. However, I also prefer to run as a standard user account most of the time and use privilege elevation tools like SAP’s Privileges or the privilege elevation functionality built into Jamf’s Self Service+ tool to get admin privileges when needed.

The combination of the two sometimes means I get halted while working because the log command line tool needs an account with admin privileges to run when it is getting log information from the unified system log on the Mac I’m using. Using the log command line tool doesn’t require root privileges or require admin authorization, but it needs to be run by a user with admin rights.

Note: This requirement for admin privileges does not appear to be coming from the log command line tool itself, but instead is coming from the unified system log. The reason I’m saying this is that accessing logs using the log tool from a sysdiagnose file does not require admin privileges. If any readers have more information about this topic, please let me know in the comments.

This has been an occasional annoyance because I get pulled briefly out of my focus while working in order to elevate my account’s privileges and then go back to my work. However, I was able to develop a solution for this issue using the sudo command line tool. For more details, please see below the jump.

This method uses the ability on macOS for the sudo command line tool to use properly formatted configurations for the sudo tool, where those configuration files are stored as plaintext files in the /private/etc/sudoers.d directory. The following process will create a sudo configuration which is stored in a plaintext file named logstandarduser which will be stored in the /private/etc/sudoers.d directory.

The configuration should be a plaintext file and formatted as followed:

A. Enter the following:

%staff

B. Hit the Tab key to create a tabbed space
C. Enter the rest of the line:

ALL = (ALL) /usr/bin/log

The complete configuration file should look like this:

What this does is create a sudo configuration which allows all members of the staff group on the Mac, which is a group that has all local users on the Mac as members, to run the log command line tool with root privileges. This removes the need for the account to have admin rights and enables accounts with only standard rights to use the log command line tool to get information from the unified system log on that Mac.

This sudo configuration can be deployed to Macs by either copying the logstandarduser file into the /private/etc/sudoers.d directory (a task which requires root privileges) or by using DDM to deploy the logstandarduser file as a configuration file for the sudo tool.

Once the sudo configuration is deployed, it should be possible for any local account on the Mac to query the unified system log via using the sudo command line tool to run the log command line tool.

As a follow-up to my previous post on using Apple Business Manager to enroll in the AppleSeed for IT program, my colleague Mark let me know that in addition to the Administrator role, it appears there are two other roles which can administer the AppleSeed for IT program for an organization.

Note: One of those roles is exclusive to Apple School Manager, so for Apple Business Manager there is only one other role in addition to the Administrator role which can administer the AppleSeed for IT program.

• People Manager role (available in Apple Business Manager and Apple School Manager):

If you look in the People Manager role in either Apple Business Manager and Apple School Manager, there is an Administer AppleSeed for IT checkbox option.

This option is disabled by default, but it is the same checkbox option which is checked for the Administrator role, which in turn allows the Administrator role to administer the AppleSeed for IT program for an organization.

• Site Manager role (available only in Apple School Manager):

If you look in the Site Manager role in Apple School Manager, there likewise is an Administer AppleSeed for IT checkbox option. This option is enabled by default, so it looks like the Site Manager role in Apple School Manager by default has the same ability as the Administrator role to administer the AppleSeed for IT program for an organization.