babgond

One of the changes Apple has introduced with macOS Tahoe is the ability to use SSH at the unified login screen available on Apple Silicon Macs. Apple has built on this to provide a way to allow a FileVault-encrypted Mac to be unlocked via an SSH session. Apple mentions this new capability as part of the following KBase article:

• What’s new for enterprise in macOS Tahoe 26: https://support.apple.com/124963

As part the KBase article, the following man page is referenced:

apple_ssh_and_filevault

This can be accessed using the following command:

For more details, please see below the jump.

To unlock FileVault on macOS Tahoe using SSH, you can use the procedure described below:

Pre-requisites:

• Second computer available which can run SSH.
• Target Mac must be using an Apple Silicon processor.
• Target Mac must be running macOS Tahoe or later.
• Target Mac must have FileVault encryption enabled.
• Target Mac must have SSH enabled.

1. Connect from the second computer to the target Mac using the username and network address of the target Mac.

For this example, the target Mac has the following account and network address:

• Account: username
• Network address: computername.local

In this example, the following command is being used to connect from the second computer to the target Mac using SSH:

2. When you connect, you should be informed that the target Mac is locked and that you’ll need to a local username and password to unlock it.

In this example, we’re connecting with the username of an account which is enabled on the Mac to unlock FileVault. Because of this, we should only need to provide the password for that account.

3. Once the password has been provided, the Mac unlocks FileVault and automatically closes the SSH connection between the second computer and the target Mac.

On the target Mac, you should see activity similar to this occurring on the login screen.

4. After a short amount of time, the target Mac should be unlocked. At this point, you should be able to connect again from the second computer to the target Mac using SSH and have access to all expected functionality.

For those who wanted a copy of my talk on MDM and DDM at Jamf Nation User Conference 2025, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/JNUC2025PDF
• Keynote: https://tinyurl.com/JNUC2025Keynote

Apple has provided settings for suppressing various screens which appear the first time you log into a Mac and sometimes also after an OS update. In recent OS releases, Apple has been using the following preference domain and key for this:

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

Apple has the SkipSetupItems key set to store its settings in an array, as described below:

Why this is important is that the array and its list of strings is what’s being interpreted as the setting for the SkipSetupItems key in a management profile. This detail is important in itself because it can lead to multiple management profiles managing what macOS sees as the same setting.

In a case where you have two or more management profiles managing the same setting differently, you get what Apple calls indeterminate or undefined behavior. In a situation like this, macOS may randomly choose to apply one of the settings and ignore any others, or just ignore all of the settings. For more details, please see below the jump.

As an example, you may deploy a management profile to stop the Your Mac is Ready for FileVault screen from appearing.

In that case, there’s now a profile which is deploying the following setting in the SkipSetupItems array:

Later, you may choose to deploy a management profile to stop the Software Update Complete screen from appearing.

In that case, there’s now a management profile which is deploying the following setting in the SkipSetupItems array:

Once the second management profile to suppress the Software Update Complete screen has been deployed, you may now see the following behavior occurring randomly on the Macs it was deployed to:

• The Software Update Complete screen appearing.
• The Your Mac is Ready for FileVault screen appearing.
• Both the Software Update Complete and Your Mac is Ready for FileVault screens appearing.

The fix for this situation is to not deploy separate management profiles containing settings for the SkipSetupItems key. Instead, combine the settings into one management profile with multiple entries in the array. For example, to suppress both the Software Update Complete and Your Mac is Ready for FileVault screens, you would deploy a single management profile with the following settings in the SkipSetupItems array:

For macOS Tahoe 26.0, the following management profile should stop the following screens from appearing:

• Analytics
• Apple Intelligence
• Software Update Complete
• Update Your Mac Automatically
• Your Mac is Ready for FileVault
• Welcome

Over the years, Apple has introduced a number of screens which appear the first time you log into a Mac. Among those which appear following an upgrade to macOS Tahoe 26.0 is the Software Update Complete screen, which notifies you that the Mac has been upgraded to macOS Tahoe.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Software Update Complete screen on macOS Tahoe 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: UpdateCompleted

The profile is available on GitHub via the link below:

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

