Re: Sun Ray doesn't present lock screen

Clift, Tom CIV NSWCDD, K55 wrote:
> Bob, thanks for the information. It's nice to know what is actually 
> going on behind the scenes to help with troubleshooting and relaying 
> the pertinent information to the group.
> If the problems happens again (we are now running with "-D") I will 
> look for the detached Hotdesk sessions and kill them and let you know 
> the outcome.

If you are running the -D then RHA is not in effect and you will never 
see Hotdesk.* tokens for sessions. You needn't bother looking for them.
With -D we don't disconnect the user session or create an additional 
session for authentication upon hotdesking. We simply connect directly 
to the user session and rely on the screensaver/locker to provide 
security for session access.

-Bob

>
> We run in a closed network and really don't have to worry about the 
> DOS or token spoofing attacks so running with the -D doesn't really 
> concern us.
>
> I can get you more information in a direct email conversation if you 
> think it will help with troubleshooting the problem and truly fixing 
> it instead of a patching it.
>
> Thanks again for the information,
>
> Tom Clift
> NSWCDD - K55
> 540-653-8023
>
>
>
> From: Bob Doolittle
> Sent: Tue 8/3/2010 12:31 PM
> To: SunRay-Users mailing list
> Subject: Re: [SunRay-Users] Sun Ray doesn't present lock screen
>
>
> Clift, Tom CIV NSWCDD, K55 wrote:
>> Sorry it was a hotdesk token reported and not a payflex. Sometimes 
>> the fingers type different than what the brain is telling it to.
>
> Thanks for clarifying this significant point.
>
> In that case, I have another workaround for you if you value the extra 
> security provided by RHA.
>
> First, some background.
> When a user attempts to access an existing session, RHA creates a new 
> session for them to authenticate to, to protect against the attacks 
> described previously. It starts up a greeter in the new session and 
> only connects to the actual user session after successful authentication.
>
> If that greeter itself becomes detached, it should self-destruct its 
> session (just the greeter session, not the user session), and a new 
> one will be created as needed in future. However, for unknown reasons 
> once in a rare while the self-destruct doesn't occur, resulting in a 
> persistent detached RHA greeter session.
>
> A detached RHA session (which has the token form Hotdesk.*) is an 
> illegal condition that should never occur. It is always safe to kill 
> such sessions and your problem will resolve.
>
> So, the workaround:
>
> I think if you use utsession to detect and kill a detached Hotdesk.* 
> session when this situation arises you'll find such sessions are quite 
> rare, although once the problem occurs it persists and has broad 
> effect (the DTU it is associated with cannot be used to attach to 
> existing sessions until the orphaned RHA session is cleared).
>
> I guess it's time to develop a fix to "self-heal" this situation when 
> detected, since the underlying problem is so elusive and meanwhile 
> customers are impacted. I hate the idea because it's ultimately just a 
> patch over a real problem and will make diagnosing the underlying 
> problem much more difficult (because nobody will even know the problem 
> has occurred unless they happen to see it in the logs), but clearly 
> it's most important that we provide a robust experience to our 
> customers. It's possible that the underlying cause has to do with 
> resource constraints on the server at the time we try to kill the 
> detached RHA session, in which case it needs a fix like this anyway.
>
> -Bob
>
> _______________________________________________
> SunRay-Users mailing list
> SunRay-Users <at> filibeto.org
> http://www.filibeto.org/mailman/listinfo/sunray-users
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SunRay-Users mailing list
> SunRay-Users <at> filibeto.org
> http://www.filibeto.org/mailman/listinfo/sunray-users
>