Apple Remote Desktop, Screen Sharing and Mojave

Last week, Apple posted one of the first support articles specifically for 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.

In macOS Mojave, Apple will restrict the functionality of kickstart:

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.

Workarounds

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

Published by

ab

Mac Admin, Consultant, and Author

6 thoughts on “Apple Remote Desktop, Screen Sharing and Mojave”

  1. I haven’t seen any issues with connecting to Mojave test Macs with screensharing and controlling the screen. We normally configure it to require the end user to grant permission to connect, and that works as expected.
    I can also configure specific users to be allowed connect, and that works as well.

    1. Hi Greg,

      can you share your configuration how to enable remote access with end user require to grant permission?

      Thanks,
      Philipp

  2. Continually impressed with your posts, info, and willingness to share. Its important you know how much it helps individuals and the community. So many changes happening so quickly, I still see an almost daily stream of Mac admins stumbling into the slack asking questions about their workflows unaware of the massive shifts in Apple’s technology decisions. Its good to have you on our side.

  3. I seem to be able to observe/control a system ok, but in my ARD list, it shows ‘access denied’, which in turn doesn’t allow me to push a Unix script, push a package, or even wake the machine. It’s set in System Prefs already (every box checked) under Remote Management. Am I missing something?
    Thanks!

    1. The connection from the ARD app to the client has gone stale. There are many reasons this can happen. You may need to either restart the agent software on the client (with kickstart) or remove the client from ARD and add it back.

Comments are closed.