Remote desktop tool can't control laptop on Mojave?

[Tony_E-Learning]

Hi there,

I recently upgraded High Sierra to Mojave on a test laptop. In High Sierra, I was able to use the Remote desktop tool to remote into the laptop and control it. After upgrading, I am only able to observe after remoting in. 

Weird thing is that I've already enabled Remote Login and Remote Management in Sharing system prefs and I'm able to remote in and control the laptop with ARD.

Anyone else encounter this issue with the remote desktop tool?

[sshort]

There are a couple of potential causes, one is that Apple only allows "observe" by default unless the user activates Remote Management in the Sharing prefs pane. I know you mentioned that's turned on, but I'm wondering if Apple is enforcing a "user-approved" methodology, where the user has to enable those settings in the GUI vs it being activated as part of a script/another management tool.

The other possibility is that m_agent or some other Meraki binary needs to be whitelisted for accessibility/AppleEvents and/or full disk access as part of the new Privacy Preferences Policy Control payload 

[BlakeRichardson]

Mojave has quite a few changes security wise, given its only been out a few days I doubt Systems manager has been updated to reflect some of the major changes. 

[sshort]

For anyone still following this thread: Apple has released a workaround for remotely controlling vs observe-only mode. You'll have to upload a custom mobileconfig to your Meraki dashboard.

https://support.apple.com/en-us/HT209161

[SClute]

So I've uploaded a custom mobile config enabling the screen sharing agent but I still can't control my users machines remotely on Mojave-  what am I missing?

[Jame]

I reported this to Meraki support a couple of months ago. I see it's still been an issue since September. The support agent said they are working on a fix. Is Meraki trying to fix this or is it solely on Apple? Would love to have this feature re-enabled so we can provide better support.

[Richard_W]

This whole Mojave thing is predicated on the fact that in Mojave the user has to approve remote control explicitly.

I have all machines set up to allow remote control but still the issue remains that I can see the screen, cannot control the mouse, nor click. I had this issue with 10.12, 10.13 and now 10.14.

I've asked support for a solution but alas none forthcoming since January. The blame game places the ball in the Mojave court but this seems odd given it does not work in earlier MacOS's. It appears a non-valid argument.

Like I asked in another community forum; does anyone have this working?

[Jame]

I don't have a solution presently, but I will note that Spiceworks remote support tool has overcome this by having the user grant special privileges via system prefs. So other remote access tools have worked past this.

[Richard_W]

I've been back around again it appears the machines I can not control are indeed Mojave machines.

Settings on Mojave mirror those on older OS in that remote access is set to allow control.

Again any thoughts?

[AndrewSL]

This is really frustrating... like others, I have not been able to get this to work. I used carlashley's TCC profile maker from GitHub to push a profile on to our machines with Mojave... still not able to control the screen in Remote Desktop.

Used all the links and resources in this thread and tried numerous methods... no luck. Cisco support says there is no fix for this and have no ETA on that. We are stuck as an organization because most of our computers are used by remote workers... so we don't have physical access to these machines to whitelist programs or allow remote access in the settings. We would have to give the admin password out to all our users (Which obviously something that we don't want to do). This is definitely a issue with Mojave update because we have a few machines still on High Sierra - and we are able to use the Remote Desktop feature on Meraki to control their screen.

I was thinking about installing a Remote Desktop application on our users machines... but that would require admin privileges to install things and we don't want to give out the admin password. Also, we would have to whitelist that program - which would require admin privileges again, which we can't type in remotely.

Has ANYONE successfully gotten by this? We are at the point of just dropping Meraki and going with JAMF... This is outrageous that Cisco support won't even assist me with this issue when I call or open up a ticket. 

[AndrewSL]

@Jame how are you using Spiceworks remote support tool as a work around?

[Jame]

I'm using the free support tool. We just initiate a session and they have to grant Zoho assist additional permissions the first session so that it can be an interactive session (I can click and move stuff). For follow up sessions this is not needed.

I work at a small company, so I don't have as many support cases. I imagine this would not scale well.

@AndrewSL 

[BlakeRichardson]

The issue is most likely Appe's new security controls, they are very picky and cause all sorts of issues so certain software. 

You will probably find it easier just using another product i.e. teamviewer or gotomypc. Yes their licenses are expensive but the time you will save will pay for it.

[Richard_W]

One of the reasons we chose Meraki SM was for the remote control features advertised for both platforms. To suggest a third party solution for an issue with an OS that's been out since September 2018 is not particularly useful. 

