Skip to main content

So, I don't see folks complaining about this on the forums so I'm guessing that I and my institution are special. Over the past several versions of JSS 9.x I've experienced an issue where, when using Casper Remote's screen sharing option login as yourself: "casperscreensharing" which allows an approved Casper Remote user to log into a users computer in a background desktop environment, the device looses 802.1x wireless connectivity. When I selection the option to share the users desktop, via CasperRemote's use of Screen Sharing everything works as expected.

Any thoughts on where to chase this little demon?

Now this isn't an answer, more of a direction to look into because I'm curious of the fix myself as my campus will be using 802.1x in the future. So I have two questions, the first being, is the user profile you're logged into part of the domain and has a 802.1x certificate? If so, have you thought of adding your AD profile as an authenticated user for every single casper suite binded machine on your campus?? I think that may fool the system into allowing the 802.1x wireless connect to maintain itself because each of the "users" on the laptop are both authenticated via 802.1x on the AD domain.

Let me know if that helps!

Well, most of that is pretty easy to answer. No AD binding and no profiles being pushed to implement the 802.1x certificates. Our individual users, on local accounts log into and accept the certificates from our Clearpass system. Honestly I believe that it has to do with something along the lines of the other user (casperscreensharing) not being similarly authenticated and killing the connection. The only thing bugging me about it is the whole "... but it used to work" factor. I'm going to be running some more tests on this next week as it's lower on my priority scale.

Terms & ConditionsCookie settingsAccessibility statement