@Andy You can see any window spawned by Splashtop Streamer. Like the window that helps direct the user to enable the Permissions. More than a few times I’ve had a session started without screen recording or accessibility enabled and helped the user finish enabling the PPPC by continually directing them back to that window and watching as the click the buttons that will take them to the appropriate locations.
Of course until they enable screen recording I can only see the Streamer window, however when I’ve been in the situation it is exceedingly helpful.
At a minimum the feature should have a bypass. Better would be a simple warning. But considering the failure to function with MDM PPPC and the focus-stealing issue the entire workflow really needs to be refactored.
@mgiordanoI imagine you have a much different relationship with your customers. And yes, I can definitely imagine a situation where a nefarious end user would try to take advantage.
TBH, that is a human resource issue. Even if I didn’t have total faith in the folks that I’ve had to do that with … They have unrestricted physical asses to the machine. Accidentally passing a unique local admin pwd really isn’t the primary vector of attack.
I also just brought this up with our account manager because it seems kind of ridiculous that Syncro checks for all the permissions before even attempting to access the computer.
Same thing for us is that we didn’t have an issue with NinjaOne’s implementation of the Splashtop for RMM. It would connect you with the computer and let you see the user’s screen even if all the security settings weren’t in place.
Definitely seems like they just don’t want to put in the effort to change it.
You can’t see the user’s screen if you don’t have screen recording permissions enabled from any remote access tool for Mac, including Splashtop. This has nothing to do with Syncro, but the permissions Apple requires (which is documented by Splashtop) for remote access.
I think there may be a secondary issue in play here that has to do with enabling permissions via MDM.
NinjaOne also has this issue - I am not sure what you mean either? Its an Apple change. Depending on when you was using it - Apple did have it setup to display the screen before - then they change that to never display the screen after. Can’t remember when the change happen - but even Screenconnect work like this for a while until they made that change. Its not Syncro - its Apple in this case. Even then I would argue you would be better off talking with Splashtop than Syncro about this as they are two different products. I would also argue - while annoying for MSP, its one of the better moves Apple did make to make sure their devices are a little harder to gain access to vs the easy access Windows has currently.
I understand that its Apple requiring the settings for Splashtop to work fully, but I was just testing Ninja vs Syncro a month ago.
With a fresh install of the Ninja Agent on a Mac, you can at least initiate a remote session without having the end-user add all the other privacy settings, vs Syncro, they have to add everything before you can even attempt the remote session on the computer.
I was just doing this like a month or two ago and I’m like 99% sure that it “worked” without all the permissions but trying to get back into a Ninja tenant to confirm that.
@Andy Syncro will not allow a Splashtop session to start if all the “required” PPPC’s are correctly set, but MDM is used for Accessibility and Full Disk Access.
Whatever checks are in place within the Syncro code simply ignore/don’t/can’t/won’t check for MDM enabled PPPC.
It absolutely wouldn’t be an issue if the overkill guardrail at least had a bypass. Splashtop Streamer clearly shows the three PPPC’s as enabled, but the Syncro Agent does not. Splashtop for RMM sessions can be initiated from NinjaRMM. Syncro blocks sessions on the same Splashtop Streamer clients because PPPC permissions are “incorrect”. I’m sure sessions from Syncro would work without issue if the broken PPPC check and artificial session block was not in place. ¯\(ツ)/¯
I’ve not heard anything back from support on this sins 8/4.
@anon83914637 Splashtop remote sessions are fully functional as view-only with just Screen Recording enabled for Splashtop Streamer.
SyncroMSP blocks/does not attempt the session because they’ve decided that a view only session has no value.
Splashtop remote sessions are fully functional as view-and control with Screen Recording and Accesibility enabled for Splashtop Streamer.
SyncroMSP blocks/does not attempt the session because they’ve decided that a full remote control session has no value without Full Disk Access (never mind that the remote session runs in the user context and enabling Full Disk Access only grants access to the logged in user’s home directory. The only way to have root access to the file system is to be in a remote session at the loginwindow where the launchagent runs as root)
SyncroMSP blocks and will not initiate a session to a macOS endpoint without all three PPPC enabled. It’s a pretty bad choice to throw up a session block because one or all three PPPC’s are not enabled. It’s a terrible choice to block sessions when Syncro cannot correctly parse the PPPC settings.
I’ve just spent over an hour and a half trying to get these permissions working for a client and quite honestly I’m sick of it. Splashtop says it has all the permissions it needs, but Syncro still refuses allow it to connect.
Having the same issue here - I’m trying to retire my expiring TeamViewer license, but even manually setting everything, ensuring Splashtop and Syncro are all happy, I STILL get the error. Weirdly, the KB article referenced in the error is hidden behind Zendesk which I don’t have access to? Seems like the issue is mostly with Monterey and later OS. I don’t even care about MDM set permissions at this point - the manually set permissions are not working reliably.
@Andy Just noting that this is still an issue. It’s been 10 months since I opened a ticket on this and 5 months since I was told by support that it was reproduced and they’d get back to me.
It’s still broken. Splashtop Streamer still reports that all TCC permissions are granted. Syncro MSP still artificially blocks a connection attempt because SyncroMSP is not deriving TCC correctly. SyncroSplashtop RMM still doesn’t work on any of my macOS devices.
Yes. Ever provided remote support on iOS/iPadOS? Exactly like that. I’ve not had this come up often, but it has come up and is an edge case that should not be artificially disabled by SyncroMSP guardrails.
Regardless of the weather or not you purposefully do not enable Accessibility TCC, blocking connections that don’t have the “correct” TCC enabled is short-sighted. There have been many times I’ve attempted to connect to a 10.15+ machine where one or both Accessibility and/or Screen Recording are disabled. In every situation with every other implementation of Splashtop (RMM and Business Access) I’ve used (and other remote tools) besides SyncroMSP the connection is still made.
And boy does it make walking an enduser though the setup much, much easier.
In the case that both are off, you can still see the Splashtop Streamer’s windows. Describing where the button to pop the Spalsthtop “Security & Privacy” window is simple to point out. Then it’s much easier to step them through clicking and enabling.
In the case that Accessibility is off, but Screen Recording is enabled so you can still view the entire screen. Can you really tell me that you’re better off as an admin not viewing the entire display to walk the end-user though enabling Accessibility?
To the specific point of this post, do you want your RMM to artificially block the connection because the’ve decided they know better than you what can and can’t be useful in a remote session? Especially when the artificial guard rails block connections to devices that are 100% configured correctly with every TCC enabled because the RMM Agent was not designed to detect MDM deployed TCC?
(After 10 month’s with no movement on a fix, I’m a bit salty. Who am I kidding, I’m probably always a bit salty.)
I don’t provide remote support on iOS directly on the screen, no. I’ve managed settings with Jamf, but that’s as far as I’ve ever had to go.
Fair enough on your use case. My ‘workaround’ after seeing what the Syncro Agent can do/not do, was to get an MDM. And if a user needs help getting some permissions accepted to receive remote support, I use a simple solution like peercalls to see what they’re seeing. Easier for me than stumbling through each piecemeal setting. But, that said, I haven’t had a user who wasn’t able to follow the instructions to allow permissions. I start my MDM installation (if it’s not ADE in ABM) with a link to Screenconnect, so the users are following those directions, not whatever Syncro/Splashtop are displaying.