babgond

As part of supporting Jamf Pro‘s API functionality, Jamf has made interactive documentation pages available with every Jamf Pro installation via the following address:

https://jamf.pro.server.here/api

When choosing to view the Classic API or Jamf Pro API documentation, there’s an option to log in and authenticate, so that you can run API commands interactively to see how running the commands works in real time and what results you see. This functionality is also useful when setting up API accounts with least privileged access, as it allows testing to verify that all necessary privileges have been assigned to the accounts.

Up until now, this authentication mechanism only supported using username and password authentication but as of Jamf Pro 11.2.0, the authentication mechanism now supports both of the following authentication methods:

• Username/Password authentication
• API client authentication

To use your preferred authentication method, please select it from the relevant drop-down menu.

A question I’ve seen repeatedly in the Mac Admins Slack goes something like this:

“I installed this profile for macOS NewVersion onto macOS OldVersion, then upgraded from macOS OldVersion to macOS NewVersion. The setting didn’t work. Why didn’t it work?”

Why it didn’t work has to do with how management profile settings are handled. When a management profile is installed, the settings contained within that profile are applied.

This settings application occurs exclusively at the time of the profile installation. Those applied settings are never again re-read or re-applied as long as that profile is installed. The settings in a profile are applied only at the time of installation and that is the current state of things.

How is this relevant to settings you want to apply to macOS? Apple defines what OS version a setting was introduced for, which means it does not work for OS versions prior to that. For more information, please see below the jump.

An example of this is the management setting for iPhone mirroring:

https://github.com/apple/device-management/blob/1fa842739c8f19db5b62f3ac6aed261cc378e5b8/mdm/profiles/com.apple.applicationaccess.yaml#L1834-L1860

This setting was introduced for macOS as of macOS 15 Sequoia. That means that the setting works on macOS Sequoia but what happens when you install a management profile like the one below which contains this setting onto a Mac running macOS 14 Sonoma?

Nothing.

A profile’s settings get applied at the time of installation. If the setting isn’t understood by the OS the profile is installed onto at the time of installation, the setting is ignored.

In the context of the management setting for iPhone mirroring, macOS Sonoma doesn’t have the management option for managing iPhone mirroring so Sonoma will ignore the setting. It will remain ignored if the Mac gets upgraded to Sequoia because the setting only gets applied at the time of installation and the setting never gets re-evaluated to see if it applies to Sequoia. The outcome is that the setting does not get applied on Sequoia if the profile with the setting was installed on Sonoma.

How do you fix this? Remove the profile with the iPhone mirroring setting from the Sequoia Mac and re-install the profile. Once the profile is installed again, the setting will get applied as part of the install process. Sequoia has that setting as a management option, so Sequoia will then apply the setting from the profile and manage iPhone mirroring as defined by the profile’s settings.

So what does this mean for management settings you want to apply to macOS NewVersion? You’ll need to check what the introduction version is for the setting you want to apply. If it’s a brand new setting where the introduction is on macOS NewVersion, you’ll need to wait until the Mac is running macOS NewVersion before deploying a profile to manage that setting.

For Mac admins who want the capability to install a setting on macOS OldVersion and have it apply to macOS NewVersion, I recommend filing feedback with Apple to request it .

Apple has introduced a number of pop-up windows over the years, which appear the first time you log into a Mac and sometimes also after an OS update. Apple added a new one for macOS Sequoia as part of introducing Apple Intelligence.

The Apple Intelligence pop-up window can be suppressed for the logged-in user by running the command shown below:

It is also possible to suppress the Apple Intelligence pop up window on macOS Sequoia using a configuration profile. For more details, please see below the jump.

The relevant preference domain and key values are below:

• Preference domain: com.apple.SetupAssistant.managed
• Key: SkipSetupItems
• Value: Intelligence

The profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/blob/main/SkipAppleIntelligenceSetup

As a follow-up to my earlier post on managing Apple Intelligence features on macOS Sequoia, Apple has added a couple of new management options for Apple Intelligence now that Apple Intelligence is able to communicate with external services like ChatGPT. For more details, please see below the jump.

As of macOS 15.2, management options are available for the following Apple Intelligence functionality:

• Genmoji
• Image Playground
• Writing Tools
• Summarizing emails
• Enabling Siri to connect to third party cloud-based intelligence services
• Managing non-anonymous login to third party cloud-based intelligence services

The relevant key values are below:

It’s important to note that while all of the settings listed above work on macOS Sequoia 15.2, not all work on earlier versions of macOS Sequoia. Here’s the compatibility list:

macOS 15.0 and later:

• allowGenmoji
• allowImagePlayground
• allowWritingTools

macOS 15.1 and later:

• allowMailSummary

