problems changing password

[Carroll, Jim]

> This sequence does not appear to be correct.  The prompt for the old
> password should be first.
> 
>    $ nispasswd
>    Enter old NIS+ password: 
>    Enter new password: 
>    Re-enter new password: 
>    NIS+ password information changed for <user>
>    NIS+ credential information changed for <user>

Gah.  Okay, my first mistake:  I was using passwd instead of nispasswd.

Armed with that knowledge, this is what transpires on the RedHat host:

$ nispasswd
Enter old NIS+ password:
Enter new password:
Re-enter new password:
ERROR: Only partial success
        secret key: Could not reencrypt secret key

Then a subsequent ssh login (with the new password) to that host as that
user shows no problems.  However, a subsequent login (also with the new
password) to a Solaris box reveals:

$ ssh jcarro10 at localhost
jcarro10 at localhost's password:
Password does not decrypt secret key (type = 192-0) for
'unix.1095 at webdev.sprintspectrum.com'.
Password does not decrypt any secret keys for
unix.1095 at webdev.sprintspectrum.com.
Last login: Thu Apr  4 17:45:06 2002 from localhost
Sun Microsystems Inc.   SunOS 5.8       Generic February 2000

[major tangent here, trying to figure out exactly which combo breaks the
secret key, and how to resolve this...]

It now appears that once the secret key is broken (thanks to trying to run
nispasswd on Linux), the only way to repair it is to login to the Solaris
master and run:

   # nisclient -ocl nisplus jcarro10

Using myself as an example, I've had no problems changing my NIS+ password
under Solaris, but the minute I try it under Linux, I need to rebuild the
credentials.  (By "broken credentials", I mean that logging in as myself
causes both Linux and Solaris to complain, and I'm unable to supply keylogin
with a satisfactory password (neither the old nor the new passwords work,
nor does the original password supplied with the nisclient command).)

> I suspect you have RedHat.  If so, the file you seek is
> /etc/sysconfig/authconfig, but I don't think it explains your
> troubles.

Agreed.  I toyed with it for a bit, but no noticeable effect.  Thanks for
the info anyway.  :)

> I have not debugged the problem, but I cannot use the supplied
> passwd entry in nsswitch.nisplus.  Instead, I have
> 
>    passwd: files nisplus
> 
> I'm uncertain if this has anything to do with your question.  Wild
> guess: do you mistakenly have an /etc/passwd entry for the test user?

I'm using the following:

   passwd: compat
   passwd-compat: nisplus

because we're using netgroups.  Aside from the netgroup entry "+ at unixsa" in
/etc/passwd and /etc/shadow, those files are vanilla, devoid of any user
accounts, including my own.  I should point out that I have no problems
logging in as myself, whether I use ssh, or whether I sit at the console and
login via xdm.  And yes, I can successfully unlock the console after the
screensaver kicks in.

Except for the odd behaviour of nispasswd on Linux, I'd say everything is
working like a charm.

I don't know if this is worth mentioning or not, but when I set up the
passwd table on the Solaris master, I deliberately excluded the default
accounts (eg, root, daemon, bin, sys, etc.) and chose to focus on just the
user accounts.  I haven't come across anything which says that this is a
good approach or not; I'm merely taking a page from my NIS days, when it was
strongly recommended to leave root out of the passwd map.  If anyone can see
a possible reason for this to cause the problems I'm seeing, let me know.
(If it *is* causing problems, it's unique to Linux, because I'm not seeing
this problem when I try it on a Solaris client.)

Ideas?  Suggestions?  Tips?  Darts and laurels?

Jim Carroll