Jamf Nation Community

prujamf · ‎02-07-2022

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.

Bol · ‎06-11-2022

Also, thanks to all the community bloggers and their amazing ideas that i've taken snippets of code from!

a_bautista · ‎06-16-2022

Were you able to resolve this? I'd like to enable FileVault but it turns on the firewall blocking all incoming connections. Only seeing this in M1 Macs on Monterey.

Bol · ‎06-16-2022

I've never come across that message sorry.

At a bare minimum, all you need for all users to observe is the config profile scoped to the device and the enable remote desktop command sent once from Jamf. If that still fails on a freshly enrolled machine then there may be some restriction / policy preventing this from working.

kwoodard · ‎06-30-2022

Well, I discovered a very strange work around for the issues I have been seeing. If I uncheck remote management, check "Screen Sharing and select all users" then check remote management again, and reselect all the options...I can connect with ARD. So strange.

jkline19 · ‎07-01-2022

I was recently able to get this working in Jamf Pro, and wanted to add a couple notes for anyone looking to enable Remote Management via script in the future.

First, thank you @Bol for providing your script! It was very helpful as a basis to set this up in our environment. However, some tweaks were required to get it to work. My notes are below.

With Basic authentication being deprecated later this year, we decided to use the latest getBearerToken and invalidateToken functions instead. The latest bearer token functions can be found here: https://developer.jamf.com/jamf-pro/recipes
The new getBearerToken and invalidateToken functions require login credentials for a user in Jamf Pro. An API account will need to be created for this purpose. While no account permissions are required to get a token or invalidate a token, some permissions are required to enable Remote Management using this script. The minimum required permissions are as follows: Create Computers, Read Computers, and Send Computer Remote Desktop Command
When we tested deploying this policy to M1 Macs running Monterey, the SetAppleRemoteDesktopViaKickstart function used in conjunction with the SetRemoteDesktopViaAPI function did not allow VNC connections. It did work properly if we unchecked then checked Remote Management. By removing the SetAppleRemoteDesktopViaKickstart function from the script, Remote Management was properly enabled from the API, and we were able to connect via VNC without issue. @kwoodard Try removing the SetAppleRemoteDesktopViaKickstart function and see if that solves your problem.

I hope this helps! Thanks again to everyone in this thread for taking the time to help get this set up for others!

kwoodard · ‎07-01-2022

Care to share your script? Would love to give it a try in my environment.

jkline19 · ‎07-01-2022

The script is below. Be sure to supply the appropriate information for parameters 4, 5, and 6. Parameter 4 is your API account username, parameter 5 is your API account password, and parameter 6 is your local administrator account username.

#!/bin/bash
#	B0L ARD Screen Share / Remote Desktop via Jamf Pro API
#	- Added bearer token support as Classic API due for retirement
#	- Added print of access group (to see who can ARD)
#	- Removed hard code of Jamf Pro URL for plist preference
#	- Overkill add Jamf Pro into groups / SSH / ScreenShare
error=0

#Variable declarations
username="$4"
password="$5"
localUserName="$6"
bearerToken=""
tokenExpirationEpoch="0"
jamfbin=$(/usr/bin/which jamf)
jamfpro_server_address=$(/usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf jss_url); jamfpro_server_address=${jamfpro_server_address%%/}
group=com.apple.access_screensharing
machineUUID=$(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | /usr/bin/awk '/IOPlatformUUID/ { gsub(/"/,"",$3); print $3; }')

GenerateAuthToken () {
	response=$(curl -s -u "$username":"$password" "${jamfpro_server_address}"/api/v1/auth/token -X POST)
	bearerToken=$(echo "$response" | plutil -extract token raw -)
	tokenExpiration=$(echo "$response" | plutil -extract expires raw - | awk -F . '{print $1}')
	tokenExpirationEpoch=$(date -j -f "%Y-%m-%dT%T" "$tokenExpiration" +"%s")
}