I feel that is is Meraki's job to honor the production solution that they offered. Apple's change does not strike me as  "picky" especially given that the other solutions you have mentioned apparently work fine within these new constraints. 

[AndrewSL]

I agree with you @Richard_W  I think Meraki should be honoring their MDM solution and come up with a fix for it. Their system is basically useless at this point for us and they don't bother to even provide help to fix it. Support just has one general answer and refuses to look for any type of work around. Shoulda just went with JAMF.... thanks Cisco!

[mbonne]

In the same boat, Meraki SM still doesn't feel 100% Mojave ready, and we're now a few dot releases in. 10.14.5

Remote screen view connects, selecting things and clicking on stuff doesn't work!

Not even a TCC/PPPC user consent dialogue box popup when making the connection for first time.

Troubleshooting steps:

spoiler: I still haven't got it working...

Using this terminal command on a test Mojave Mac:

$ log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'

Launching remote access from Meraki Dashboard I see the following log stream:

MB-Mojave-VM:~ admin$ log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'
Filtering the log data using "subsystem == "com.apple.TCC" AND composedMessage BEGINSWITH "AttributionChain""
Timestamp Thread Type Activity PID TTL
2019-05-24 18:41:21.773770-0700 0x2687 Info 0x378f 201 0 tccd: [com.apple.TCC:access] AttributionChain: RESP:{ID: com.apple.bash, PID[1463], auid: 0, euid: 0, responsible path: '/Library/Application Support/Meraki/OSXvnc-server.sh', binary path: '/bin/bash'}, ACC:{ID: ??, PID[1466], auid: 0, euid: 0, binary path: '/Library/Application Support/Meraki/OSXvnc-server-4'}, REQ:{ID: com.apple.WindowServer, PID[177], auid: 88, euid: 88, binary path: '/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer'}
2019-05-24 18:41:22.097860-0700 0x281f Info 0x0 201 0 tccd: [com.apple.TCC:access] AttributionChain: RESP:{ID: com.apple.bash, PID[1463], auid: 0, euid: 0, responsible path: '/Library/Application Support/Meraki/OSXvnc-server.sh', binary path: '/bin/bash'}, ACC:{ID: ??, PID[1466], auid: 0, euid: 0, binary path: '/Library/Application Support/Meraki/OSXvnc-server-4'}, REQ:{ID: com.apple.appleeventsd, PID[52], auid: 55, euid: 55, binary path: '/System/Library/CoreServices/appleeventsd'}
2019-05-24 18:41:22.099473-0700 0x281f Info 0x0 201 0 tccd: [com.apple.TCC:access] AttributionChain: RESP:{ID: com.apple.bash, PID[1463], auid: 0, euid: 0, responsible path: '/Library/Application Support/Meraki/OSXvnc-server.sh', binary path: '/bin/bash'}, ACC:{ID: ??, PID[1466], auid: 0, euid: 0, binary path: '/Library/Application Support/Meraki/OSXvnc-server-4'}, REQ:{ID: com.apple.appleeventsd, PID[52], auid: 55, euid: 55, binary path: '/System/Library/CoreServices/appleeventsd'}
2019-05-24 18:41:24.394726-0700 0x2687 Info 0x4692 201 0 tccd: [com.apple.TCC:access] AttributionChain: RESP:{ID: com.apple.bash, PID[1463], auid: 0, euid: 0, responsible path: '/Library/Application Support/Meraki/OSXvnc-server.sh', binary path: '/bin/bash'}, REQ:{ID: ??, PID[1466], auid: 0, euid: 0, binary path: '/Library/Application Support/Meraki/OSXvnc-server-4'}
2019-05-24 18:41:24.401944-0700 0x281f Info 0x4680 201 0 tccd: [com.apple.TCC:access] AttributionChain: RESP:{ID: com.apple.bash, PID[1463], auid: 0, euid: 0, responsible path: '/Library/Application Support/Meraki/OSXvnc-server.sh', binary path: '/bin/bash'}, ACC:{ID: ??, PID[1466], auid: 0, euid: 0, binary path: '/Library/Application Support/Meraki/OSXvnc-server-4'}, REQ:{ID: com.apple.WindowServer, PID[177], auid: 88, euid: 88, binary path: '/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer'}
^C
MB-Mojave-VM:~ admin$

(I had to paste into text editor to read each line as one line...otherwise it messy af to read in block of text)

Points of interest:

'/Library/Application Support/Meraki/OSXvnc-server.sh'

