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.
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
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
