From: Rasana Atreya (
Date: Thu Oct 10 1996 - 17:00:30 CDT


My original post and all replies are enclosed. Thanks a lot, guys. Your help
is really appreciated!


>I'm testing NIS+ with a rootmaster and three clients. My machine is a NIS+
>This morning, when I tried to login in:
>login: mylogin
>Choose a new passwd
>New passwd: mypasswd
>Re-enter passwd: mypasswd
>syslog: Fatal error: 19
>What's going on? Why did I have to chose a new passwd in the first
>Here's what I tried next:
>#nispasswd mylogin
>passwd: mypasswd
>re-ener: mypasswd
>"Unable to re-encrypt credentials for mylogin"
>#niscat passwd
>Shows all null passwords!
>What's going on?
>I would appreciate any pointers. I can't login 'cept as root.
From: (Ron Loftin)

Check the GCOS field in the passwd map. If you have any numerics in there,
( such as a phone number ), they may be getting interpreted as the password
aging controls. I've had similar difficulties under Solaris 2.5 with the
standard NIS.

From: (Normand Ranger)

Do they have "credentials". Your problem seems to be with
the credential file.

Try these lines with an user:

nisaddcred -r _login_name_._Domain_Name_.
nisaddcred -p _uid_ -P _login_name_._Domain_Name_. local
nisaddcred -p unix._uid_@_Domain_Name_ -P _login_name_._Domain_Name_. des

nisaddcred -r joe.CIRANO.UMontreal.CA.
nisaddcred -p 222 -P joe.CIRANO.UMontreal.CA. local
nisaddcred -p unix.222@CIRANO.UMontreal.CA -P joe.CIRANO.UMontreal.CA. des

From: John Justin Hough <>


 The login is not properly credentialled. This is overkill, but it
 works. If you created the users with admintool, and are running
 anything less than 2.4 and haven't patched admintool in 2.4 then
 it will not credential users properly. Since Sun broke admintool
 in 2.5 I have stopped using it entirely.

 See if user mylogin has credentials:

# nisgrep mylogin cred.org_dir

 Remove the old credentials:

# nisaddcred -r mylogin.mydomain. mydomain.

 Add them back in (with the current login passwdord):

# nisaddcred -P mylogin.mydomain. local
# nisaddcred -P mylogin.mydomain. -p unix.myuid@mydomain DES mydomain

 it will ask you for the login password

 Then I become (su) mylogin and rlogin into the same system (that way
 there is nothing but the user mylogin will associated with the
 controlling terminal, and make sure every thing is okay with keylogin:

mylogin> keylogin

 If it doesn't work you can try to set it again with chkey:

mylogin> chkey -p
old passwd:
new passwd:
new passwd:

From: (Choi)

Well, I had similar problem when configuring a new NIS+ client.
The problem was corrected by doing a `rdate comp67'(comp67 is our NIS+
server). Well, we use rdate for synchronizing time.
From: "Reggie Stuart" <>

     Did the system let you in anyway even though the user passwords were
     declared "incorrect"? Check out the man page on 'keylogin' and
     'chkey.' Hope this helps in the short term.
From: Sun Tech support

Hi Rasana,

Here is what you need to do to get your nis+ passwd table back with all the
correct info.

On the command line in the bourne shell type the following:

nisaddent -rvf /etc/passwd passwd

This assumes that your etc passwd has the correct info in it. This command is
going to replace everything in the passwd.org_dir with the contents of

Next on the command line in the bourne shell type the following:

cat /etc/shadow|nisaddent shadow

This will merge the shadow info from /etc/shadow into the passwd.org_dir table.
This also assumes that the /etc/shadow has all of the correct accounts in the
same order as they appear in the /etc/passwd.

Then when you type niscat passwd.org_dir you should see all the info. Don't
forget to set the shadow entries to the correct setting before the merge.

~ Rasana Atreya Voice: (415) 476-3623 ~
~ System Administrator Fax: (415) 476-4653 ~
~ Library & Ctr for Knowledge Mgmt, Univ. of California at San Francisco ~
~ 530 Parnassus Ave, Box 0840, San Francisco, CA 94143-0840 ~
~ ~

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:13 CDT