macOS 15.2 and later:

• allowExternalIntelligenceIntegrations
• allowExternalIntelligenceIntegrationsSignIn

These settings can be managed by a configuration profile, where setting a boolean value of false will disable the Apple Intelligence feature in question. Please see below for example profiles. The example profiles are also available via the following links:

• Genmoji: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableGenmoji
• Image Playground: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableImagePlayground
• Writing Tools: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableWritingTools
• Summarize emails: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableMailSummary
• Block Siri from connecting to third party cloud-based intelligence services: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableExternalIntelligenceIntegrations
• Disable non-anonymous login to third party cloud-based intelligence services: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableExternalIntelligenceLogins

Note: If you’re planning to use the example profiles with Jamf Pro, the profiles will need to be signed before they can be uploaded to Jamf Pro. If you’re not familiar with how to sign profiles, the post linked below is a good guide to how that process works:

https://macblog.org/sign-configuration-profiles/

Genmoji:

Image Playground:

Writing Tools:

Summarize emails:

Block Siri from connecting to third party cloud-based intelligence services:

Disable non-anonymous login to third party cloud-based intelligence services:

One of the privacy protections Apple introduced for macOS as part of macOS Sequoia is MAC address randomization. This address randomization is a privacy feature which Apple first introduced for mobile devices in iOS / iPadOS 14 and later, as well as watchOS 7 and later, which enables a unique randomly generated MAC address to be provided to Wi-Fi networks when an Apple device connects via Wi-Fi to the Wi-Fi network. The reason for doing this is to prevent the Apple device from being tracked as it connects to public Wi-Fi networks, as each Wi-Fi network will receive a new MAC address from the Apple device every time it connects to the Wi-Fi network in question.

For shops which want to disable the MAC address randomization for their own Wi-Fi networks, Apple has provided a DisableAssociationMACRandomization management setting which is available for use in iOS 14 and later, macOS 15 and later, and watchOS 7 and later. However, for shops which don’t want to disable this privacy protection but still want to be able to find out what the actual MAC address of the Wi-Fi network interface on Macs running macOS Sequoia and later, it’s possible to use the networksetup tool to do so. (Hat tip to everyone in the Mac Admins Slack who helped with figuring this out.) For more information, please see below the jump.

Assuming the Wi-Fi network interface on your Mac has been assigned the display name of Wi-Fi, you can get the actual MAC address using the following command:

You should see output similar to what’s shown below:

If you want only the MAC address returned, you can use the following command:

You should see output similar to what’s shown below:

If you want only the MAC address returned with all the colons ( : ) removed, you can use the following command:

You should see output similar to what’s shown below:

One of the options available in Privileges 2.x is the capability of running an action once admin rights have been granted or removed.

This action can be launching an app or running a script and is set by the Run after privilege change setting.

This action can be further customized by choosing to only run the action once admin rights have been granted. This can be set by the Run only if administrator privileges have been granted setting.

Something to be aware of is that when using an action is that the script or application in question will be run within the context of the logged-in user. This means it will have the same level of access rights that the logged-in user currently has (standard versus admin.) This may be important if running the script or launching the application includes functionality which works for a user with admin rights but not for a user with standard rights. An example of this is running the following command using the log command line tool:

If the logged-in user has admin rights, the log command shown above runs without issues and without requesting authentication.

If the logged-in user has standard rights, you get an error that the log command operation is not permitted.

Privileges 2.x includes management options for setting post-actions, so that their operation and configuration can be set using configuration profiles. For more details, please see below the jump.

The relevant preference domain and key values are listed below:

• Preference domain: corp.sap.privileges
• Key: PostChangeExecutablePath
• Value: String containing the absolute filesystem path to an application or script

• Preference domain: corp.sap.privileges
• Key: PostChangeActionOnGrantOnly
• Value: Boolean

Here’s how the settings would appear in the following example:

1. The App Store app is launched as a post action.
2. The action is run once admin rights have been granted or removed.

Here’s how the settings would appear in the following example:

1. A script named privileges_teams_report.sh located in the /usr/local/bin directory is launched as a post action.
2. The action is run only when admin rights have been granted.

One use case for a post action script would be sending a report to a Slack or Teams channel via webhook. While Privileges natively supports sending JSON output to a web hook, both Slack and Teams need to have the JSON being sent to it formatted in specific ways, or else the receiving end won’t be able to work with it. They’re also different formats, so sending to Slack using JSON formatted for Teams doesn’t work and vice-versa.

I’ve written a couple of example scripts which can be used with Privileges as a post action, which are designed to be run as follows:

1. The reporting script is launched as a post action.
2. The action is run only when admin rights have been granted.

