Apple Remote Desktop and Lab computers - Huge issue moving forward from 13.6.2

jalawton
New Contributor II

I am trying to prepare for our next semester.  I do not upgrade instructional machines until the semester is over.  In doing so, I learned that my older Intel machines could be moved up to 13.6.3 and started to do so.  However, for the Lab Instructor machine, this disables valuable features within Remote Desktop for non-admin users.   For my lab instructors logging in via AD, this would be the three options to the: Copy, Install, and Unix. 

Of all these Copy would be my critical loss for a lab instructor.  They can still observe.

13.6.2 still allows my non-admin users access to all these features.

Also, for machines running Sonoma (my M1 machines) I also loss the ability to login to all lab machines at once via my admin account.  This would be using the Send Unix Command of an osascript   The error they return is 143:162: execution error: Not authorized to send Apple events to System Events.

So . . . if Apple Remote Desktop is still part of your environment, please beware!

Jack Lawton
IT Manager
School of Journalism and New Media
The University of Mississippi
5 FARLEY HALL
University, MS 38677-1848
(662) 915-2046
jalawton@olemiss.edu
7 REPLIES 7

Qwheel
Contributor II

I haven't seen much changes in ARD.
But then again, first I push out the MDM command for Remote Desktop during DEP enrollment, then I use a trigger to run kickstart afterwards; the command that specifically grants priveleges to the local admin account.

Perhaps you need to granularly specify the admin user on the client, as a pose to just using the MDM command?

We have to use the MDM command as well as a separate kickstart.  The MDM command seems to want to set the permissions to everyone, we want it to be set to a specific account only with certain permissions so the kickstart command does that for us now that it alone can't enable remote management properly.  If we have to disable and re-enable with the MDM command because it's not working we flush the policy that runs the kickstart command so the permissions stay how we want them.

Dpatschke
New Contributor II

I'm having an issue where ARD is up and running (I can take over a client screen), but trying to send a unix command or copy files to multiple Macs results in an "Unauthorized" message. Can you point me to this 'kickstarter' script that allows you to set permissions? Maybe that's what's wrong here...

Are you able to take over ALL of those client's screens? The "Enable Remote Desktop" command has to be sent to all of the machines you're trying to do that with I'm guessing, and if remote management was enabled with a terminal command at some point you'll need to disable with the management command button and then enable again to all.

That being said you're probably best off looking at the kickstart man page and picking the options that fit what you're wanting to allow or set.

Dpatschke
New Contributor II

ARD was enabled via mass action command in Jamf. I can take over an individual screen, but I cannot send that same machine a file (to the "current user's desktop folder").

Interesting, I was under the assumption that the MDM command for remote desktop was to enable remote management with the permissions set to all users and all abilities enabled.  What you're probably wanting is something like this:

 

Expand

#!/bin/sh

privs="-DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings"

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -access -on -privs $privs -users $USERNAME
fi

 

We use something similar to that within a script that runs on all of our Macs.  You can change the privileges to what you want as they're pretty similar to the checkboxes in the list in the Remote Management settings.  The first command is enabling Remote Management, for specific users.  Then the second command is what puts the specific user in the list and then what privileges it has based on what "privs" contains.