Suppressing Apple Intelligence notifications on macOS Sequoia

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.

Managing Apple Intelligence features on macOS Sequoia 15.1

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.

Disabling iPhone mirroring on macOS Sequoia

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.

Managed Apple Accounts which were out of scope for ABM or ASM federation may be changed to be in scope by the federation process

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.

Why is this? As part of the documentation Apple provides for the federation process , there’s this note in the Before you begin section:

For existing users with an email address in the federated domain, their Managed Apple ID is automatically changed to match that email address.

What’s this mean? It means that the existing MAA may be set up with the following username and email:

• Username: something@outside_domain_being_federated.com
• Email: something@domain_being_federated.com

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:

• Username: something@outside_domain_being_federated.com
• Email: something@domain_being_federated.com

Change it to something like this:

• Username: something@outside_domain_being_federated.com
• Email: something@work_email_domain_which_is_not_the_domain_being_federated.com

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.

Successfully run sudo commands are no longer logged by default to unified logging on macOS Sequoia

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:

sudo date

view raw

gistfile1.txt

hosted with ❤ by GitHub

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:

log show –style syslog –predicate 'process == "sudo" AND composedMessage CONTAINS "COMMAND"' –last 3h

view raw

gistfile1.txt

hosted with ❤ by GitHub

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.

Setting Safari to always prompt for download location on macOS Sequoia

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.

Using certificate public keys to create dummy MDM configuration profiles for Jamf Pro device smart group scoping

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:

1. User is assigned an application with compliance policy in the organization’s identity provider.
2. A Jamf @ Jamf automation system adds User Extension Attribute criteria to a username in scope of a group provided by the identity provider.
3. A smart user group in Jamf Pro uses that criteria to populate group membership.
4. 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:

1. Profile with certificate payload
2. 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.

Detecting via Jamf Pro if a Mac is being issued an IPv4 or IPv6 address

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:

/usr/sbin/system_profiler SPNetworkDataType | /usr/bin/grep -c "IPv4 Addresses:"

view raw

gistfile1.txt

hosted with ❤ by GitHub

 

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):

	username@computername ~ % /usr/sbin/system_profiler SPNetworkDataType | /usr/bin/grep -c "IPv4 Addresses:"
	2
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

 

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:

/usr/sbin/system_profiler SPNetworkDataType | /usr/bin/grep -c "IPv6 Addresses:"

view raw

gistfile1.txt

hosted with ❤ by GitHub

 

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:

	username@computername ~ % /usr/sbin/system_profiler SPNetworkDataType | /usr/bin/grep -c "IPv6 Addresses:"
	0
	username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

 

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.

 

Session videos and slides available from MacSysAdmin 2024

The documentation from MacSysAdmin 2024 is available, with the session slides and videos being accessible from the link below:

http://documentation.macsysadmin.se

The video of my session is available for download from here:

macOS Application Packaging 101: https://docs.macsysadmin.se/2024/video/Day1Session6.mp4

I also like to thank Patrik Jerneheim again for inviting me to speak at this year’s MacSysAdmin.

Slides from the “macOS application packaging 101” session at MacSysAdmin 2024

For those who wanted a copy of my installer packaging talk at the MacSysAdmin 2024 conference, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/MSA2024PDF
• Keynote: https://tinyurl.com/MSA2024Keynote