'/Library/Application Support/Meraki/OSXvnc-server-4'

com.apple.WindowServer

com.apple.appleeventsd

Using PPPC Utility to try and open the OSXvnc-server-4 binary in didn't do anything.

Using ProfileCreator to drag it in there returned an error: The file "OSXvnc-server-4" did not have a designated code requirement for it's code signature, and cannot be used.

Hmmm...

For test sake, I drag

/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/MacOS/AppleVNCServer

into ProfileCreator and wants to confirm some things, but for the most part looks like any other signed app I’ve dragged into the profile creator.

Checking the code signing of Meraki's own OSXvnc-server-4 binary seems its not signed. Why not? Shouldn’t it be? m_agent is.

# codesign -dv /Library/Application\ Support/Meraki/OSXvnc-server-4 

/Library/Application Support/Meraki/OSXvnc-server-4: code object is not signed at all

# codesign -dv /System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/MacOS/AppleVNCServer
Executable=/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/MacOS/AppleVNCServer
Identifier=com.apple.AppleVNCServer

...

# codesign -dr - /Library/Application\ Support/Meraki/OSXvnc-server-4
/Library/Application Support/Meraki/OSXvnc-server-4: code object is not signed at all

ARD Agent, again, all signed.

Why is Meraki not signing their own VNC Server?

Is this part of the issue?

--

Manually adding in /Library/Application Support/Meraki/OSXvnc-server-4 to Security and Privacy prefs

and allowing has done nothing extra.

¯\_(ツ)_/¯

Any insight from Meraki Support/Dev Team would be greatly appreciated.

[BlakeRichardson]

@Richard_W  you are blaming Meraki for Apple tightening their OS's security and making everything difficult.

We are finding a lot of systems app's that we use to diagnosis no longer work properly because of Apples new security features.  Disk warrior is a prime example. 

[Richard_W]

@BlakeRichardson I'm taking Meraki to task for advertising a feature that does not work.

You yourself suggested using other apps "teamviewer or gotomypc" both of work within Apple's tightening OS security fine.

Funny you should mention diskwarrior (not a remote access application) their issue is with APFS as per:

https://www.alsoft.com/DiskWarrior/mojaveapfs.html

And they apparently tackled the new security features with aplomb.

My issue is that Meraki has known about these "new" security features for a while (like all developers) and yet they still do not have a viable solution eight months in. And it is not as if this issue will go away - more and more machines will upgrade to Mojave.

I don't think this is a "blame" game, but rather a sensible request for an advertised feature to work. 

I don't feel I'm alone in this request.

[Richard_W]

@mbonne 

Thanks for your massive spelunking  - I saw the OSXvnc-server-4 when I was grasping at adding something to security > accessibility. 

I'm guessing you are on to something in regards to the lack of signing.

Maybe Support/Dev teams can help?

[mbonne]

The Meraki reply from yesterday(looks like who ever wants this to work has to make a wish for it to work.):

Greetings,

Thank you for contacting Cisco Meraki support!

We took a look into this query and unfortunately currently on the support side we do not have any visibility as to the ETA of this query. We will recommend using the make a wish button on your dashboard for our engineering team to take  look into this.

Kind regards,

Cisco Meraki Technical Support
ref:_00D606uBw._5000d1SoDxz:ref

[Richard_W]

Make a wish - wow, just wow.

Well I'm off to make a wish that Meraki considers sending peeps to WWDC (or at least watch the keynote), after all it's just around the corner and they may learn about changes to their clients' OS.

[uninterested]

Thought I'd just post one message in here to chime in on the mess that is Systems Manager, in particular when it comes to macOS support. We have dozens of customers that chose SM when it was one of the first MDMs on the market. Over the years they have renewed their licenses and stuck by Meraki in the hope that they would see better support for macOS and, to a lesser degree, iOS. Both our customers and us are absolutely fed up with Meraki's development timeline and the support department's response to 90% of tickets that are raised. The default answer is to 'make a wish' and when we suggest that none of the new features should have caught Cisco, one of the world's largest and best resourced technology companies, by surprise, it falls on deaf ears. 

It's been almost a year since Mojave was released and we still can't remote control clients. It's a view-only connection.

There's no way to implement the majority of new macOS features that were released in High Sierra or Mojave and it certainly seems like Meraki do not count the Mac as a first class platform that it is interested in concentrating on. 

iOS management is certainly better, but even then they never have zero day support for any new iOS features. This first started to become apparent when Apple released the education-specific features in iOS 9.3 and it took Meraki an age to implement them, whereas most other MDMs offered support right from day one.