ExpireAuthToken () {
	responseCode=$(curl -w "%{http_code}" -H "Authorization: Bearer ${bearerToken}" ${jamfpro_server_address}/api/v1/auth/invalidate-token -X POST -s -o /dev/null)
	if [[ ${responseCode} == 204 ]]
	then
		echo "Token successfully invalidated"
		bearerToken=""
		tokenExpirationEpoch="0"
	elif [[ ${responseCode} == 401 ]]
	then
		echo "Token already invalid"
	else
		echo "An unknown error occurred invalidating the token"
	fi
}

GetJamfProComputerID () {
computerrecord=$( /usr/bin/curl --request GET \
	--url "${jamfpro_server_address}/api/v1/computers-inventory?section=USER_AND_LOCATION&filter=udid%3D%3D%22${machineUUID}%22" \
	--silent \
	--header "Authorization: Bearer ${bearerToken}" )
computerID=$( /usr/bin/osascript -l 'JavaScript' -e "JSON.parse(\`$computerrecord\`).results[0].id" )
}

SetJamfProConfig () {
sudo defaults write /var/db/launchd.db/com.apple.launchd/overrides.plist com.apple.screensharing -dict Disabled -bool false
sudo /bin/launchctl load -w /System/Library/LaunchDaemons/com.apple.screensharing.plist
sudo /bin/launchctl load -w /System/Library/LaunchDaemons/ssh.plist
/usr/sbin/dseditgroup -o edit -a "$localUserName" -t user admin
/usr/sbin/dseditgroup -o edit -a "$localUserName" -t user com.apple.access_ssh
/usr/sbin/dseditgroup -o edit -a "$localUserName" -t user com.apple.access_screensharing
$jamfbin startSSH
}

SetAppleRemoteDesktopViaAPI () {
/usr/bin/curl --request POST \
	--url "${jamfpro_server_address}/JSSResource/computercommands/command/EnableRemoteDesktop/id/$computerID" \
	--silent \
	--header "Authorization: Bearer ${bearerToken}"
}

GetGroupMembership () {
echo "Screen sharing ACL members:";
for i in $(dscl . list /users); do [[ $(id -nG "$i" | grep $group) ]] && echo "$i"". "; done
#	$kickstart -computerinfo -1 "$text"
}

GenerateAuthToken
GetJamfProComputerID
SetJamfProConfig
SetAppleRemoteDesktopViaAPI
GetGroupMembership
ExpireAuthToken

exit $error

Bol · ‎07-01-2022

@jkline19 No worries at all and thank you for sharing the Jamf recipe, I had not come across that at all.. Kudos!

When enabling ARD via the api, I understand it turns on remote management for all users with only observe and control permissions which didn't meet our requirements.

Pairing with the kickstart command allowed us to specify one user and their access controls.

jkline19 · ‎07-01-2022

I suppose the appropriate method would depend on your environment. We are mostly on Windows with a small amount of Macs, so VNC functionality was most important. We do not use ARD for remote management.

Cheers, and have a great weekend!

Bol · ‎07-01-2022

Oh vnc, you needed to add these switches to the command line. I kept this page in the initial script so I could always reference back to it, very handy. You too, cheers!

https://ss64.com/osx/kickstart.html

   -configure -clientopts -setreqperm   -reqperm    yes|no     ## Allow VNC guests to request permission
   -configure -clientopts -setvnclegacy -vnclegacy  yes|no     ## Allow VNC Legacy password mode
   -configure -clientopts -setvncpw     -vncpw      mynewpw    ## Set VNC Legacy PW

dstranathan · ‎07-01-2022

One trick I learned from Richard Purves on how to acquire the target computer's Jamf computer record ID using a custom MDM profile...

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>JamfProID</key>
<string>$JSSID</string>
</dict>
</plist>

Make the pref domain in the profile something unique like "com.my-org.jamf".
This will generate an XML plist with a single key/value pair at /Library/Managed Preferences/com.my-org.jamf.plist.
Then you can read it back as a variable anytime you need it to reference it from a script/policy on the Target Mac like this example:

COMPUTER_RECORD_ID=$(defaults read "/Library/Managed Preferences/com.my-org.jamf.plist" JamfProID)

Bol · ‎07-01-2022

