Apple recently released new hardware models for Mac Minis and MacBook Pros which use Apple’s M4 processors. As those new machines are purchased by companies, schools or institutions and get loaded into those organization’s Apple Business Manager (ABM) or Apple School Manager (ASM) instances though, new device listings for M4 Mac Minis and M4 MacBook Pros aren’t appearing. What is appearing are 21.5 inch iMacs, which does not appear to be an iMac hardware model that Apple is selling as of November 2024.
Why is this? I’ve observed over time that the 21.5 inch iMac listing is what appears for new hardware models in ABM / ASM when Apple hasn’t yet updated ABM / ASM with the information for the newly-released hardware model.
You should be able to confirm in ABM / ASM if the part number listed for the Mac in question matches up with what you’re expecting, in place of being the part number for a 21.5 inch iMac. In this example, the part number appearing is MX2E3ZE/A, which corresponds to a part number for a 2024 14 inch MacBook Pro.
Historically, once Apple updated ABM / ASM with the updated hardware model information, this display issue in ABM / ASM has corrected itself. Affected device listings switched from displaying as 21.5 inch iMacs to whatever actual hardware model the device is.
MDM profiles can use the new key ‘forceBypassScreenCaptureAlert’, which allows owners of managed devices to opt out of user notifications for content capture technologies. (131327961)
What’s this note discussing? It’s referring to a user notification that Apple introduced in macOS Sequoia for apps which request screen access but aren’t using Apple’s SCContentSharingPickerMode API to do so. A good example is the user notification for the Zoom app, which uses screen access for video conferencing.
These user notifications appear monthly and request the user to choose whether or not they want to allow this access for the app in question.
For Mac environments which want to manage these notifications and prevent them from being displayed to their users, Apple has provided management options as part of macOS Sequoia 15.1. For more details, please see below the jump.
It’s important to note that while this management setting works on macOS Sequoia 15.1, it is not available to macOS Sequoia 15.0.1, 15.0.0 or earlier versions of macOS.
These settings can be managed by a configuration profile, where setting a boolean value of true will disable the user notifications. Please see below for an example profile. The example profile is also available via the following link:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Note: If you’re planning to use the example profile with Jamf Pro, it will need to be signed before it 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:
As an alternative, you can use the Application & Custom Settings profile payload in Jamf Pro with the plist shown below to create a profile with the same functionality as the example profile.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
As part of Apple’s rollout of Apple Intelligence, there’s a Notification Center notification which may appear on macOS 15.1 and later which prompts you to try using Apple Intelligence.
Shops who want to block use of Apple Intelligence for security reasons may also want to stop these notifications from appearing. This is possible to do once you have the bundle identifier for the notification in question. Thanks to excellent detective work by colleagues in the Mac Admins Slack, the correct bundle identifier for this notification has been identified as the following:
_SYSTEM_CENTER_:com.apple.followup.alert
Once you have the bundle identifier, you can put this into a configuration profile which manages notification settings to block these notifications from appearing. For more details, please see below the jump.
Please see below for an example profile. This profile is also available via the following link:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
As part of the release of macOS Sequoia, Apple has provided management options on macOS for Apple Intelligence features. While not all of these Apple Intelligence features may be available as of macOS 15.1 in all areas of the world, use of these new features may not be acceptable for security reasons in all Mac environments. Having these management options available now allows Mac admins to get management of these features in place before Apple makes them available. For more details, please see below the jump.
It’s important to note that while all of the settings listed above work on macOS Sequoia 15.1, not all the settings work on macOS Sequoia 15.0.0 and 15.0.1. Here’s the compatibility list:
macOS 15.0 and later:
allowGenmoji
allowImagePlayground
allowWritingTools
macOS 15.1 and later:
allowMailSummary
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
iPhone mirroring is a new feature as of macOS Sequoia, which acts as a screen sharing method for an iPhone from a Mac. It allows the use of an iPhone from a nearby Mac by displaying the iPhone’s screen within an iPhone Mirroring.app window and allowing the Mac user to interact with the iPhone’s screen, including being able to access its apps and notifications.
This new screen sharing capability may not be acceptable for security reasons in all Mac environments, so Apple has provided management options for disabling the use of iPhone mirroring. For more details, please see below the jump.
The relevant preference domain and key values are below:
Preference domain: com.apple.applicationaccess
Key: allowiPhoneMirroring
Value: Boolean
This setting can be managed by a configuration profile, where setting a boolean value of false will disable iPhone mirroring and prevent it from working. Please see below for an example profile. This profile is also available via the following link:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
In Apple Business Manager (ABM) or Apple School Manager (ASM), you can link to your identity provider (IdP) to ABM and ASM. This allows folks to sign in to Apple devices with the same username and password that they use to log into systems used at their company, school or institution. Apple refers to this as federated authentication and supports this by creating Managed Apple Accounts (MAA) with the username and email address of the user in question, where that information is being provided by that company, school or institution’s IdP. Once this federation process is completed, when someone tries to use their MAA to log into an Apple system, they’ll be provided with the login screen for that company, school or institution’s IdP, in place of using Apple’s own authentication system for Apple Accounts.
However, prior to the federation process happening, a company, school or institution may have manually created MAAs in ABM / ASM for various purposes and want them to keep using Apple’s own authentication system for Apple Accounts in place of authentication using their company, school or institution’s IdP.
This usually applies to MAAs which are used as service accounts in ABM / ASM, where there may only an email alias set up in place of an actual user account set up in the IdP for that MAA. In those scenarios, if there’s no actual user account in the IdP for that MAA, authentication becomes impossible if ABM or ASM is forwarding authentication requests to the IdP.
The best practice in this case is to assign the MAAs in question to a domain which is different from the one being federated. So if you’re planning to federate accounts in the company.com domain, you would set up a different domain in ABM or ASM which is not company.com and assign those MAAs to that different domain. However, there’s an additional step to take as part of this domain re-assignment process. In addition to assigning the MAA to a different domain, you also need to make sure that the associated email address used with the MAA is also not part of the domain you’re planning to federate.
However, once the initial federation process has happened the MAA username and email will now look like this:
Username: something@domain_being_federated.com
Email: something@domain_being_federated.com
Now the previously outside-of-federation-scope MAA ( something@outside_domain_being_federated.com ) is in scope for being federated by having its MAA changed to something@domain_being_federated.com. In turn, this change means that authentication requests for the something@domain_being_federated.com MAA are being sent on to the company, school or institution’s IdP. That IdP may not actually have a user account for the something@domain_being_federated.com MAA or be able to authenticate it, which means you can’t log into that MAA.
How do you address this? My recommendation is that prior to federation, you identify all the MAAs you want to remain outside of scope and assign them an email address which is explicitly outside of the domain you’re planning to federate. For example, if your MAA is currently like this:
As far as I know, this is a one-time change which is made by the initial ABM / ASM federation process. But I do not know that with 100% certainty, so please make sure to ask the folks at Apple about this issue if you’re planning an ABM / ASM federation process and have existing MAAs which may be affected by this.
On macOS, you can use macOS’s unified logging to display commands run using the sudo command line tool. On macOS Sonoma and earlier, both successful and unsuccessful commands were logged by default. For example, here’s what you would see on macOS Sonoma when the following command was run first unsuccessfully and then successfully:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Assuming you ran this command within the past three hours, you could use the following command to see both the successful and unsuccessful attempts to run the command above in the unified logs:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
On macOS Sonoma, you should see both the successful and unsuccessful attempts to run the sudo date command (along with any other successful and unsuccessful attempts to use the sudo command.)
However, on macOS Sequoia if you run the same set of successful and unsuccessful attempts and then run the log command shown above, you would only see the unsuccessful attempts in the unified logs:
Why is this? For more details, please see below the jump.
On macOS Sequoia and earlier, the sudo command’s behavior is defined by the sudoers configuration file stored in the /etc directory. For macOS Sequoia, the following section was added to the /etc/sudoers configuration file:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The !log_allowed setting means that the sudo command should not log allowed, or successful, attempts to run the sudo command. That means only the not allowed, or unsuccessful, commands will get logged to the unified logging.
If you want to configure the logging to use the pre-Sequoia behavior, you can edit the /etc/sudoers configuration file in one of the following ways:
1. Comment out the new !log_allowed line:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Once the /etc/sudoers configuration file has been edited to either comment out or remove the new !log_allowed line, the sudo command on macOS Sequoia should log both successful and unsuccessful commands to the unified logging.
One of the options in Safari is to set a location for file downloads to go to. By default, this is set to the Downloads directory in the logged-in user’s home folder.
An alternative option is to set Safari to always prompt for a download location.
For those who want to set the option for Safari to always prompt for a download location, it is possible to set this on macOS Sequoia using the com.apple.Safari.SandboxBroker preference domain. For more details, please see below the jump.
The relevant preference domain and key values are below:
Preference domain: com.apple.Safari.SandboxBroker
Key: AlwaysPromptForDownloadFolder
Value: Boolean
This can be set for the logged-in user using the following defaults command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This setting can also be managed by a configuration profile. Please see below for an example profile:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
My teammates at Jamf who support Jamf’s own IT (known as Jamf @ Jamf) have developed an innovative method for allowing computer and mobile device smart groups to figure out device membership based on users and groups from an identity provider (like Okta or Entra ID) or an LDAP service (like Active Directory).
Normally, figuring out user and group membership is not a capability of computer and mobile device smart groups but the method the Jamf @ Jamf folks developed leverages MDM configuration profiles to bridge that functionality gap in the following way:
User is assigned an application with compliance policy in the organization’s identity provider.
A Jamf @ Jamf automation system adds User Extension Attribute criteria to a username in scope of a group provided by the identity provider.
A smart user group in Jamf Pro uses that criteria to populate group membership.
The new smart user group is used to scope a configuration profile.
The configuration profile referenced in step 4 above is then deployed to devices that match the smart user group’s membership. Once the profile is deployed, the profile being installed on a device is criteria which can be used by computer and mobile device smart groups. This allows the profile to be the bridge functionality to connect users and user groups from an identity provider or an LDAP service.
In the post I linked to earlier, the configuration profiles created for this purpose are referred to as “dummy profiles”, which are in turn a reference to “dummy receipts”. Dummy receipts are a method for creating a receipt for an installer package installed by Jamf Pro, which likewise can be used as criteria which can be used by computer smart groups.
But what goes in that dummy profile? Ideally, it should be something that deploys no settings at all. The dummy profile’s existence on a device is enough to accomplish the goal of bridging the gap between user and device scoping and for the sake of causing no complications, the profile should exist on the device and otherwise do nothing. Meanwhile, this should be an approach which can be used on all Apple platforms so we need something which can be deployed to all Apple platforms.
After thinking about this for a bit and discussing it with colleagues, it looks like the best way to accomplish this is to build a configuration profile with the following characteristics:
Profile with certificate payload
Certificate payload should have the following:
Self-signed certificate’s public key
Certificate lifespan should be set to an extended period of time, to allow the use of the profile over a long period of time without worrying about the certificate expiring.
The reason to use a self-signed certificate’s public key is that a certificate can only be used for something if you have both the public and private key available. Without the private key being available at some point in the communication process to authenticate the public key as being valid, the public key is effectively useless.
In this case, that’s exactly what we want – we want something useless in the profile’s certificate payload because something useless can’t be used! Using this approach will mean that our configuration profile will deploy no settings to a Mac or mobile device, and a malicious third party won’t be able to use the certificate either because only the public key for it will be available. For more details, please see below the jump.
To assist with creating the self-signed certificate’s public key for our dummy profile’s certificate payload, I’ve written a script which does the following:
1. Generates a self-signed SSL certificate’s public key and associated private key, where the script’s default settings are to create a self-signed certificate with the following characteristics:
Certificate subject name is set to a UUID value.
Certificate key is set to use a 4096-bit RSA key
Certificate lifespan is set to 3652 days.
2. If the self-signed SSL certificate’s public key and private key are successfully created, script displays a message listing public key certificate name with a .cer file extension and the certificate public key’s location on the filesystem.
3. If the self-signed SSL certificate’s public key and private key are not successfully created, script displays an error message.
Note: Both the RSA key bit strength and lifespan are set using variables in the script, so these default settings can be adjusted as needed.
The private keys created by this script are completely disposable. For this purpose, we only want the public keys created by this script because we want a certificate payload which is functionally useless for use with Jamf Pro dummy configuration profiles.
A successful run of the script should produce output similar to that shown below:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Once the public key is created, a new Jamf Pro configuration profile can be created. For this example, I’m setting up a new dummy configuration profile named Advertising Department Software Test Group which will be deployed to Macs.
As part of creating the profile, I’m selecting the Certificate payload option and uploading a certificate public key file created by my script. In this case, the public key file is named 2E69ABC8-3B5C-4F8F-ACE9-BAAAE592BF1C.cer.
Once the public key is uploaded, you will need to set a display name.
In this case, I’m choosing 2E69ABC8-3B5C-4F8F-ACE9-BAAAE592BF1C, which matches the subject name of the certificate.
In the certificate options, uncheck the following options:
Allow all apps access
Allow export from keychain
Both settings refer to the certificate’s private key (which is not being provided with the public key), but not allowing these options for certificates when you don’t have to is a good security-focused habit to cultivate.
Once the public key is uploaded and all the other choices you want are made for the profile, the profile should look like this:
Once deployed to a Mac, the profile should look like this in this example:
For this example, in Keychain Access.app you should see that a certificate named 2E69ABC8-3B5C-4F8F-ACE9-BAAAE592BF1C has been added to the System keychain as a self-signed root certificate without a private key associated with it.
Once the configuration profile is deployed, you can use the profile as part of a device smart group’s criteria.
Now you can apply whatever user-focused criteria you want to the Advertising Department Software Test Group configuration profile’s scoping and the device smart group’s membership will update to only include those devices with the Advertising Department Software Test Group configuration profile installed on them.
The script referenced above is available below, and also on GitHub via the following link:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
I assisted a colleague recently with an interesting request – how to detect if a Mac is only being issued an IPv6 address? In this instance, the use case was for when a Mac is on a network where only IPv6 addresses are being issued by DHCP (so no IPv4 addresses are available.)
The idea was to get a Yes or No answer for whether any of the Mac’s network interfaces were being issued an IPv4 address, where Yes meant that at least one network interface had an IPv4 IP address and No if none of the network interfaces had an IPv4 IP address.
After some research and discussion with colleagues in the Mac Admins Slack, this information was available via the system_profiler command line tool, using the SPNetworkDataType datatype. You can parse the output from the system_profiler tool using the following command to get a count of how many IPv4 addresses are in use by the various network interfaces on a Mac:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
For example, if your Mac has IPv4 IP addresses assigned to both Ethernet and Wi-Fi, you should see output like this to show that your Mac has two assigned IPv4 addresses (one for Ethernet and one for Wi-Fi):
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This same approach works for IPv6 addresses, where you can parse the output from system_profiler using the following command to get a count of how many IPv6 addresses are in use by the various network interfaces on a Mac:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
For example, if your Mac has no IPv6 IP addresses assigned to any network interfaces, you should see output like this to show that your Mac has no assigned IPv6 addresses:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
I’ve used this technique to create Jamf Pro Extension Attributes which can help figure out if a particular Mac has IPv4 or IPv6 addresses assigned to it, which can help in the use case I discussed earlier to help figure out if no IPv4 or no IPv6 addresses are available to a particular Mac. For more details, please see below the jump.
I’ve written two Extension Attributes, one for detecting IPv4 addresses and the other for IPv6 addresses. Here’s how they work:
Detects if an IPv4 / IPv6 network address is being used on a Mac. It returns the value below if one or more IPv4 / IPv6 addresses are detected on the Mac’s various network interfaces.
1
In all other cases, the value below is returned:
0
The Extension Attribute’s returned value ( 1 or 0 ) can then be used as Jamf Pro smart group criteria.