Hi,
My original post and all replies are enclosed. Thanks a lot, guys. Your help
is really appreciated!
Rasana
>I'm testing NIS+ with a rootmaster and three clients. My machine is a NIS+
>client.
>
>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
>place?
>
>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.
>
>Rasana
---------------------------------------------------------------------------
From: rloftin@engsys.mc.xerox.com (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: rangern@cirano.umontreal.ca (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
Example:
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 <john@oncology.uthscsa.edu>
Rasana,
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
>mylogin.mydomain.:LOCAL:{groups}:
>mylogin.mydomain.:DES:unix.myuid@mydomain:credentials.....
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
password:
If it doesn't work you can try to set it again with chkey:
mylogin> chkey -p
old passwd:
new passwd:
new passwd:
---------------------------------------------------------------------------
From: slash@comp67.snu.ac.kr (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" <Reggie_Stuart_at_~ISTG2__PO@smtpinet.aspensys.com>
Hi,
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
/etc/passwd.
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 ~
~ Rasana.Atreya@library.ucsf.edu ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:13 CDT