I discovered recently that users w/o NIS+ credentials are unable to change
their own passwords under Solaris 2.6, whereas under 2.5.1 this wasn't an
issue. I asked if anyone else had had this experience.
I didn't receive any confirming or denying replies. But I've spent time
wrestling with the problem and yakking with Sun Service and feel confident
that I have in fact identified a difference between Solaris 2.6 and 2.5.1.
There may be a work-around lying in /etc/pam.conf, but I've quit looking.
I'm dumping this cluster of users -- the ones w/o credentials -- from NIS+
into files and thus avoiding the problem.
--sk
Stuart Kendrick
Network Services
CNS
Original query:
Hi,
Under 2.5.1, I have been running a collection of users who exist in the
NIS+ tables but who don't have NIS+ credentials. Doing this saved me the
overhead of managing credentials -- restoring them after tragedy,
trouble-shooting credential-related problems. Worked great.
I gradually upgraded the Solaris coven to 2.6 ... and finally upgraded the
last machine, the one carrying all these users w/o credentials, from
2.5.1 to 2.6 a few weeks ago.
And now I discover that under 2.6, users w/o credentials can't change
their own password.
machine% passwd test
Enter login(NIS+) password:
passwd(SYSTEM): Sorry, wrong passwd
Permission denied
machine%
And here is what appears in syslog.
Apr 20 16:38:06 machine passwd[6158]: pam_chauthtok: error Permission
denied
I have been reading the man pages on pam_chauthtok, pam.conf, pam_unix.
I'm looking for a way out.
Option 1: dump NIS+, return to /etc/passwd, /etc/shadow. I know how to
do this.
Option 2: Give users credentials. Painful. Most of these people don't
know what telnet is; all they do is read mail via POP or IMAP-based
clients. I would have to teach these people how to telnet, run
/usr/bin/passwd, and sync their login password with their new NIS+
password. And from then on, I would have to debug NIS+ credential
problems -- those annoying times when the login password and the NIS+
password get out of sync.
Option 3: Perhaps there is some way for me to restore /usr/bin/passwd's
2.5.1 functionality. (Or, perhaps, reintroduce the bug in the 2.5.1
/usr/bin/passwd which allowed me to create this situation in the first
place.) I need to understand the PAM architecture better in order to
understand where I would need to insert my own code.
Does anyone have suggestions for reading on PAM? The man pages are
helpful, but I would like more.
--sk
Stuart Kendrick
Network Services
FHCRC
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:39 CDT