ARD Screen Sharing issue M1 Macs and Monterey

prujamf
New Contributor

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.

134 REPLIES 134

Bol
Contributor III

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

a_bautista
New Contributor II

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
Contributor III

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.

 

Bol_0-1655425406441.png

 

kwoodard
Contributor III

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
New Contributor II

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!

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

jkline19
New Contributor II

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
Contributor III

@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
New Contributor II

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
Contributor III

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
Valued Contributor II

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)


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

DaddyFixIT
New Contributor

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.

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
Contributor III

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