Note: The reason why the reporting script should be run only when admin rights have been granted is that the log command line tool is used in the scripts. As discussed previously, these scripts will run in the context of the logged-in user and if the logged-in user has admin rights, the log command runs without issues and without requesting authentication. If the logged-in user has standard rights though, the log command will error.

privileges_slack_report.sh

When configured with a Slack webhook URL, the following script should send a report similar to the one below to the relevant Slack channel.

privileges_teams_report.sh

When configured with a Teams webhook URL, the following script should send a report similar to the one below to the relevant Teams channel.

Example configuration profiles containing the PostChangeExecutablePath and PostChangeActionOnGrantOnly settings are available below:

ConfigurePrivilegesPostActionAppStore.mobileconfig

Settings:

1. The App Store app is launched as a post action.
2. The action is run once admin rights have been granted or removed.

ConfigurePrivilegesPostActionReportScript.mobileconfig

1. A script named reporting_script.sh located in the /path/to directory is launched as a post action.
2. The action is run only when admin rights have been granted.

One of the new features in Privileges 2.x is the unified ability to set and manage how long you want to grant admin rights, where running Privileges grants admin rights for a defined amount of time and then those admin rights are taken away. This ability had also existed in Privileges 1.x but it was exclusively tied to Privileges 1.x’s Toggle Privileges function, where in Privileges 2.x it is available no matter how Privileges is being run.

By default, Privileges 2.x will grant administrator rights for 20 minutes if not configured otherwise.

But what if you want to configure it otherwise? There are management options available for this. For more details, please see below the jump.

The relevant preference domain and key values are listed below:

• Preference domain: corp.sap.privileges
• Key: ExpirationInterval
• Value: Positive Integer

• Preference domain: corp.sap.privileges
• Key: ExpirationIntervalMax
• Value: Positive Integer

Note: In both cases, the positive integer values are defining time in minutes.

ExpirationInterval:

The ExpirationInterval key defines a set time in minutes after which administrator rights expire and the logged-in user reverts to using standard user rights. For example, setting ExpirationInterval to a value of 15 would set Privileges to allow admin rights for fifteen minutes. Once the fifteen minutes are up, the logged-in user reverts to using standard user rights.

In this example, the Administrator privileges expire setting in the Privileges settings would be set to the defined value and grayed out.

Note: Setting a value of 0 disables the timeout and allows the user to request administrator privileges which do not expire.

ExpirationIntervalMax:

The ExpirationIntervalMax key defines a set time in minutes after which administrator rights expire and the logged-in user reverts to using standard user rights. In general, this works like the ExpirationInterval key but it allows the logged-in user to choose a timeout value which is different as long it does not exceed the defined value.

For example, setting ExpirationIntervalMax to a value of 20 would set Privileges to allow admin rights for twenty minutes. However, the logged-in user can go into the Privileges settings and set a different time interval for the Administrator privileges expire setting as long as that time interval does not exceed the defined value of twenty minutes.

Note: In the event that both the ExpirationInterval and ExpirationIntervalMax settings are set, as of Privileges 2.0 the ExpirationInterval behavior will be applied. The Administrator privileges expire setting in the Privileges settings would be set to the defined value for ExpirationInterval and be grayed out.

The ExpirationInterval and ExpirationIntervalMax settings can be managed by configuration profiles. Please see below for example profiles.

ExpirationInterval:

ExpirationIntervalMax:

SAP has released a new major version of their open source Privileges app. This tool provides macOS standard user accounts with a way to request administrator rights. Privileges 2.x includes a number of new features not available in Privileges 1.x and in particular fulfills two particular long-standing requests from its user community:

1. It provides a unified mechanism for time-limited admin rights.
2. SAP now provides a signed and notarized installer package for deployment.

For more details, please see below the jump.

Time-limited admin

Privileges 1.x featured a mechanism for setting a time limit, but it was tied specifically to using the Toggle Privileges function. This was discussed in the previous version of the Privileges FAQ:

By default, is there a time limit on the admin rights granted by Privileges?

No. Admin rights are granted until some process (like running Privileges again) takes them away.

Can I set Privileges to give me administrator rights for a defined amount of time?

Yes. You can use the Toggle Privileges option on the dock icon to get admin rights for a set amount of time (the default amount is 20 minutes.)

With Privileges 2.x, time-limited admin is no longer tied exclusively to the Toggle Privileges function. For those who want to set a time limit for granting admin rights, you can now set this and Privileges 2.x will remove admin rights after the set time regardless of if you used the Privileges application, the dock tile or the command line tool to request admin rights.

By default, Privileges 2.x will grant administrator privileges for 20 minutes if not configured otherwise.

This is discussed in the updated Privileges FAQ:

