Enable remote management (full control) in Mojave??

[taugust04]

So...

Prepare your institution for iOS 12 or macOS Mojave
[https://support.apple.com/en-us/HT209028](link URL)

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

So any thoughts on how we can enable full control Apple Remote Desktop management in 10.14? Some of us still have computer labs to manage. I know JAMF Remote provides some of this functionality, but the full console where you see all your systems in Apple Remote Desktop still hasn't been replicated nicely by a third party product.

Its hard to believe how many more things we now need to enable manually in the year 2018 for the sake of security. I remember the good old days where I could just a schedule re-image an entire lab without any intervention... sigh... Apple really needs DEP to catch up with their security policies they keep rolling out...

[russeller]

If a config profile can't be used, maybe a third party remote management tool? ¯_(ツ)_/¯

[dmw3]

@taugust04 Had the same thought, how do you set ARD up in a remote environment if you have to set it manually at the mac? Looks like I will be doing some travelling to the far reaches of the state.

How many more configuration items will have to be handled locally in the future?

[MACHOUSTON]

Does anyone tried this old script deployed with JAMF?

i use it on 10.3.6 with no issues

#!/bin/sh
####################################################################################################
#
# Copyright (c) 2010, JAMF Software, LLC.  All rights reserved.
#
#       Redistribution and use in source and binary forms, with or without
#       modification, are permitted provided that the following conditions are met:
#               * Redistributions of source code must retain the above copyright
#                 notice, this list of conditions and the following disclaimer.
#               * Redistributions in binary form must reproduce the above copyright
#                 notice, this list of conditions and the following disclaimer in the
#                 documentation and/or other materials provided with the distribution.
#               * Neither the name of the JAMF Software, LLC nor the
#                 names of its contributors may be used to endorse or promote products
#                 derived from this software without specific prior written permission.
#
#       THIS SOFTWARE IS PROVIDED BY JAMF SOFTWARE, LLC "AS IS" AND ANY
#       EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
#       WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
#       DISCLAIMED. IN NO EVENT SHALL JAMF SOFTWARE, LLC BE LIABLE FOR ANY
#       DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
#       (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
#       LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
#       ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
#       (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
#       SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
####################################################################################################
#
# SUPPORT FOR THIS PROGRAM
#
#       This program is distributed "as is" by JAMF Software, LLC's Resource Kit team. For more
#       information or support for the Resource Kit, please utilize the following resources:
#
#               http://list.jamfsoftware.com/mailman/listinfo/resourcekit
#
#               http://www.jamfsoftware.com/support/resource-kit
#
#       Please reference our SLA for information regarding support of this application:
#
#               http://www.jamfsoftware.com/support/resource-kit-sla
#
####################################################################################################
#
# ABOUT THIS PROGRAM
#
# NAME
#   enableARD.sh -- Enable ARD and Configure Remote Management Settings
#
# SYNOPSIS
#   sudo enableARD.sh
#   sudo enableARD.sh <mountPoint> <computerName> <currentUsername> <targetUsername>
#
#   If the $targetUsername parameter is specified (parameter 4), this is the account that will be 
#   granted access to ARD.
#
#   If no parameter is specified for parameter 4, the hardcoded value in the script will be used.
#
# DESCRIPTION
#   This script enables and configures remote management settings for a user.  There are a number
#   of options that the script is capable of configuring, which should be specified in the privs
#   string.  Please see the kickstart man page for more information.
#
#   The following options are available in the kickstart application:
#
#       -DeleteFiles
#       -ControlObserve
#       -TextMessages
#       -ShowObserve
#       -OpenQuitApps
#       -GenerateReports
#       -RestartShutDown
#       -SendFiles
#       -ChangeSettings
#       -ObserveOnly
#       -mask
#
#   ARD access is granted and priviliges  are assigned to an individual account on computers running 
#   Mac OS X 10.3 and later. It can be used with a hardcoded value in the script, or read in as a 
#   parameter.  Since the Casper Suite defines the first three parameters as (1) Mount Point, 
#   (2) Computer Name and (3) username, we are using the forth parameter ($4) as the passable 
#   parameter.  We do not use $3 since it may not match up to the username that we want to grant
#   access for.
#
####################################################################################################
#
# HISTORY
#
#   Version: 1.1
#
#   - Created by Tedd Herman on August 5th, 2008
#   - Modified by Nick Amundsen on August 5th, 2008
#
####################################################################################################
#
# DEFINE VARIABLES & READ IN PARAMETERS
#
####################################################################################################


# HARDCODED VALUE FOR "USERNAME" IS SET HERE
targetUsername=“$USERNAME ADMIN”


# CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 4 AND, IF SO, ASSIGN TO "USERNAME"
if [ "$4" != "" ] && [ "$targetUsername" == "" ];then
    targetUsername=$4
fi

# DEFINE WHICH PRIVILEGES WILL BE SET FOR THE SPECIFIED USER
privs="-DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings"

####################################################################################################
# 
# SCRIPT CONTENTS - DO NOT MODIFY BELOW THIS LINE
#
####################################################################################################

if [ "$targetUsername" != "" ]; then
    echo "Enabling Apple Remote Desktop Agent..."
    /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers
    echo "Setting Remote Management Privileges for User: $targetUsername ..."
    /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -access -on -privs $privs -users $targetUsername
else
    echo "Error:  The parameter 'targetUsername' is blank.  Please specify a user."
fi

[mm2270]

@MACHOUSTON This discussion is about the upcoming Mojave, still in beta. The above commands still work in High Sierra, but according to Apple will stop working (only work partially) in Mojave 10.14.

[tlagrange]

@MACHOUSTON this won't work because it still uses the "kickstart" command. Take a look towards the end of the script:

echo "Enabling Apple Remote Desktop Agent..."
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers
echo "Setting Remote Management Privileges for User: $targetUsername ..." /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -access -on -privs $privs -users $targetUsername

The kickstart command from now on will only configure access or disable access - but not actually enable access. That will have to be done in the System Preferences "Sharing" pane.

[BOBW]

This is going to be fun, especially when our users don't have admin rights to open the sharing prefs..... can see multiple name changes, VNC enabled devices... caching servers everywhere.....

[a_stonham]

WTF Apple!!! I’m managing 8000+ machines. User approved MDM has been a big enough headache as not only has it decrease security by not allowing us to deploy security tools such as AV with out manually visiting random machines. Now we can’t even provide remote support.

Now we have to decrease security even further by potentially giving out end users admin so they can enable system prefs.

[milesleacy]

Perhaps an unpopular view, but this presents an opportunity to re-evaluate whether remote control is required as opposed to remote viewing.

Perhaps a re-evaluation of stances on local administrative privileges is also in order.

[davidhiggs]

We like the request permission option and have been using it for a while for 1-to-1 Macs. This is not useful in our fully managed 1-to-Many labs though, so Apple needs to implement this as a UAMDM option I think (if not in dev already).

[dan-snelson]

In limited testing, the following appears to still be working via ARD 3.9 (382A110) and VNC from a computer running macOS 10.13.6 (17G2307) to a computer running macOS 10.14.0 (18A384a):

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

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users jamfManagementAccount,localadmin1,localadmin2 -access -on -privs -all -setmenuextra -menuextra no -restart -agent

[ImAMacGuy]

@dan.snelson remote access settings are carried over when upgrading. New deployments/restores will not.

[dan-snelson]

@jwojda Thanks for the heads-up; in this one test case, it was a fresh nuke-and-pave via macOS Recovery with macOS 10.14.0 (18A384a).

[tnielsen]

I suppose JAMF Remote is the only option and this is going to kill ARD usage. What is Apple doing this for? So odd.

[ImAMacGuy]

@tnielsen it seems apple has a longer term strategy/roadmap that they aren't ready to reveal. Over the years I've noticed they take these small steps which seem to be counter productive at the time, but once the grander vision rolls out over the next months/years it starts to make sense, or at least you can see why they did those things.

ARD has had very little development over the years, more of a do the minimum to make it work with the new OS's rather than new features / functionality / fixing annoyances. Back to my Mac has been discontinued, kickstart has reduced functionality...

[blackholemac]

I'm pulling my post and referring people to this thread (where I posted more in depth) on Apple's Developer Forums so it can be hashed out more thoroughly without dancing carefully with NDA issues.

https://forums.developer.apple.com/thread/107632

[sullrich]

@blackholemac That script also invokes kickstart

[blackholemac]

I'm pulling my post and referring people to this thread (where I posted more in depth) on Apple's Developer Forums so it can be hashed out more thoroughly without dancing carefully with NDA issues.

https://forums.developer.apple.com/thread/107632

[tnielsen]

If rich's script works, that's even better than before tbh. I would add all local techs to the group using AD groups then have them remote control using their own credentials rather than built-in admin accounts.

[sullrich]

This is where the confusion lies. According to the Apple support document in the parent post the kickstart command will soon loose the ability to set the remote management features for screen control.

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

[blackholemac]

I'm pulling my post and referring people to this thread (where I posted more in depth) on Apple's Developer Forums so it can be hashed out more thoroughly without dancing carefully with NDA issues.

https://forums.developer.apple.com/thread/107632

[taugust04]

I'm not quite sure why discussion has to be done about this in the Apple Developer forums. Apple had the opportunity to release that information earlier in the beta process, where I think a discussion in the developer forums might have been productive. Apple lost that opportunity by releasing what many of us consider to be a bomb shell weeks from a full release of macOS. In addition, the link where this information was released on is a publicly available knowledge base article, and we can run public betas of macOS 10.4 Mojave without agreeing to any NDAs.

So... I think we should continue to discuss here unless JAMF moderators say we can't. Thank you.

[blackholemac]

I’m fine with folks continuing the discussion...I just don’t want to violate NDA by saying what I really had to say. Check out my link to ADC and see what your thoughts are.

[taugust04]

It took a few days, but I'm happy to see (unfortunately), that I'm not the only one scratching my head on this one.

I'm really starting to come to the conclusion that Apple no longer wants to support customers with computer labs. It would make sense from Apple's educational sales and marketing point of view that everything be geared towards one-to-one programs. This is why I always have a chuckle lately when I hear about "zero touch" deployments. I chuckle because I work in an educational environment where the following to conditions apply:

1. Faculty and staff that want the computer to be pre-configured "out of the box". No wizards or assistants to run through. No waiting for enrollment triggered policies for software to install. No clicking on installers in Self Service. This means IT is going to need to touch these systems before deployment. As recently as two years ago I could drop a factory image onto the system and the rest would be automated without my intervention. No longer.

2. Lab systems that need to be configured by IT that are shared by multiple users. There is no longer a zero touch scenario for these systems with High Sierra, so we've essentially gone backwards there as well.

As more and more of the automation that we had to administer labs is removed from the operating system, it makes it easier to convince customers to migrate away from labs and go towards one-to-one programs, where sales volumes are increased. Yes I know this has a little bit of a conspiracy theory edge to it, but, I'm sure this synergy has been discussed by project managers and developers at Apple when they look at targets and roadmaps for the macOS product.

I know I may be generalizing here but "zero touch" deployments that Apple and JAMF brag about in the year 2018 are clearly geared toward corporate customers where some level of management can fully dictate IT policy to the end users receiving the computers. IE, "If you want a computer, this is how you set it up, end of story. Here's the box. Enjoy!" If we just deployed brand new computers out of the box to the faculty and staff here, we would get very dirty looks. And we don't have administration in place right now where a big change in IT philosophies is on the top of their to-do list. So while I'm flexible and know how we can change our IT philosophy to adapt to Apple's and other vendors changes, the budget, and other people who I'm held accountable to, are not. The end result for us, unfortunately, is Apple's changes are just sucking up people-hours that could be assigned to other tasks and responsibilities.

The loss of ARD will not be the end of the world. JAMF Remote is an okay substitute. The fact that JAMF Remote does not have a console to visually let you know if a system is online or view multiple systems at one time means a little bit more effort in setting up remote control to systems that don't have anyone logged into them. I'm sure many other users are subscribed to better services such as TeamViewer or LogMeIn that have better functionality than Apple Remote Desktop. But Apple Remote Desktop still does a few things better than any other product available, especially when you need to administer or monitor lab/classroom systems. It has been a neglected product, and I would imagine the limitations being implemented mean its going to be discontinued within the next few years. Apple has been hit with a number of "simulated click" security vulnerabilities over the last year, and the perception of increased security at the expense of IT automation and administration is going have more of a positive marketing and financial effect than the other way around. I get it. It is what it is.

@milesleacy raised the question of re-addressing admin access and remote control policies. I'm not sure how that's addressed on the 200 or so publicly available systems I need to manage that this ARD post was initially geared towards. When you ask me that question, your essentially asking me if I should get rid of classroom and labs, and the institution I'm employed at have no interest in doing so. In fact, over the last five years they've increased the number of labs rather than decreased them.

My apologies on the tangent here. It really didn't expand the technical discussion of the problem we're facing with kickstart being limited in Mojave. There's just a lot of frustration lately from this Mac administrator as things continue to get harder when they should be getting easier, and believe me, I'm not the type of person that doesn't like or handle change. It's part of our life as information technologists, and I personally find that part of the job exciting. However in this case, I think the changes occurring here are much more widespread and philosophical and far out of the scope that most information technologists can implement on their own.

End rant. 8-P

[taugust04]

@blackholemac I did take a look at your post. My concern (along with yours) is the warning you're getting when you run those commands. It's probably a loophole that hasn't been closed yet, but only Apple knows. I just don't want to get my hopes up on something they are warning you shouldn't work, and may not work in a future version.

[allanp81]

I use screen sharing/ARD on a daily basis so this is another thing to add to the list of why we must get rid of Apple computers in our environment as they are becoming increasingly impossible to image/manage centrally.

[blackholemac]

@taugust04 that is exactly why I chose to pull my post from the Jamf forum and repost on ADC. I highly encourage people to check out the post and respond to it there if you are an ADC member. Only Apple knows the future of what I discussed there. I’m honestly hoping enough of us will “Me too” that post explaining the situation and maybe just maybe someone official will say something.

When my Apple rep sent me the KBase article explaining the changes in ARD, within a day, I gave him the same write-up I posted on ADC. I hesitate to push anyone at Apple more than that, but it's all I can convey without breaching NDA on pre-release software.

[blackholemac]

Now that Mojave is out NDA is over. It looks like on the shipping build, the directory services technique I referred to in this post was shut down and it was actually as late as Friday seemingly that it was shut down from the timestamps. I was kinda hoping that technique didn't run aground of Apple's new guidelines, but figured it wouldn't last long. Hopefully they will release some sort of profile to allow for that. It's about the only way out now.

[a_stonham]

It looks like the kickstart method is still working at least in 10.14.0.

I tested it today with both a fresh install and an upgrade.

[allanp81]

Have just tried it and you CANNOT enable screen sharing/ARD via the kickstart command. You are met with:

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

[dstranathan]

Im seeing the same results as @allanp81 with Mojave 10.14.0 (18A391). Kickstart no-worky.

Looks like I need to leverage Jamf Remote and TeamViewer more.

[roiegat]

Anyone figure out how to get control working? I set up a computer manually and checked all the buttons to turn on it on, tried to connect from another machine and.....was only able to observe.

[blackholemac]

On my deleted posts, I had originally noted that it worked during testing despite the gnarly warning. I got my inspiration from a post on Rich Troutons blog. Sadly this got shut down in the shipping version.

In reality, our IT group is fine with Jamf Remote alone, but I actually still have teachers that use ARD to interact with lab students. Setting that up now will require turning Remote Management on by hand in the Sharing pane as an admin and setting the permissions on each client in the lab. Any good ideas for that kind of setup?

[allanp81]

I use screen sharing on a daily basis so not being able to enable this will massively affect my ability to work. Thanks Apple!

[sullrich]

So much for zero touch deployments. This really is a inconvenience.

Has anyone opened a ticket with JAMF support to see what their stance is on this?

[allanp81]

I can understand restricting this on a consumer device but to not give admins the ability to enable this is ridiculous. Fingers crossed they'll be a config profile setting that will be able to enable it.

[blackholemac]

I’m hoping for a profile soon myself. I’m also watching the developments on Apple Classroom on Macs. For IT purposes, I know we are on our own unless a profile shows up. For instructional tasks though, this is going to be messy to get a lab up and going.

[sullrich]

This is quite confusing. On Mojave release we just went through a DEP enrollment and the kickstarter binary enabled remote management and I can connect via vnc:// and also through ARD to control the machine. Why are folks seeing different results?

[jheman]

@sullrich

We're seeing differently. I'm uncertain why, although we do get an explicit notice when enabling via kickstart that it is not supported on 10.14+

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

We can connect just fine through VNC but can't drive.

[tnielsen]

Complain to your Apple reps, please. This is just stupid on Apple's part. There's no grandiose plan here, it's pure stupidity.

Btw, you can still turn on everything BUT CONTROL using the same old commands. I suppose that's something.

Are they trying to make me switch to Windows? I'll do it! I swear I'll do it! HOLD ME BACK BROS