But that is a function of screensharing in OS X itself.

If instead of ARD you use the built in screen sharing app in OS X and connect as a user that is not logged in while someone else is logged in you will get the same exact prompt since its also using the built in OS X screensharing app in both cases.

@CasperSally If they have access to remote, do they also have access to run scripts & install software etc?

Cos that too could cause havoc as well. Hell, they could restart via remote whilst a user is logged in. All without logging into a user session.

It sounds like you might need to disable screen sharing in Casper remote and have them use something else. That being said, have you tried changing some of the privileges:

@bentoms - the tech accounts are very locked down. techs can only use casper remote to screen share.

@davidacland - This isn't how casper remote worked in 9.32. I wonder if the change was in the release notes at some point, if it was, I obviously missed it. In my opinion, building off of the build in screen sharing is fine, but I don't consider the ability to masquerade as another user screen sharing anymore and the user prefs you took a screen shot of don't reflect that.

Our concern isn't really the techs doing something malicious, that's really a worst case example, it's more the policy we have that the end user accepts the request and can see what techs are doing every step of the way.

It's unfortunate to have to consider another product for remote access. It's not like we'll get some sort of reduced rate for not using Casper Remote anymore to offset the cost of another product. We use Bomgar for PC access... it's not cheap.

@CasperSally - this isn't a concern in my environment, but I know that @mm2270 has been working on a method to alert users when there is an active screensharing session. It was detailed in https://jamfnation.jamfsoftware.com/discussion.html?id=12735

I think that's a function built in to OSX, not Casper.

@CasperSally have you tried turning off the without asking option? if it has to prompt the user I am fairly certain they will not get the other option. if I get time to play around today I will try to test that as well.

@nessts - we never have allowed the without asking option for the techs, part of our policy requires the request for control/view.

saves me needing to test it then i suppose.

@mattware is right, Casper Remote is sending the request to Screen Sharing.app (built into OS X).

FWIW, that Screen Share with Remote Users Without Asking checkbox is a no-no in every environment I've ever been in (legal, HR, and security mandates).

So we have to make sure hat box is off for all JSS user/group accounts.

So we have only the Use Casper Remote and Screen Share with Remote Users enabled for techs.

Check in Computer record > History > Screen Sharing Logs to see who logged on to which computer.

You can use an ACL for Remote Management, but you'd have to share the local admin account credentials (not sure how that would pan out if you're rotating that password).

I wanted to chime in on this topic, partly because I think that some of us are confusing the issue that @CasperSally brought up here, and also because I understand the issue and will detail one possible way to mitigate it.
The issue here isn't whether techs are secretly logging into other users Macs. or that the end users aren't being asked to authorize the connection. As she has mentioned, the users do see a prompt to allow the remote tech to connect when its done over Casper Remote. The issue is that, because of how Apple's built in screen sharing works, which Casper Remote has been using now for several years I might add, its connecting with the temporary "casperscreensharing" account. When this happens, the tech gets presented with 2 options - Share the screen with the currently logged in console user, OR, log in as casperscreensharing. The latter option is where the concern comes in since this allows someone to log in and not show any control over the screen of the current console user. so they can't see anything the remote tech is doing.
This is not a big issue for us, so, though I've known it works this way for a while, I never gave it much thought until now.

First thing is, this is Apple's screensharing at work and not something JAMF is doing. This is how it works. Here's an example:
• If I have another Mac that I am logged into with my AD account on, and from my primary Mac I fire up regular old Screen Sharing.app, type in the remote Mac's IP or hostname and connect, I get prompted for credentials.
• If I type in my own AD credentials, since my account is also on that Mac and in control of the screen, I get logged right into that account, no questions asked, no other options given.
• If on the other hand, I type in the name/password of a local account on the Mac, like a local admin account, I then get 2 options - Share the screen with my account that's logged into the remote system, or log in as that local administrator account. I can choose whichever one, leading to the concern above.

So in essence, the only way for Casper Remote to not present those options would be for it to somehow know the credentials for the logged in user and connect as them and not as casperscreensharing.
Obviously this is impossible, and so, as JAMF stated, this is working as designed.

Now, for a possible solution, I just tested something out and wanted to share.
So, one thing JAMF could implement (as an option of course) to stop logging in as their "casperscreensharing" account is to disable actual login to that account. What I mean is, set the User shell to /usr/bin/false. I just did a series of tests on this and it prevents me from logging into that account when I'm presented with those options. I tested this by starting a Casper Remote session and when the prompt appears on my admin Mac, going to the test Mac I'm remoting into and doing the following command:

sudo chsh -s /usr/bin/false casperscreensharing

Once done, I tried selecting the "casperscreensharing" account to log into and could not. Its a bit ugly as is, because it simply sits there indefinitely trying to 'log in' and can't. You have no choice but to click Cancel and restart a screen share connection. I then tried by sharing the screen with my console account and got right in, so setting the shell that way doesn't affect the ability to share the screen with the logged in user.