Oh that's beautiful, kudos! :D Thank you for sharing!!

DaddyFixIT · ‎09-30-2022

I have the same issue but don't use MDM. My ARD source iMac is intel running macOS 12.6; My ARD target is M1 running macOS 12.2.1; When I try Observe or Control, all I get is a black screen, but ARD shows that the computer is on Login Window.

rcole · ‎09-30-2022

Yeah, this issue is def on Apple and the new changes. None of the previous methods will work. You have to Enable ARD via MDM or use API or some type of scripting that ties into your MDM to execute this now. It’s a real bummer, but understandable from a security/privacy standpoint.

Bol · ‎10-01-2022

If you aren't using MDM then the only option is to enable via System Preferences, locally on the machine.

That is by design, trying to automate this remotely via script will give you the blank screen described.

I setup three Mac Mini's during the week with no MDM, enabling remote management before deploying the machine worked.

https://support.apple.com/en-au/guide/mac-help/mh11851/mac

DaddyFixIT · ‎10-03-2022

Hi Bol, I've done exactly that. I enabled Remote Management locally on the machines before deployment. I found out when I was trying to remote connect to upgrade OSes, that I was getting black screen.

Bol · ‎10-05-2022

That's annoying, weird too. Well, if the target machines aren't controlled by MDM and remote management is already set I would try two things;

(If local access is an option)

- Uncheck then re-enable Remote Management. Then remove and re-add any users in the Allow Access For window, it should prompt again for permissions to be selected. Also set in the options but I think that's only if you have all users selected.

(If remote is the only option)

- Do you have remote login enabled?

- ssh into the machine and essentially do the same as above but using the command line equivalents. eg. Kickstart comand to remove ard settings / preferences and re-add users, set permissions etc.

Plenty of examples in the scripts above, good luck!

DaddyFixIT · ‎10-07-2022

So, I ended up visiting the M1s physically and upgraded them to macOS 12.6, and unchecked/rechecked Remote Management under System Preferences -> Sharing and now the problem has gone away. Curiously enough though, when I try to use the Lock Screen feature I get an error message saying it "Could not change to Curtain Mode : An error occurred on this computer. [OK]" but it only happens on the default shared control. If I choose full control, it works fine. Not exactly something I need fixed, but thought I mention it in case others run into it. :)

Bol · ‎10-07-2022

Wonderfull, appreciate you updating us as it’s handy to know.

Bol · ‎10-07-2022

@DaddyFixIT
Maybe try adding your account into the local ard group and see if that helps. I include this in my startup script and it's one thing I haven't test myself on that command alone;


/usr/sbin/dseditgroup -o edit -a "yourusername" -t user com.apple.access_screensharing

kbreed27 · ‎10-07-2022

@Bol

Thanks for constantly checking in on this thread. The script you helped me create is working pretty well, but I've noticed that Certain functions of ARD are no longer working. I did set the "privs" to all, but I can't do a spotlight search or copy files to the computer anymore I just keep getting a "This task will fail" message. Remote controlling or viewing works like a charm, however.

Do you know if this Is something I have messed up in the kickstart command privileges or if this is a security setting that Apple has implemented in Monterey.

This is my section of the Kickstart command that I cobbled from your script:

/usr/bin/curl -s -u $apiuser:$apipass $jssurl:8443/JSSResource/computercommands/command/EnableRemoteDesktop/id/$computerID -X POST

/usr/bin/defaults write /Library/Preferences/com.apple.RemoteManagement allowInsecureDH -bool TRUE
$kickstart -targetdisk / -verbose -uninstall -settings -prefs
$kickstart -targetdisk / -verbose -configure -allowAccessFor -specifiedUsers
$kickstart -targetdisk / -activate -configure -access -on -users $localUserName -privs -all -DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings -clientopts -setmenuextra -menuextra no -setwbem -wbem yes -restart -agent -console -menu

Thanks again sir!

Bol · ‎10-11-2022

@kbreed27 wrote:
@Bol
I've noticed that Certain functions of ARD are no longer working.

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!

DaddyFixIT · ‎10-07-2022

