Skip to main content

Hi All,

I’ve come across a strange issue stopping me rolling out M1 MacBook Pros to our users to replace older Intel machines.

I’m unable to use ARD to screen share onto an M1 Mac in these scenarios:

Filevault on and Firewall on

Filevault on and Firewall off

 

Works if Filevault is off and Firewall on or Filevault is on and Firewall is off.

I’ve tested a MacBook Pro 14inch and 16inch M1 running Monterey 12.0 through to 12.2 with the same result. 

If I test an Intel Mac with the same Filevault/Firewall on, ARD works no problem.

 

Not sure if I’ve missed something daft on these M1 machines or a bug in Monterey on Apple silicon.

 

Cheers,

Robert.

Without knowing what commands you are running I found the opposite happening for me.


# Enable ARD
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -privs -DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings -clientopts -setmenuextra -menuextra no

# Restart ARD
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers -restart -agent -menu

# Enable SSH
systemsetup -setremotelogin on
# Enable ARD
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -privs -DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings -clientopts -setmenuextra -menuextra no

# Restart ARD
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers -restart -agent -menu

# Enable SSH
systemsetup -setremotelogin on
  • 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   

 

@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   

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.

Reply


Terms & ConditionsCookie settings