One of the management options Jamf Pro provides with Blueprints for macOS Tahoe is using DDM declarations to manage settings which can used by Apple’s Safari web browser. Let’s see how this works using by distributing the following Safari settings:

• Allow History Clearing: Set to false, to disable clearing history in Safari.
• Allow Private Browsing: Set to false, to disable private browsing in Safari.

For more details, please see below the jump.

Safari settings can be managed using DDM declarations at the user level, which like with user-level MDM profiles, means that they can be applied only to MDM-managed users. When dealing with local accounts, this means that only the local user account which installs the MDM enrollment profile becomes the MDM-managed user. For our purposes here, this means that Safari bookmark management declarations can only be applied to the MDM-managed user and any other local accounts on the Mac cannot have their Safari settings managed.

As of Jamf Pro 11.20.1, there is not a Blueprints template available for creating blueprints which manage Safari 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. Give it a name when prompted and click the Create button. For this example, I’m using Safari Settings.

5. You should see an unconfigured Blueprint. Scroll down in the list on the right-hand side of the browser window to locate the Safari settings component.

6. Click on the Safari settings component and drag the Safari settings component to the Declaration group section.

7. Mouse over the Safari settings component and you will see a Configure button appear. Click the Configure button.

8. To add the settings for the Safari settings in this example, set the following settings as follows:

• History clearing: Set to Disallowed
• Private browsing: Set to Disallowed

9. Once all the settings choices have been made and verified, click the Add 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 Safari Settings Deployment Group.

14. Once everything has been configured, 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 Safari Settings blueprint as being deployed.

On your managed devices, you can verify that the new Safari settings management configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom.

In the case of this example, you should see a User Declarations section with a listing for Safari Settings.

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

• Allow History Clearing: No
• Allow Private Browsing: No

You should also be able to open Safari and verify that the desired settings are being applied by trying to clear Safari’s history and opening a private window.

One of the management options Jamf Pro provides with Blueprints for macOS Tahoe is using DDM declarations to manage the bookmarks which can used by Apple’s Safari web browser. Let’s see how this works using by distributing the following links as Safari bookmarks:

• Company Name Intranet: https://intranet.company.com
• Company Name Developer Site: https://developer.company.com
• Company Name Travel: https://travel.company.com

For more details, please see below the jump.

Safari bookmarks can be managed using DDM declarations at the user level, which like with user-level MDM profiles, means that they can be applied only to MDM-managed users. When dealing with local accounts, this means that only the local user account which installs the MDM enrollment profile becomes the MDM-managed user. For our purposes here, this means that Safari bookmark management declarations can only be applied to the MDM-managed user and any other local accounts on the Mac cannot have their Safari bookmarks managed.

As of Jamf Pro 11.20.1, there is not a Blueprints template available for creating blueprints which manage Safari bookmarks 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. Give it a name when prompted and click the Create button. For this example, I’m using Safari Bookmarks.

5. You should see an unconfigured Blueprint. Scroll down in the list on the right-hand side of the browser window to locate the Safari bookmarks component.

6. Click on the Safari bookmarks component and drag the Safari bookmarks component to the Declaration group section.

7. Mouse over the Safari bookmarks component and you will see a Configure button appear. Click the Configure button.

8. At this point, you will see an Managed Bookmarks section without any listed bookmarks. Click the Add bookmark group button.

9. To add the settings for the Safari bookmarks in this example, set the following entries as follows:

• Title: Company Name
• Group identifier: 875D8D76-20EE-43DB-B874-9FC9F1CCC3A9

Note: The Group identifier field can be any unique string and the only thing that matters is that it is unique. Acceptable unique strings include the following:

• 875D8D76-20EE-43DB-B874-9FC9F1CCC3A9
• Finance Department Bookmarks
• Man I Love Donuts Especially Those With Chocolate Frosting

If the string is not unique, the bookmarks which have a not-unique group identifier will be composited together into one set of bookmarks.

Bookmarks:

• Company Name Intranet: https://intranet.company.com
• Company Name Developer Site: https://developer.company.com
• Company Name Travel: https://travel.company.com

10. Once all the settings choices have been made and verified, click the Add group button.

11. If everything looks right, click the Save button.

