"Scott Packard" <scottp@%hash%.usenet.us.com> wrote in message
newsan.2004.10.18.18.10.30.813826@%hash%.usenet. us.com...
> On Sat, 16 Oct 2004 13:50:40 +0000, sinister wrote:

Scott---thanks for your response. It's a little beyond the scope of my
knowledge, but I appreciate the insight and effort.

Cheers.

>> A colleague of mine is connecting to a SunOs 5.9 server from a local
>> SunOs
>> 5.9 SunBlade. (I forget the name for this kind of login/window session;
>> XDMCP?)
>>
>> When she leaves the local host unattended, the screensaver comes up.
>> Eventually it locks the screen.
>>
>> When she tries to log back in, her password doesn't work. Searching the
>> web and USENET, I thought maybe the root password would work, but that
>> doesn't work either.
>>
>> Any solution? I'm not even sure how to diagnose the problem; all I've
>> found so far by internet research is that the process probably
>> responsible
>> for locking the screen is dtsession.
>
> It's probably due to an incorrectly configured /etc/pam.conf.
> First, make sure you have all the latest patches in place.
> Second, I found I had to put in an explicit dtsession "trap" to account
> for just this problem. dtlogin covers the user logging in, but dtsession
> covers the screenlock problem. You've configured dtlogin to allow the
> user to login, but you haven't configured dtsession, so whatever "other"
> does is what transpires as the user tries to unlock the screen.
>
> FWIW, my traps are as follows:
> login auth requisite pam_authtok_get.so.1
> login auth required pam_unix_auth.so.1
> login auth required pam_dial_auth.so.1
> login auth sufficient /usr/lib/security/pam_afs.so.1
> setenv_password_e
> xpires try_first_pass ignore_root
> #
> # 28-Jul-2004 SEP: Providing explicit dtsession because when screen locks
> # I can't unlock it and it seems to be related to dissimilar nis/afs
> # passwords.
> #
> dtsession auth requisite pam_authtok_get.so.1
> dtsession auth sufficient /usr/lib/security/pam_afs.so.1
> try_first_pass setenv_password_expires ignore_root
> dtsession auth sufficient pam_unix_auth.so.1 try_first_pass
> #
> dtlogin auth requisite pam_authtok_get.so.1
> dtlogin auth sufficient /usr/lib/security/pam_afs.so.1
> try_first_pass setenv_password_expires ignore_root
> dtlogin auth sufficient pam_unix_auth.so.1 try_first_pass
> #
> su auth requisite pam_authtok_get.so.1
> su auth sufficient /usr/lib/security/pam_afs.so.1
> setenv_password_expires try_first_pass ignore_root
> su auth sufficient pam_unix_auth.so.1 try_first_pass
> :
>
>
> I have at least one other to account for sshd, but that's unrelated to
> your problem. I mention it only so you'll set it up in yours iff you
> use ssh with PAM.
>
> The last thing to ponder is: Why didn't I just use "other" as a general
> trap, like the manual says? Answer: I remember trying to take that
> course in the beginning, but OpenSSH didn't really get with PAM until
> very recently so I had to break it out of the other. I think it was my
> messing with OpenSSH and a general lack of knowledge of PAM[1] that
> caused me to do things this way. PAM has dramatically changed in the
> last few years, and it is a pain to get PAM, TCP Wrappers[2], and other
> things to work with each other.
>
> Regards, Scott
>
> [1] General Google info on PAM usually covers Linux versions, or is
> just plain obsolete with respect to Solaris.
>
> [2] TCP Wrappers /etc/hosts.allow and /etc/hosts.deny can behave
> differently depending on how the source code was built. OpenSSH
> also behaves in its own way, and is not documented anywhere.