By default, is there a time limit on the admin rights granted by Privileges?

Yes. By default, administrator privileges are granted for 20 minutes (if not configured otherwise). However, if necessary, you can configure Privileges not to remove administrator privileges by setting the expiration interval to “Never” in the app’s settings.

Installer package deployment

Privileges 1.x had an odd issue, where some folks who tried packaging it into an installer package consistently ran into problems. This was partially addressed by using AutoPkg to build the installer package, as AutoPkg-driven workflows consistently produced working installers. SAP has addressed this issue by providing a signed and notarized installer package for Privileges 2.x, which solves the problem by making it unnecessary for Mac admins to create their own installer packages for deployment.

For those using Privileges in your own shops, I recommend taking a look at Privileges 2.x as it includes more features and fixes in addition to what I’ve discussed above. It is available via the following link:

https://github.com/SAP/macOS-enterprise-privileges

For those who want to manage Privileges, please see here for the Managing Privileges documentation:

https://github.com/SAP/macOS-enterprise-privileges/wiki/Managing-Privileges

If the following situation occurs:

1. You forgot the password to the local account you use to log into your Mac.
2. You have FileVault enabled.
3. You have the FileVault recovery key available.

You can use the FileVault recovery key to authenticate changing your local account to use a new password. Apple has documentation on how to do this available here:

https://support.apple.com/102633 (please see the Reset it using your recovery key instructions)

However, it looks like Apple made a change at the login window for macOS Sequoia. Apple’s instructions reference clicking on a ( ? ) symbol, which doesn’t appear in my testing on Apple Silicon Macs. Without that, how do you access the recovery key entry blank to enter the recovery key?

In the absence of the ( ? ) symbol appearing at the login window, you should be able to use the following keyboard shortcut to get the recovery key entry blank:

Shift+Option+Return

Clicking that combination of keyboard keys on an Apple Silicon Mac should cause the recovery key entry blank to appear at the login screen. 

Note: I was not able to verify that this also works on Intel Macs, so please let me know in the comments if Intel Macs have different behavior.

Here’s how the login window should appear when you enter the keyboard shortcut in this scenario:

A while back, I had posted about a solution for clearing failed MDM commands on a per-computer basis. I recently learned it’s also possible to clear them by using an API command which clears failed MDM commands from all members of a specified Jamf Pro smart or static group. This approach works for both computer groups and mobile device groups. For example, if you wanted to clear all failed MDM commands for members of a mobile device group, you could use a command like the one shown below:

If you wanted to clear all failed MDM commands for members of a computer group, you could use a command like the one shown below:

In both cases, the following API permission would be required:

Flush MDM Commands

If using a user account to authenticate to the API, this permission would be set in Jamf Pro Server Actions:

If using an API client to authenticate to the API, this permission would be set in an API role:

For folks who want to use this method to clear failed API commands, I’ve written a couple of scripts to assist with this. For more details, please see below the jump.

I’ve posted both scripts to the following location:

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

• clear_failed_Jamf_Pro_mdm_commands_from_computer_group.sh – clears failed MDM commands from Jamf Pro smart or static computer groups
• clear_failed_Jamf_Pro_mdm_commands_from_mobile_device_group.sh – clears failed MDM commands from Jamf Pro smart or static mobile device groups

Both scripts are designed to use API client authentication, with the following permissions assigned:

clear_failed_Jamf_Pro_mdm_commands_from_computer_group.sh

• Flush MDM Commands
• Read Smart Computer Groups
• Read Static Computer Groups

clear_failed_Jamf_Pro_mdm_commands_from_mobile_device_group.sh

• Flush MDM Commands
• Read Smart Mobile Device Groups
• Read Static Mobile Device Groups

Both scripts are designed to use the Jamf Pro ID number for a specified Jamf Pro smart or static group to do the following:

1. Verify that the provided Jamf Pro ID is a positive number, as Jamf Pro IDs should only be only numbers which are not negative.
2. If the provided Jamf Pro ID is a positive number, look up the display name of the specified Jamf Pro smart or static group via the Jamf Pro Classic API using the Jamf Pro ID number.
3. If the lookup succeeds, send a command to clear all failed MDM commands associated with the members of the specified group.
4. If the MDM command clearing succeeds, display a message that all failed MDM commands associated with the members of the specified group have been cleared.

The scripts will produce errors in the following cases:

1. The provided Jamf Pro ID is not a positive number.
2. The lookup of the display name of the specified Jamf Pro smart or static group fails.
3. The MDM command clearing fails.

Successful output should look like this for the following scripts:

clear_failed_Jamf_Pro_mdm_commands_from_computer_group.sh

clear_failed_Jamf_Pro_mdm_commands_from_mobile_device_group.sh