William Yang wrote:
Yes. But, we use our own compiled xscreensaver since the Sun-shipped one
had issues interacting with the pam_krb5 we use (slightly patched version of
Russ Allbery's pam-krb5). So RHA is not triggered by the screensaver,
although it is still invoked on a smart card hotdesk event.
If you use pam_sunray.so on your PAM stack, then RHA should still be
triggered.
We didn't modify xscreensaver for SRSS.
So I know our setup isn't supported, but I can come up with a theoretically
supported situation which should be equivalently impacted:
Site uses NFSv4 with Kerberos for home directories. User's tickets expire
while detached, RHA does not refresh tickets on attaching, and user has lost
access to home directory (the same thing basically happens with our AFS
setup).
If you have pam_sunray.so on your xscreensaver stack, then everything
should work. But the screensaver has to be well behaved in a few ways:
- It must not require a user interaction (i.e. it must not assume that
conversation function will ever be called)
- It must call pam_authenticate immediately upon session lock, and not
wait for events like mouse movement or keyboard events first
The model is that even though authentication occurs outside of the
session with RHA, we still run the PAM stack for the screensaver when
the desktop session is connected. It's at that time that tickets should
be refreshed. pam_sunray bypasses the authentication interaction with
the user, but the PAM authentication stacks are still processed,
including pam_sm_authenticate and pam_sm_setcred(PAM_REFRESH)
-Bob
The same resolution for that setup should be applicable to our AFS setup.
Any ideas?
Thanks,
William Yang
-----Original Message-----
From: [email protected] [mailto:sunray-users-
[email protected]] On Behalf Of Bob Doolittle
Sent: Monday, February 02, 2009 5:46 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:
4.1 on S10U6. I don't know if this is possible because of the way AFS
does
PAGs.
And pam_sunray is on the xscreensaver (or dtsession-Sunray if CDE) stack
in /etc/pam.conf?
I'm afraid I don't know anything about AFS and we don't support it :(
-Bob
William Yang
-----Original Message-----
From: [email protected] [mailto:sunray-users-
[email protected]] On Behalf Of Bob Doolittle
Sent: Monday, February 02, 2009 11:12 AM
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:
Regarding RHA security...
Does anyone else on the list deploy Sun Rays in a Kerberos 5 and AFS
setup?
We seem to be stuck with forcing users to unlock twice since
unfortunately
we need the screensaver to refresh a user's tickets and tokens. Since
the
RHA dialog creates a temporary session, the tickets and tokens for the
user's session aren't refreshed when it is used, so for the time being
we
use RHA and screensaver lock to achieve better security and still
maintain
the ability to refresh session creds. Any ideas?
What version of SRSS?
What OS platform are you using? If it's Linux, then we may have an
issue
here since gnome-screensaver doesn't handle PAM properly so we can't
utilize pam_sunray (which refreshes creds on the screensaver stack) and
use utxunlock instead. utxunlock has no way of directly refreshing
creds.
-Bob
William Yang
-----Original Message-----
From: [email protected] [mailto:sunray-users-
[email protected]] On Behalf Of Joerg Barfurth
Sent: Monday, February 02, 2009 6:39 AM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] How to make JDS lock screen lock the
screen
and not utdetach with NSCM
You can do much of what you desire by editing /etc/pam.conf. But the
result is an unsupported configuration.
David Markey schrieb:
They could manually detach the session using shift+pause, its just
complicated for our users and id like to disable it. i see its hard
coded into xscreensaver. Any way to disable it even unsupported?
You could remove or turn into a comment the
xscreensaver auth sufficient pam_sunray.so syncondisplay
line in /etc/pam.conf.
The price you have to pay for that is that when hotdesking to a
different DTU with your NSCM session or after the session has been
detached in whatever other way (e.g. by rebooting the DTU), you'll
have
to enter your password twice - first for NSCM, then for the
screensaver.
You also lower security for your session, as explained by Bob.
Also, when i do a utswitch -h <hostname> the previous user name gets
entered into the new sunray servers login, any way to disable that
also?
For NSCM users: To get rid of the name you can use the startover
button.
To never get that name in the first place, you could try to remove
the
utgulogin auth requisite sunray_get_user.so property=username
line in /etc/pam.conf.
To achieve the same effect for smartcard users, you'd need to also
remove the
dtlogin-SunRay auth requisite sunray_get_user.so
property=username
line. Beware: This might be incompatible with NSCM (though I haven't
tried). In any case you enter unsupported territory here.
Do not remove the analogous line for utsclogin!
HTH
- Jörg
_______________________________________________
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
_______________________________________________
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
