ARD and future of kickstart

With the recent announcement of the removal of Back to My Mac and Apple's recommendation to use ARD as a replacement, I was hoping to see some love tossed ARDs way. However, I am hearing rumblings that the kickstart command may also be in the crosshairs for removal/nerfing in the near future. As of Beta 8, I am seeing an ominous cloud on the horizon.


Setting the config and activating appears to go as expected with an added twist:

kickstart -configure -users user -access -on -privs -all -activate

Returns the following results:

Starting...

Warning: macos 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.

Activated Remote Management.
user: Set user remote control privileges.
user: Set user remote access.Done.


The Warning has me troubled.


At this time, Beta 8 is allowing the use of the kickstart command but the command and the System Preferences user interface are not aligning. Nor do I have full control from kickstart. For example, the command above should have checked all the options in the Options... UI. However, when working directly on the machine (including after a reboot), no options are enabled. Yet I can observe the machine. Yes, kickstart started the service and granted me observe rights but not control. Likewise, I can run UNIX commands, copy files, and likely use every other feature of ARD other than control, or let users know when I am observing.


To the end user, the service is on. Yet no options are enabled. Yet I can observe and not show the user that they are being watched. Something is very wrong here.


It is not until physically touching the machine and checking the Remote Management service that control is granted.


For those of us doing fleet deployments, the kickstart command is heavily leveraged during initial device setup to enable and configure the service, commonly through a script delivered by the management tool. Sure the command's syntax is weird and funky, but it is what gives it its charm and it works and has worked for years. To have that function removed would be very impactful. Forcing the physical touching of devices to enable the full function of the service is not an option. This is as bad as the start of 3rd party kernel extensions.


Isn't the entire point of the nexus of DEP, VPP, and an MDM to be able to avoid physical contact with, and manual configuration of, individual devices? With the hoops introduced with secure token and 3rd party extensions, it feels like there is more touch these days then there should be. And now the guidance appears to be to touch every device to enable remote control?!?


Tell me there is a profile in the works to control and enable this service? Removing a function without offering a reasonable replacement seems like a poor decision. Likewise, if ARD is changing, perhaps a beta release with detailed Release Notes telling the community what your vision for the product is would be a good idea. Or, tell me this service is going to be included in a DEP authorization process, allowing DEP enrolled devices the ability to allow an admin at an MDM console to configure and activate this service. Non-DEP'd machines are not my concern. Please don't make fleet deployment more difficult.


Thanks for reading.

Replies

I chuckled when I read, "it is what gives it its charm and it works and has worked for years," because it has most certainly not worked that well for me. Although eventually it did seem to work out … so it's possible that my problems were the initial starting point of users and groups and previous "kickstart" runs.


I have seen improvements in at least one relatively recent ARD update. I also hope that it continues to be configurable via the "kickstart" tool or something better, but the way things are going, everything seems to need user approval. And then mostly through the GUI.

I see the trends also, but there is a difference between edu deployments (with variants across levels), corporate deployments, small business, and consumer. Apple really needs to understand these differences and ensure that we are not going in reverse. The gains Apple has made in fleet deployment is the envy of IT departments everywhere. I can not tell you how many times I've heard, "I wish we had that on Windows" when they see us do a DEP deployment with VPP delivered apps during a Jumpstart. There is usually the audible sound of jaws hitting the table as their narrow Windows-centric brains comprehend the enormity of the solution. (yes, yes, autopilot now exists and is trying to close the gap, but not everyone is in Azure so not everyone has access to autopilot)


Small business (without an MDM) and consumer can have their GUI setup as the usual deployment model is: Here is your machine. Set it up how you want. Good luck. In these deployments, even if there is an IT guy or a consultancy like us doing the initial setup, it remains hands on due to the lack of a management platform. In this case, check the box, click the button.


But in corporate and edu (especially primary education) where the devices are institutionally owned, I see no reason to give the user the rights to approve a device configuration. After all, the device is the property of the organization, the data created on it is the intellectual property of the organization, and the user's actions are subject to oversight by the organization. Things like service configuration and actviation (Remote Management is our current example), FileVault, and 3rd party kexts should be managable and controllable (I know, I know, control is a four letter word in the language of Apple) via an institutionally controlled MDM. Apple seems to have figured out kexts (although there is still some witchcraft involved in the whitelisting process) and approved MDM.


So this brings up a new thought. Maybe we should be asking for new features in ARD instead of begging for continuation of previous function(s)? For example, allow admins to still use kickstart (or another method) to configure and enable the service. But build in a true authorization framework that prompts a console operator when a remote user is about to control/observe the screen. If the goal here is to protect the privacy of the user's active session, then enhance ARD so a tech can request view/control of an active session while allowing institutions to still centrally manage the configuration of the service. This would allow the service to be enabled and controlled, allow the admin to login and control an independent session, and protect the provacy of the user's experience by notifying the user that someone is attempting to view/control, giving the active console user the ability to decide if they want to allow the operation to continue.


It's been a long time (excluding the recent secure token chaos) since I've needed to make excusses and craft workarounds for things that should just work. I don't want to go back to those days. kickstart might seem like a strang hill to die on, but as you said, "everything seems to need user approval" and that is what is keeping me up at night worrying about future mass deployments. I don't want to go back to touching every device during a deployment. I've become to lazy, ah... efficient, in the DEP/VPP/MDM model.

Given article https://support.apple.com/en-us/HT209028


Given that Apple's Developer Forums is an appropriate place to discuss Mojave without breaking NDA


In Mojave beta 10, I can still get kickstart to work and do my bidding fairly well by following this technique to prepare a fresh machine:


1. Wiped hard drive and installed Mojave DP and created the admin account (localadmin) through Setup Assistant.


2. Upgraded to DP 10, restarted and logged in


3. Opened System Preferences to Users and Groups and created an additional user, a standard account named “ard”


4. Found a useful script written by a well-known Mac Admin that basically creates the groups com.apple.local.ard_admin, com.apple.local.ard_interact, com.apple.local.ard_manage and com.apple.local.ard_reports on the local Mac if they don't exist already. Within the same script, you declare hard coded values for the user you wish to add and the group you wish to add it to.


Documentation on these groups and their permission levels can be found in older Apple documentation for ARD 3.x from years ago.


The script then runs the following to add the user to the group you specified in the hard coded value

/usr/sbin/dseditgroup -o edit -a "$youruser" -t user "$yourgroup"


Finally it runs:


/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setdirlogins -dirlogins yes

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent


4A. Ran the script successfully for my "localadmin" user, but was presented a grisly warning "Warning: macos 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.”


4B. Promptly ignored the warning and ran the script again to add my "ard" user to a different group. Again success, but again grisly warning. Again ignored it.


5. Went over to a different Mac with the latest ARD admin installed and was successfully able to control the machine that kickstart was run on as both users. Same if I quit ARD and use vnc://<kickstartcomputerIPAddress> from Go --> Connect to Server


It sounds great that this works...the big question is...will Apple kill this functionality before Mojave ships? I hope not as K-12 school administrators still need to remotely control machines in public labs.