But wouldn't that only work using the traditional Solaris pam_krb5 model (which is to use the same cred cache for every session as long as it's the same user)? The problem is that RHA processes the password verification in the uthotdesk stack, using a temporary session, and in our case a temporary ccache that gets thrown out later. When that stack exits, it kicks back up to the xscreensaver stack, where it sees that the RHA unlock was successful and exits the PAM stack since it is "sufficient" for pam_sunray.so. The successive pam_setcreds may get called, but pam_krb5.so can't renew the creds without the user's password. Even if the password were passed back up, I think this pam_krb5 by design will not attempt to setcred if it was not the module that successfully authenticated the user. Please correct me if I'm not tracing the PAM stack properly.
I'm not sure why our screensaver isn't triggering the RHA dialog at all...I know the stock xscreensaver doesn't call the stack as soon as you lock, that was a patch worked into the Sun xscreensaver. But even when the screensaver dialog is triggered, the RHA dialog still doesn't come up, but for our purposes that is okay. Can someone out there verify that RHA is able to refresh their Kerberos tickets if they are per-session? Or is that something I will need to file an RFE for, especially since right now the pam_krb5 included in Solaris doesn't support per-session ccaches? William Yang > -----Original Message----- > From: [email protected] [mailto:sunray-users- > [email protected]] On Behalf Of Bob Doolittle > Sent: Thursday, February 12, 2009 6: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: > > 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 _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
