Got some good hints and one me too.
Thanks to:
John Walp
Francis Liu
Leanne Davis
Gary Franczyk
Tom Erickson
Ross Helfand
Wales Wong
James Quackenboss
for taking the time to respond, unfortunately none of their hints and
suggestions apply or cleared up the problem. Here is a condensed one
line summary of each of their suggestions and the results.
using passwd -r nisplus: no difference
Password aging: not used.
keylogin: is successful.
nisdefaults -av: shows correct info.
nismatch $USER passwd.org_dir: works, and can see the encrypted password.
tried "nisplus" and root password for the NIS+ password, didn't work.
/etc/nsswitch.conf is setup ok to use files and nisplus for passwd.
No NIS+ errors in /var/adm/messages on replica's and master server.
The only thing I did notice that I thought was strange (other than the
password problem itself) was when the user would type `passwd -r
nisplus -s`. This should give the password attributes for the user.
When run on the master server and the replicas, it gives the expected
result:
username PS
However when run from the client machines it shows:
username LK
But, running nismatch $USER passwd.org_dir` from the client shows the
encrypted password for that user. If the client machines think the
password is locked that would explain why the password can't be
changed, but why would they show the password is locked in the first
place, especially if the users can see their encrypted passwords in
passwd.org_dir? Am I missing something obvious?
Sorry for the length of this SUMMARY. My problem is not yet solved but
I appreciate all the help everyone has offered! My original question
is listed below. If anyone has any other ideas I will gladly entertain
them and once I figure this out, I'll post a follow up.
Original question:
Hello guru's,
We are having problems changing our passwords. We have one NIS+ domain
across 2 subnets. There is a NIS+ master and two root replicas, one
replica on each subnet. When a user tries to change his/her password
on any of the client machines using passwd, the session looks something
like this:
/home/user% passwd
passwd: Changing password for user
Enter login(NIS+) password: <xxxxx>
Sorry: wrong passwd
Permission denied
The credentials for the client machine as well for the users trying to
change their passwords look ok and they are authenticating correctly.
Furthermore, if the user logs on to any NIS+ root replica or the NIS+
root master, they CAN change their password successfully.
We have a mix of Solaris 2.6 and 2.5, and recommended patches have been
applied to all machines. Any ideas or hints on what to look for? I'm
at a loss right now. I will summarize once a solution is found.
Thanks for your help!
++++++++++++++++++++++++++
David Fitzgerald
Department of Earth Sciences Phone: (717) 871-2394
Millersville University Email: dfitz@snowball.millersv.edu
Millersville, PA 17551
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:50 CDT