Screen Share Monitor

[mm2270]

Hi All,

Just wanted to post about something I crafted to help address a concern for some environments around Screen Sharing, whether using Apple's built in Screen Sharing process, or through Casper Remote.

As outlined in this Feature Request (https://jamfnation.jamfsoftware.com/featureRequest.html?id=167), there is a valid concern over the lack of any notification of a Screen Sharing session starting and then ending. Although its possible to get notified of a Screen Sharing session starting by way of Casper Remote with the user account settings set to always prompt the end users to authorize the connection, there is never any indication of when the session ends. Its not easily possible for a client to know that a remote technician isn't still viewing their screen. While some may just consider it being paranoid, its a bit inarguable that it remains a valid issue. To make matters worse, if someone is using the built in Screen Sharing.app, there is no user authentication presented. You simply remote in and the end user simply doesn't know its happening.
I recall this issue being raised by some techs that I was training during my very first Casper Suite installation some years ago. I didn't have a good answer for them then, and it always bugged me that there wasn't a simple way of knowing if the screen was still being observed.

Some months back I decided to see if there was some way to address this. My research led me to find some posts on the subject of how to monitor ports on OS X and see established connections. In playing around with it, I hacked a simple process together that could tell me if there was an active Screen Sharing session happening, and when it subsequently ended.

Recently, this came up again on the same Feature Request. I dug out the process from earlier in the year and decided to take a fresh look at it to see if I could come up with something that would really work well enough that it could be considered for use in various environments.

I'm finally ready to announce it, and I put together a github page with a release so anyone who wants to use it can download it and try it out.

You can find all the source files as well as a pre-packaged installer pkg here:
https://github.com/mm2270/ScreenSharingMonitor/

How it works
I outlined the process of how this actually works in the Read Me on the Github page, so read that for more information, but the long and short of it is, its using both a LaunchDaemon and a LaunchAgent. The Daemon does the bulk of the work of detecting Screen Sharing sessions (or lack of one) and taking appropriate action. The Agent does the work of notifying the user by calling a compiled version of terminal-notifier. As such, this can be used currently only with 10.8 and higher. If you needed it to work with older version of OS X, the script can be made to work with something else like cocoaDialog, so you'd just need to modify the script accordingly. I settled on terminal-notifier and Notification Center messaging because, frankly, we're not really doing much support on Lion and below at this point, so I didn't feel it was necessary to accommodate those older OS releases.

I've done testing with this in our environment against different OSes ranging from 10.8.5 through 10.10, and it seems to work pretty well and reliably. Its also been tested when Casper Remote screen sharing from JSS 8.73 and 9.61. I don't see any reason it wouldn't work with some older and some newer releases of Casper Suite, but I can't confirm any of that at this time.
YMMV, so I welcome any feedback on it you may have if you decide to try it.

Also, I would welcome any improvements you may make to it, especially if someone can figure out an even more reliable way of knowing when a Screen Sharing session starts or ends.

[perrycj]

Good stuff man. I'm definitely gonna try it out and I'll let you know how it goes.

[ImAMacGuy]

it worked the first time I connected/disconnected... then tried it again and it didn't show up.. had another person try, and it didn't show up either.

[mm2270]

@jwojda - interesting. I haven't seen that happen. Can you check to see if there was an entry in the log file located at /private/var/log/screenshare-notifier.log? I'm wondering if there's some kind of timing issue I need to check on. Again though, in my tests I haven't seen that happen.
Also, any details on the OS it was tested on, whether it was a Casper Remote session or using the regular Apple Screen Sharing app would be helpful. Lastly, did you manually install everything from the github page or did you install it with the prebuilt package?

[ImAMacGuy]

i take that back, it didn't register that I logged off.

How come it says that the connection was stopped from: localhost no matter what machine I use?

[mm2270]

Do you have the option enabled in the user account settings to prompt for authorization? It sounds like you don't have that on. Unfortunately, the only way the script can determine who the user is connecting when doing it through Casper Remote is to have that option enabled. It can then pull the informaiton from the jamf.log. With that option disabled and connecting via Casper Remote, it ends up showing as "localhost". it seems the way Casper Remote initiates the connection, on port 5900 it appears to be coming from the local machine itself, so the script tries to pull the connection info from the jamf.log. If that's not present, it can only report as localhost.
I meant to add that into the Known Issues section on the Github page. I'll update it later with that info.

Going back to the previous issue though, when you say it didn't register that you logged off, you mean not at all? Or just that there was a delay?

[ImAMacGuy]

i'm sorry, I don't follow the user option thing.

when I tried it, it showed I signed on... then off.. then i tried again which showed I connected, but it never recognized I disconnected. A co worker of mine then signed on 2 or 3 times and it didn't register it. then after 9m4s the logs showed disconnected. After that it seemed to recognize the connects/disconnects as expected.

[scottb]

@mm2270 - seeing the same as @jwojda. Got a NC message the first time, subsequent connections nothing.
Also did not get a NC message that I disconnected.

OS X 10.9.5, JSS 9.32

Thank you for this though - it's a start and I'll see what I can find as to when it works and doesn't. Tried both the .pkg and installing the bits by hand.

[perrycj]

@mm2270 Seems to be working fine for me. I was able to connect to 2 different MacBooks running 10.9.5 from an iMac running 10.10.0 and got the notifications each time.

The only thing was the disconnected notification was slightly delayed by about 5-10 seconds after I actually closed out the session. But other than that, it works well.

[scottb]

Last lines in system.log:

Dec 4 13:35:04 USSMOMD00172760 defaults[1382]: The domain/default pair of (/Library/Preferences/com.jamfsoftware.jamf, casperscreensharing_no_login) does not exist Dec 4 13:35:05 USSMOMD00172760 sudo[1407]: hpadmin : TTY=ttys002 ; PWD=/private/var/.hpadmin ; USER=root ; COMMAND=/usr/sbin/jamf monitorScreenSharing

[scottb]

@mm2270][/url - I removed all the components by hand and installed the package again. Immediately the NC message came in that there was a connection.

Upon disconnect, I didn't get the message, but I figured out why - I'm "double-dipping" on the remote testing by using Casper with "ask for permission" and ARD.

I was not seeing the disconnect message as I still had ARD active. D'oh!
So I get messages below, but I'm testing repeat connections/messages now.

external image link

external image link

[scottb]

@mm2270][/url][/url][/url - it seems to work pretty much all the time now, and even with "the option enabled in the user account settings to prompt for authorization" off, I see notifications.

My take is that you say that should not work? The only change I made was:
System Preferences/Sharing/Remote Management/Options/Show when being observed.
*EDIT: I re-read and see that is for Screen-Sharing initiated connections.

However, I flicked that off again and still get connect/disconnect messages for every session.
Interesting that there was a delay in this working ~100% of the time. Makes no sense to me, but it's better after being up for a while and testing.

external image link

*EDIT: If you click the "Show" button in the NC messages, it opens up Self Service!

[calumhunter]

this is very cool. this should absolutely be a feature added to casper.
its common place for this sort of notification in other remote access apps like team viewer.
users definitely get nervous when you remote control their machine, i think this type of notification goes a long way to alleviate those concerns.
Nice work @mm2270

[Kumarasinghe]

Nice addition @mm2270][/url][/url.

Is there a reason for not using Casper notification tool instead of terminal-notifier?
It's like a cutdown version of terminal-notifier.

/Library/Application Support/JAMF/bin/Management Action.app/Contents/MacOS/Management Action

Sound option did not work for us with this but basic functionality works fine.

[franton]

This is nice. I like this a LOT!

[ImAMacGuy]

ARD shows the machine name, but Casper Screen share doesn't. I think because when I use casper screen share, it reports "User Name" is currently connected using the display on "127.0.0.1:5904", and then I choose share display...

the logs just show this...
Screen Sharing - ON
12/05/2014 8:07 AM: A Casper ScreenSharing session started to your Mac from: localhost

[mm2270]

Hey all, thanks for the valuable feedback from everyone that has tried it out so far.
I'll try to address as many of the questions or points raised above as I can.

@jwojda][/url - Regarding the issue you're seeing with "localhost", what I was referring to yesterday is, if you go into your JSS > System Settings > JSS User Accounts and Groups, then locate your account (or whichever account you log into Casper Remote with) check under Privileges > Casper Remote. Way at the bottom of the list is a setting called "Screen Share with Remote Computers Without Asking " If that option is checked or enabled, it means the end user doesn't get an authentication prompt to allow you to connect. Unfortunately, this means that Casper/jamf binary doesn't record the user account connecting information anywhere that I can locate. If the setting is unchecked, and the user gets the prompt to allow the connection, when they click Allow, your username gets written to the jamf.log and the script is able to pick that up and use that information in the NC message. When you can connect without that auth prompt, the way Casper Remote appears to do this is, it SSH'es to the Mac and fires up Screen Sharing in a way that it appears as if the local machine initiated the connection back to you, hence why the script can only pick up "localhost" as the connecting system.
So far, I haven't found a good way of knowing who is connecting, even a hostname, when its done this way. CR just doesn't put that information in any place I can find for the script to locate.
This doesn't happen when using either ARD or Apple's Screen Sharing.app directly, so its only an issue with how Casper Remote works, and only if that option I mentioned above is enabled.
I didn't put this into the Known Issues section on the Github page - so my bad on that. I will update it soon with the above info.

@boettchs][/url - Thanks for pointing out the issue with multiple remote connections from different tools or even different systems to the same Mac. I'll be honest and say that that condition never even occurred to me, but it makes complete sense the process would get a little tripped up from this. It will see that a connection is still active, even if one drops and the other one remains, so it won't be able to tell you when connection A leaves, but connection B is still on.
That said, I have some ideas milling around in my head about how I might be able to handle that in a future revision. It might be possible to track all active connections and report on each one's start and stop individually. I'll play around with it and see what I can come up with.
Also, glad its working reliably now. I'm not certain why it took some time to fully begin working properly. I'll need to keep my eye on that.

@perrycj][/url - As for the slight delay, the reason that happens is because of the way it was designed to use a StartInterval time of 12 seconds for the LaunchDaemon. There is typically at least a couple of seconds delay from connection or drop of a connection and the message b/c of this. However, read on. I think just yesterday I found a way to make that message come up faster and make the whole process a little more reliable. More on that in a moment.

@Kumarasinghe][/url - Valid point on the Management Action.app. I had considered that actually, but there are several reasons I chose to go with terminal-notifier.
1 - Most important to me, using Management Action.app would have meant restricting this both to a Casper Suite only installation as well as a Casper Suite 9.x installation. I wanted to make this backward compatible so it would work with any 8.x Casper Suite setups still out there, as well as working with non Casper Suite environments that just use something like ARD or Screen Sharing.app.
2 - The version of terminal-notiifer I'm using now has the ability to make the messages appear to come from any application you want by using a flag called -sender and using the Bundle Identifier for the app. When you do this, it auto selects the icon, so for example, if the session is started by Screen Sharing.app or ARD, it uses the Screen Sharing.app Bundle ID and icon. If started by Casper Remote, it uses the Self Service Bundle ID and icon (same one as Management Action.app) It also places the messages into a different group within Notification Center. A side effect of this is that when you click the message, it will open the app whose Bundle ID was used, so it will launch Self Service or Screen Sharing. That last part isn't ideal really, and I need to see if I can force it to open something else, or nothing at all. If I spoofed it to use the Bundle ID for Management Action, it won't open anything when clicked. Double clicking Management Action.app does nothing as far as I can see, so that may not be a bad option.
All that being said, you're free to modify the script to call Management Action.app or, even change the Bundle ID its using on line 130 in the screenshare-notifier.sh script to use the ID from Management Action.app, so it will appear to be coming from that application instead of Self Service.

So, going back to the LaunchDaemon, when I was designing this originally, I wasn't sure how to get this to only run the script when needed, so I used the StartInterval of 12 seconds, so it would just keep checking the port periodically. Launchd jobs can't run any more frequently than 10 seconds apart or the OS just throttles them, and you get a bunch of Throttling Respawn messages in system.log. 12 seconds seemed like a good medium.
However, I went back to this just yesterday and had a Doh! moment when I realized Launchd jobs can use [s]Mach Services[/s] Sockets to monitor ports and services. I have a modified version now running on my Mac that listens on the port for Screen Sharing and only runs the script when it sees a change there, so no StartInterval needed. It just listens for changes to the rfb service (Screen Sharing) and runs the script when it gets triggered. So far it seems to be working nicely, but I need to do a little more testing with it. I'll probably post up the modified LaunchDaemon later today after some more testing for anyone that also wants to give it a try.

For everyone else that commented, thanks! I hope to continue to add to this a little more, but even as is, hopefully its useful for some of you.

[asims9]

Thank you for this!

[Dwoodcock]

This is great!! Been thinking of something like this for a few months now. I wonder how hard it would be to have it send a txt notification? I mean it would be great to know your being observed Without I.T. being aware you know :)