ARD Screen Sharing issue M1 Macs and Monterey

• Turn on Remote Desktop Sharing, allow access for specified users:
  

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

  You must use the -configure, -access and -privs options in a separate command to specify the set of users and their access privileges. For example, this command is for users with the short names "teacher" and “student". It gives them access to observe (but not control) the computer, and to send text messages:
  

  sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users teacher,student -access -on -privs -ControlObserve -ObserveOnly -TextMessages

  Unlike other kickstart options, you can’t combine the allowAccessFor options with other kickstart options. You must use it as per the last two samples above. You may have to call kickstart more than once to finish setting up a computer.

 

@Bol wrote:

I may of worked this one out... I believe permissions are reset after upgrades, although I couldn't find logs to correspond, good luck to me I say.

Testing our workflow and noticed after macOS 11 > 12, ard permissions that reported as on were; control, observe, show observe.
Also testing minor updates but I'm guessing it will be more of the same!

---

I worked out it was due to the api enabling ard observe, it wiped out all the other permissions. For instance, if I change my script to disable the api function and just use the kickatart options, full permissions are back. 

So to enable ARD you need the api once othewrwise you will continue to get the reduced permissions each time the script runs.

---

Good one Bol.. I think I was just doing it wrong, went back to my original commands and now I'm not loosing permissions, all working as expected. Bloody hell

$kickstart -targetdisk / -configure -allowAccessFor -specifiedUsers -privs -all
$kickstart -targetdisk / -configure -access -on -users $localUserName -privs -all -clientopts -setmenuextra -menuextra no -setwbem -wbem yes
$kickstart -targetdisk / -activate -restart -agent -console -menu   

$kickstart -targetdisk / -configure -allowAccessFor -specifiedUsers -privs -all
$kickstart -targetdisk / -configure -access -on -users $localUserName -privs -all -clientopts -setmenuextra -menuextra no -setwbem -wbem yes
$kickstart -targetdisk / -activate -restart -agent -console -menu   

Hi Everyone, 

Thanks everyone for all your scripts and troubleshooting.  It seems for some reason though, that my API call will not work with the $apiuser:$apipass variables in the curl command.  I had to manually type in the username and password, which is fine for me, but if anyone else runs into an issue where the curl command isn't working, that could be a reason.  ANOTHER reason for it not working, could be the complexity of your password.  I was testing the API call using my own JAMF account, which has special characters in the password, and I would get a "10.4.2 401 Unauthorized" failure saying I require authentication.  I made a new API user (which I probably should have done since the beginning), gave the account a password without any special characters, and now the API call works perfectly.

Friends, I finally got to this topic but found that the API command you were using is Deprecated as of now -

"POST
/computercommands/command/{command}/id/{id}
Creates a new computer command. Commands supported: BlankPush(BlankPush Deprecated on 2025-05-27), EnableRemoteDesktop (macOS 10.14.4 and later) (EnableRemoteDesktop Deprecated on 2025-07-10), DisableRemoteDesktop (macOS 10.14.4 and later) (DisableRemoteDesktop Deprecated on 2025-07-10)".
How are you dealing with this now?

I tried kickstart and profile and it didn't bring the expected results