12. 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.

13. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Safari Bookmarks Deployment Group.

14. Once everything has been configured, 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 Safari Bookmarks blueprint as being deployed.

On your managed devices, you can verify that the new Safari bookmark configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom.

In the case of this example, you should see a User Declarations section with a listing for Safari Bookmarks.

If you click on the Safari Bookmarks listing, it should report the following:

Present

You should also be able to open Safari and verify that the desired bookmarks are appearing in Safari’s Bookmarks menu.

Every so often, something gets added to macOS and enabled by default where I wish it was off by default. In macOS Tahoe, that’s the appearance of desktop widgets automatically on login.

This behavior is managed in System Settings: Desktop & Dock and is listed as the Show Widgets setting. This has two selectable settings:

• On Desktop
• In Stage Manager

The default behavior is for both the On Desktop and In Stage Manager options to be enabled.

To prevent desktop widgets from appearing on your desktop, disable the On Desktop option.

Fortunately for my preferences, the desktop widgets behavior can also be controlled via the following setting:

• Domain: com.apple.WindowManager
• Key: StandardHideWidgets
• Value: Boolean

To disable desktop widgets and prevent them from appearing, run the following command as the logged-in user:

To enable desktop widgets to appear again, run the following command as the logged-in user:

In my case, I wanted to disable desktop widgets and prevent them from appearing so I’ve also written a profile which can enforce this. It’s available via the link below:

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

As part of the release of macOS Tahoe 26.0, Apple has removed built-in support for FireWire devices from macOS. This removal of support can be verified by looking in System Profiler.

For more details, please see below the jump.

On macOS Sequoia 15.7.0, System Profiler shows an entry for FireWire.

On macOS Tahoe 26.0, System Profiler no longer shows an entry for FireWire.

Running the following command on both macOS Sequoia and macOS Tahoe also shows that SPFireWireDataType has been removed from macOS, which means that System Profiler is not longer gathering data from that area:

Over the years, Apple has introduced a number of screens which appear the first time you log into a Mac. Among those which appear as of macOS Tahoe 26.0 is the Your Mac is Ready for FileVault screen, which asks if you want to enable FileVault if it is not already enabled.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress this screen on macOS Tahoe 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: FileVault

The profile is available on GitHub via the link below:

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

Mobile device management (MDM) has the concept of what’s referred to as channels, which defines how management settings can be delivered:

• Device channel: Allows MDM settings to be delivered to devices and apply device settings to the entire device.
• User channel: Allows MDM settings to be delivered to user accounts on devices and apply user settings just to the relevant users.

When enrolling a device into an MDM server using device enrollment, a couple of things happen as part of the MDM enrollment process:

• The device becomes a managed device.
• The local user account which installs the MDM enrollment profile becomes a managed user.

There’s additional details on what it means to be a managed user, but one of the most important is that in this context, being a managed user means that the local user account can be managed with settings delivered via the user channel. Other local accounts on the Mac are not able to access the user channel and cannot be managed by user level settings.

Declarative device management (DDM) has these same concepts of device channel and user channel and as far as I can tell, it works exactly the same as it does for MDM:

• Device channel: Allows DDM declarations to be delivered to devices and apply device settings to the entire device.
• User channel: Allows DDM declarations to be delivered to MDM-managed user accounts on devices and apply user settings just to the relevant users.

What this means is that a MDM-managed user account is able to be managed via settings delivered by the DDM user channel and other accounts which are not MDM-managed are not part of the DDM user channel and cannot be managed by DDM user level settings.

An example of DDM management which uses the user channel are the Safari extension management options. If you check the documentation, as of September 9th, 2025, Safari extension management has the following configuration availability listing:

• Allowed in supervised enrollment: iOS, macOS, Shared iPad, visionOS
• Allowed in device enrollment: NA
• Allowed in user enrollment: NA
• Allowed in local enrollment: NA
• Allowed in system scope: iOS, visionOS
• Allowed in user scope: macOS, Shared iPad

This means that DDM Safari extension management is using the device channel on the following Apple platforms:

• iOS
• visionOS

DDM Safari extension management is using the user channel on the following Apple platforms:

• macOS
• Shared iPad