I like it. Just to be on the safe side, I've sent this command to all my machines too. :)

Bol · ‎10-07-2022

@kbreed27
Anytime, happy to help and thank you!
I gotta say I did see this happen too a while back, at first I wasn't sure if one command was taking away from the other eg. MDM command setting back to observe over the kickstart setup.

I tried to troubleshoot a long time ago but found if I just triggered the policy again for that machine, full privs come back straight away.

Lastly I wasn't sure if settings are being changed somewhere else in my policies as it did take some time before a machine might do this (it was random I found as well). OR it was ARD being screwy as usual, saying it shows no permissions but after generating an admin report, full privs again.

Anyway, with the time I had spent overall I was happy to have the script trigger again and away I went. Think I had it set to monthly. Hope that helps, somehow.. and again thank you for letting me know it ended up working for you! Very happy it did in the end, nice work :D

eaititig · ‎03-16-2023

Well that's great you can do it via scripting or clicking a button in JAMF, but it should be available to set on a Policy instead. Very disappointing JAMF.

Bol · ‎03-16-2023

@eaititig

https://community.jamf.com/t5/community-updates/feature-requests/m-p/58

@Bol wrote:
@kbreed27 wrote:
@Bol
I've noticed that Certain functions of ARD are no longer working.
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.

kbreed27 · ‎03-20-2023

So, does that mean the script that calls the API to enable remote desktop only needs to be run once from a computer? And if it's already been enabled through API/MDM command, running the kickstart command can reassign permissions without making the API call?

Also, my api script has been working great so thank you again @Bol , How would I specify a second user that would be able to authenticate using ARD? Here is my script:

#!/bin/bash

apiuser=$4
apipass=$5
jssurl=https://myjssURL.com
kickstart="/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart"
localUserName=ardaccount

serial=$(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | /usr/bin/awk -F'"' '/IOPlatformSerialNumber/{print $4}')
computerID=$(/usr/bin/curl -u $apiuser:$apipass $jssurl:8443/JSSResource/computers/serialnumber/$serial -H "accept: text/xml" | /usr/bin/xpath -e "/computer/general/id/text()")

/usr/bin/curl -s -u $apiuser:$apipass $jssurl:8443/JSSResource/computercommands/command/EnableRemoteDesktop/id/$computerID -X POST

/usr/bin/defaults write /Library/Preferences/com.apple.RemoteManagement allowInsecureDH -bool TRUE
$kickstart -targetdisk / -verbose -uninstall -settings -prefs
$kickstart -targetdisk / -verbose -configure -allowAccessFor -specifiedUsers
$kickstart -targetdisk / -activate -configure -access -on -users $localUserName -privs -all -DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings -clientopts -setmenuextra -menuextra no -setwbem -wbem yes -restart -agent -console -menu

Could I just do something like


localUserName=ardaccount,ardaccount2

Or would it have to be something else to get a second account name in there.

Bol · ‎03-20-2023

@kbreed27
Yes I think it could be seperated by policies say; I might run the api enable on enrollment.. Then after a reboot, my ard script normally kicks in.

With the second user, yes, that's exactly what I used to have;

-users username1,username2

@kwoodard
I'd say the first thing I would try is;

kickstart -targetdisk / -verbose -uninstall -settings -prefs

eaititig · ‎03-20-2023

I enable it via JAMF using the Remote Commands but then I had a policy which ran kickstart daily and then I lose access. If I want to access I have to re-enable it using the Remote Command feature.

Bol · ‎03-20-2023

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

eaititig · ‎03-20-2023

# 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

Bol · ‎03-20-2023

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.

kwoodard · ‎03-17-2023

Is there a command we can shoot to our Mac's that will reset the Remote Management settings to how they were out of the box? I ask because I still have a bunch of Mac's that I cannot connect to and even manually enabling RM, I still cannot connect to these boxes (that is if there have been any attempts of setting up RM via Jamf).

Bol · ‎05-12-2023

@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

ImAMicrosoftGuy · ‎05-17-2023

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.

Jamf Nation Community

ARD Screen Sharing issue M1 Macs and Monterey