Casper Remote Screen Sharing authentication fails ('Permission Denied') for AD group members

robo
New Contributor III
New Contributor III

We're using JSS version 8.61, bound to AD.

We have an odd problem with Casper Remote Screen Sharing. Accounts individually added to the JSS (either local or AD) and given permission to "Use Casper Remote" and to "Screen Share with Remote Computers" can successfully screen share with Casper Remote.

However, most of the accounts we use to authenticate to the JSS are allowed via membership in an AD group. For the most part, this works fine, but these accounts cannot successfully screen share using Casper Remote. They can use other Casper Remote features successfully (executing a policy on a remote machine, for example) but when screen sharing is attempted, the process fails right at the end with a 'Permission denied for example_user_123' error in the /var/log/jamf.log on the target, and 'Permission denied to share screen' shown in Casper Remote.

In Casper Remote, in the 'Status' field, the connecting user sees "Authenticating..., Opening ssh connection, Verifying..., Starting screen sharing", but then gets 'Permission denied to share screen' right at the end. To reiterate, the AD group they are a member of has permission to "Use Casper Remote" and to "Screen Share with Remote Computers", and the same user, when removed from that AD group but added to the JSS as an individual LDAP user with those checkboxes ticked, can connect successfully.

Is this a known issue?

Thanks,
Robin

14 REPLIES 14

andrew_stenehje
Contributor

We have a similar problem and it's due to the fact that we manage ARD access using an OD group, of which the casperscreensharing user is not a member. When you screen share in Casper, it creates a user named "casperscreensharing" for this purpose. If this user it created doesn't have permission to screen share, it will fail. We had to add a user named "Casperscreensharing" as a user with remote privileges on the machine for it to work. We did this through creating an ARD package that creates this user and also points to directory services for which users have remote rights.

robo
New Contributor III
New Contributor III

hi andrew,

Hm... I guess I'm not following your explanation. I understand that a 'casperscreensharing' user is created, but why would casperscreensharing authentication fail when the Casper Remote user is part of an AD group allowed to use Casper Remote and Screen Sharing, but succeed when the Casper Remote user is an individual AD user with the same rights?

andrew_stenehje
Contributor

Hi Robin,

I'm not totally sure what would be causing it for your environment... just that the local "casperscreensharing" account that gets created didn't work in our environment because it wasn't a member of the "ard_admin" group. If you're not a member of this group, the way we're setup, you don't have permissions to Screen Share with other machines.

robo
New Contributor III
New Contributor III

Just an update - we're working with JAMF on this and it currently looks like it might be a bug, but we're waiting on a final answer and (hopefully) resolution.

aamjohns
Contributor II

robo,
If you get a resolution would you mind posting it on here? I am having the same problem you are. Thanks, Aaron.

BaddMann
Contributor

ditto

Bukira
Contributor

we had this issue and it was fixed, our ldap lookups were not pulling in the information correctly,

Check your mappings for the AD LDAP Server in the JSS, we had some wrong mappings, once fixed this all worked fine for us,

We are using v8.6 but we tried all versions past this int eh lab and same issue till we fixed the mappings,

Ask JAMF what the mappings should be as this was a few months ago and I cant remember what we changed and why I had the different in the first place

robo
New Contributor III
New Contributor III

Bukira - we've had JAMF look at our mappings and everything looked kosher to them. No resolution yet though.

robo
New Contributor III
New Contributor III

BTW - aamjohns and BaddMann: Have you reported the issues you're seeing to JAMF support?

aamjohns
Contributor II

Yes. I did last week.

BaddMann
Contributor

I haven't as my AD environment appears to be to blame. We require the Domain in front of the user for a lot of our users, the LDAP lookup doesn't provide the domain when lookups are performed.

I don't think our unique environment needs to be taking up JAMF resources at this point in time.

twrangham
New Contributor III

Curious, any updates on this topic? We are seeing this behavior as well in our environment. Curious on what the Sharing settings should be to get Casper Remote Screen Share to work? According the Casper Administrators guide its just having SSH turned on? Im attempting this also with an AD user in a AD group listed with All Privileges in the JSS. I have tried a few different Macs, all getting "Permission denied to share screen"

Any ideas?

alan_trewartha
New Contributor III

we had a similar thing, and it was down to the controlling user's account not being valid (for obscure uninteresting reasons). so you couldn't su to the account on the clients that were trying to be viewed. once we'd fixed that it worked ok.

twrangham
New Contributor III

Thanks alan for the response. Last week I did get a response that this is a known issue with CasperRemote for using LDAP groups. You have to enter LDAP users individually, and they will then have the ability to use CasperRemote if you give them the correct privilege in the JSS. A bit annoying, especially if your LDAP group in the JSS contains the users you want to grant this ability, because I found adding those same users individually doesnt work either. It must be a LDAP user not a part of the group. So currently I'm left with LDAP groups for most functions, and then a separate account for anyone needing to remote control a Mac using Casper.