Given this, I came up with the following process, which is a bit rough right now, but may help with this issue. Its a LaunchDaemon that watches /private/var/ (The "casperscreensharing" account home directory gets put here) and when the script the LaunchDaemon runs fires, it checks to see if the account is there and if the UserShell is set to /usr/bin/false. If its not, it "fixes" it and thus prevents anyone from logging in with it. There are some other things going on to help catch it if it needs to loop a few times for example, but generally speaking, thats all it does.

Disclaimer: I have not done an extensive amount of testing with this, just preliminary exploration of a possible solution. You can try this out to see how it works for you, but no guarantees this will always work properly.

Here's the LaunchDaemon (which I named com.org.cssfix < "casperscreensharing fix):

<?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>Label</key>
    <string>com.org.cssfix</string>
    <key>Program</key>
    <string>/private/var/scripts/disable_cssuser.sh</string>
    <key>RunAtLoad</key>
    <true/>
    <key>WatchPaths</key>
    <array>
        <string>/private/var</string>
    </array>
</dict>
</plist>

And here's the script, named "disable_cssuser.sh" and put into /private/var/scripts/ as shown in the LaunchDaemon, but it can be put anywhere:

#!/bin/bash

acct="casperscreensharing"

function fixcasperscreensharing ()
{

if [ "$times" == 4 ]; then
    echo "Failed to correct casperscreensharing account"
    exit 1
fi

if [[ $(dscl . read /Users/${acct} UserShell | awk '{print $NF}') == "/bin/bash" ]]; then
    echo "casperscreensharing account is active and has a user shell of /bin/bash. Fixing..."
    chsh -s /usr/bin/false casperscreensharing
    sleep 0.7

    if [[ $(dscl . read /Users/${acct} UserShell | awk '{print $NF}') == "/usr/bin/false" ]]; then
        echo "casperscreensharing login has been disabled. Exiting..."
        exit 0
    else
        let times=$((times+1))
        fixcasperscreensharing
    fi
fi

}

if [[ $(dscl . list /Users | grep "$acct") ]]; then
    times=1

    fixcasperscreensharing
else
    echo "casperscreensharing account was not found. Exiting..."
    exit 0
fi

sleep 9

I have this exact LaunchDaemon and script running on a test 10.10.3 Mac next to me, and have been testing Casper Remote screen sharing to it for the last 2 hours, and I have not been able to log in under casperscreensharing with this on, through multiple attempts and through reboots, but I can share the screen with the account the Mac is actually logged into (mine) every single time, so it seems to be working well for me.

If anyone wants to take this basic concept and perhaps flesh this out or make it more reliable, feel free to. I likely will not put any more time into it, but wanted to share a possible way to address this. Perhaps JAMF can add something into a future version, like a checkbox under some settings in the JSS that will automatically create the account in a way that no-one can log into it. Its possible to do, as I've shown above.

thanks @mm2270 for the time you put into this, I really appreciate it. I'm definitely going to test and bring this up with JAMF and see if they see any downside to the approach.

@CasperSally Sure, no problem.
As I mentioned, though its not a big deal for us, I can certainly appreciate the concern.

FWIW, I've done a little more testing with this in place and so far I've seen no ill effects. Each time I start up a CR screen sharing connection, I'm unable to log in with the "casperscreensharing" account, but can always share the screen with the console user. Once I'm in, it acts just as if I'd chosen to share the screen from the get-go and can control the screen, etc. When finished, I close the Screen Sharing window and a few moments later Casper Remote detects the closed connection and notes that in the Screen Sharing connections window.
Also, looking at the casperscreensharing account in dscl, it appears just like any other local account, complete with a home directory, full name, password, UID, GeneratedUID, even a user picture! :) So it seems it should be possible for them to just create the account with a disabled shell to prevent using it to connect.

I'd say the only downside is that the Screen Sharing.app can't possibly know the User Shell has been disabled for that account, and so it just tries and tries and tries to connect, with no message as to why it can't. I'd imagine eventually it will just time out, but I haven't let it try long enough to know.

Definitely post back when you discuss it with JAMF as I'm curious what their thoughts are on this.

Sorry @CasperSally, I wasn't quite getting it.

But as usual @mm2270 stepped in. :)

Hope you get the answers from JAMF you're after. Please report back!

@mm2270 @bentoms

JAMF said it looks like a great solution, but it's unsupported, and I'll have limited support from them if there are issues.

Not exactly the answer I was hoping for that they would be looking to implement something in the future. Hoping to do some testing today on this on my own.

@CasperSally Thanks for reporting back on that. I'm not in the least surprised by their response. It is, of course, unsupported since its modifying the original process (slightly) Though it may be a good solution, its a hack. Not a particularly dangerous hack, but a hack nonetheless.

I'm hoping JAMF will consider implementing something (as I originally mentioned) that would be an option in the JSS to prevent log in to the casperscreensharing account in the future. Its not impossible to do, but they will have to decide if this warrants an actual feature in the product. From the standpoint of security/transparency, I'd say it would make a good feature to have in there.
Speaking of that, did you actually make a Feature Request out of this? I can't recall now. If not, might be a good idea to get that in to get votes on it.

@mm2270 - I just created the feature request here, thanks for the reminder. They always seem like such a drop in the bucket it doesn't always seem to be worth the effort, but it can't hurt.

https://jamfnation.jamfsoftware.com/featureRequest.html?id=3622