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