My advice is to take your business elsewhere and vote with your feet. That is certainly what we are doing with our various edu and business customers and their combined ~10,000 licenses. I don't need to mention any competitors names here, but there are at least two or three good alternatives available, depending on if you are a business or educational establishment. Don't assume that your only option is the company with four letters in its name. Don't get me wrong, it's a good solution but there are others out there that could do exactly what you need.

Best of luck to other users... It's been an interesting ride.

[Jame]

What's even worse is the lack of any comment from Meraki in this thread. Like they're just ignoring the issue. I don't know why I would buy licenses when they won't even give us a status update on the problem here. I called their support with no follow up or updates and even on their own forum they won't recognize the issue. I'm left to assume this is something they can't fix or have decided it's not worth it and the community managers just don't want to deliver the bad news.

[jared_f]

I also have RD issues with Meraki. ARD is my best friend. Using the profile + kickstart command you can successfully enable in on Mojave.

[beks88]

Hello all,

We are using TV Host in our org and are pushing the App through SM. But even TV needs to be approved by the user.

We didn't investigate it deeper in how to overcome this, since our current workflow still requires admin touch on the books.

But will try Apple's "workaround" from the link above.

[Jame]

@jared_f 

Could you specify what profile?

[Jame]

I have tried the following payload along with the kickstart command listed below. This is the recommended fix from Apple and I noticed a couple others in this thread mentioned it worked for them. Could anyone point out what I'm doing wrong here?

Profile:

https://pastebin.com/7ecctLUP

Kickstart:

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

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -access -on -privs -ControlObserve -TextMessages

[Richard_W]

@Jame I have direct access to most of my machines so the kickstart command is moot, as I have my machine's already configured for Remote Management (so I can remote control via ARD).

The issue is that the Meraki SM client can remote in but I cannot move the mouse, nor click, if it is on Mojave; normal usage in older OS's.

As @mbonne pointed out, in this thread, the issue appears to lie with Meraki failing to sign their VNC client. Support offered the solution of "make a wish."

As of July, support says: "Our Developers continue to work on this issue. However, there is still no resolution at this time. As soon as there is a resolution, I will be sure to let you know."

Good to know that by the time support has figured out Mojave, Catalina will be out, but that may be wishful thinking on my behalf.

[BlakeRichardson]

@Tony_E-Learning  I've never been able toget this to work going right back to OS X 10.11 which didn't have the really locked up privacy settings.

[Richard_W]

@BlakeRichardson I just remoted into a 10.13.6 machine fine.

The problem really lies with 10.14 and 10.14 alone.

Maybe since 10.15 will be out this month, that may be a working solution. but honestly I'm not holding my breath.

[mmeck]

Doesn't seem to be...

[sshort]

@mbonne Great find, OSXvnc-server-4 not being signed prevents the creation of a PPPC profile to whitelist.

[mbonne]

Thanks, Exactly my thoughts 💭
If I have time later this week, was going to try mucking around with it a little more.

[mbonne]

➜ codesign -s 'Developer ID Application: my developer account' /Library/Application\ Support/Meraki/OSXvnc-server-4

Did not work. Have only started getting into this side of things(signing apps and packages) so may have used the wrong cert?

Output of the command to check if OSXvnc-server-4 is signed looked promising. But still no dice. I'm shooting in the dark here.

➜ codesign -dv /Library/Application\ Support/Meraki/OSXvnc-server-4
Executable=/Library/Application Support/Meraki/OSXvnc-server-4
Identifier=OSXvnc-server-4
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=3151 flags=0x0(none) hashes=94+2 location=embedded
Signature size=9052
Timestamp=29 May 2019 at 9:28:54 pm
Info.plist=not bound
TeamIdentifier=blah
Sealed Resources=none
Internal requirements count=1 size=176

Also made a PPPC profile and it accepted it into the helpful PPPC util and profileCreator apps.

Ticket submitted to Meraki

[NicholasBentne]

Try accessing remote desktop using tools like R-HUB remote support servers, Logmein, Teamviewer etc. and see if issue is resolved.

[ivanpetrov]

I had this problem too - I was on agent 1.0.98. After reaching to Meraki support, the issue is now resolved once they pushed agent version 3.0.2 to our tenant. Remote desktop access will work once the permissions are added in macOS settings.

[Jame]

Yes, the new agent solved this for me as well. In addition to a profile for m_agent I made with PPPC Utility.