Last week, Apple posted one of the first support articles specifically for macOS Mojave:
- Apple Support: Prepare your institution for iOS 12 or macOS Mojave
This article is not quite the bombshell that the infamous HT208020 for High Sierra is. However, in contains a few firecrackers which will affect many Mac deployments. You can test deployments with the public beta or developer release of Mojave right away.
Update: Apple has posted a new article describing how to avoid this with a Privacy Configuration Profile. Ben Toms has a wonderful summary.
The piece of information I want to focus on for this post affects Apple Remote Desktop client configuration (called ‘Remote Management’ in the ‘Sharing’ preference pane). Mac Admins have been using the command line tool kickstart to enable and configure Apple Remote Desktop access on clients with scripts through a management system.
- Apple Support: Use the kickstart command-line utility in Apple Remote Desktop
- Scripting OS X: Control Apple Remote Desktop Access with Munki
In macOS Mojave, Apple will restrict the functionality of
For increased security, using the kickstart command to enable remote management on a Mac will only allow you to observe it when sharing its screen. If you wish to control the Mac while sharing its screen, enable remote management in System Preferences.
This continues Apple’s effort to require user interaction for every configuration that can provide on going access to sensitive data or the system a Mac, like User-Approved MDM and the new privacy controls.
What this means for Admins
If you rely on Apple Remote Desktop for remote control and remote assistance, this will disrupt your installation workflow. The
kickstart tool will enable ARD access and configure the users but not enable any access privileges.
You get a nice (red) warning in the shell and when you go into the Remote Management preference pane, no active access is enabled. You can only manually enable the access privileges in the ‘Sharing’ preference pane, which requires administrator privileges to unlock.
You can still use
kickstart to disable Remote Management access.
This limitation extends to Screen Sharing. You can enable Screen Sharing (when ARD/Remote Management is disabled) from the command line with:
$ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.screensharing.plist
You have to restart System Preferences to pick up the change in the UI. This command will enable Screen Sharing access, but it will be observe only. (Note: you can use
launchctl unload ... to disable.)
When you enable Screen Sharing manually in the ‘Sharing’ preference pane, it will grant full access.
I have (so far) been unsuccessful in determining where the restricted access setting is stored. My suspicion is that the TCC database is involved. If the setting is controlled from a protected settings file or database, then you can at least read that to determine the state and use that information to trigger a notification to the user that action is required. So far, however, I cannot get this information yet.
If you find any means of determining the state, please let me know and I will update this post.
Unfortunately, Apple has provided no alternative means of controlling screen sharing or ARD with configuration profiles from a UAMDM, leaving admins stranded without an automated solution.
Update: Rich Trouton’s recent post on an managing ARD access with with user groups is of interest to admins encountering this problem.
Admins that require ARD or Screen Sharing will have to rely on users actively enabling the settings. To make things worse, unlike the approval of an MDM profile or a kernel extension, the ‘Sharing’ preference pane is locked for standard (non-admin) users.
You can either provide a way for users to be temporarily promoted to admin or modify the Authorization database to allow standard users to unlock the ‘Sharing’ pane. However, unlocking the Sharing pane allows access to many more critical services, which is untenable from a security perspective.
It will have to be seen how this affects third party remote access applications. I have tried setting up Edovia Screens Connect on my Mojave virtual machine, but that currently uses the native Screen Sharing/Remote Management client, so it will encounter the same limitations. Other third party tools may have their own clients.
As usual, please, provide your feedback to Apple through the usual channels (macOS beta Feedback app, bugreport, your Apple representative, SE or technical support).