By issues I meant
1. not going to NSCM login when the screensaver is activated
2. having a way to get from the screensaver to the NSCM login without
unlocking the screen

RHA is fine, but back several years ago when we were trialling NSCM
internally, we were using US-II server hardware, where a lot of the time a
user simply wanted to lock their screen for a short time and another user
would not be using that station while the screen was locked.  However, to
get to NSCM login and back takes a much longer amount of time than just
unlocking the screensaver, so our workaround was the one I mentioned below.
Simply a case of differing customer requirements.

William Yang

> -----Original Message-----
> From: [email protected] [mailto:sunray-users-
> [email protected]] On Behalf Of Bob Doolittle
> Sent: Friday, January 30, 2009 2:08 PM
> To: SunRay-Users mailing list
> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen
> and not utdetach with NSCM
> 
> William Yang wrote:
> > Some time ago when we tried out NSCM here, we were able to work around
> both
> > issues.
> 
> You still haven't mentioned an "issue" here. What is the problem you are
> trying to solve?
> Why isn't NSCM's behavior suitable for your purposes? It forces a user
> to authenticate before gaining access to an existing session in a manner
> similar to a screensaver, but with added security (see below).
> 
> In 4.1, we introduced RHA (Remote Hotdesk Authentication). This behaves
> a lot like NSCM when a screen is locked. You can read about it in the
> Administration Guide, but it's intended to provide added security,
> particularly in light of some features coming in the future which will
> make it easier for a malicious user to "spoof a token". Work was done in
> 4.1 (and is ongoing) to harden SRSS against such attacks, including RHA.
> RHA makes token-spoofing (without additional Solaris authentication)
> incapable of disrupting legitimate non-Kiosk users of the token . It
> also protects against a flaw in the X protocol which can prevent screen
> locks upon card removal in certain circumstances as well as certain
> problems which may occur due to bugs in screensavers.
> 
> If you don't like the RHA behavior, and are willing to accept the
> security risks with legacy pre-4.1 behavior, you can utilize the -D
> option in utpolicy (in the browser administration GUI this is described
> as "Direct Session Access" which can be enabled but is off by default).
> We recommend that you do not disable this feature, however.
> 
> -Bob
> 
> > However, we were using xscreensaver (compiled ourselves) and not
> > gnome-screensaver.  We commented out the line that Sun Ray added to the
> > xscreensaver PAM definition, then enabled the "New Login" button in
> > xscreensaver usually used for gdmflexiserver, but on our Sun Ray servers
> we
> > configured it to execute utdetach instead.
> >
> > William Yang
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:sunray-users-
> >> [email protected]] On Behalf Of Craig Bender
> >> Sent: Friday, January 30, 2009 1:28 PM
> >> To: SunRay-Users mailing list
> >> Subject: Re: [SunRay-Users] How to make JDS lock screen lock the screen
> >> and not utdetach with NSCM
> >>
> >> That behavior is by design.  What would a person do who wasn't the user
> >> who locked the screen do when they wanted to use that terminal?
> >>
> >> David Markey wrote:
> >>
> >>> Hi Everyone
> >>>
> >>>
> >>> With JDS in a non smart card session mobile session when i lock the
> >>> screen it just does a utdetach in effect.
> >>>
> >>> How can i make it just execute gnome-screensaver like normal?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Thanks
> >>>
> >>> David
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > 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
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users

Reply via email to