Guenter Millahn gave very detailed instructions:
> It seems you have wrong access attributes to passwd.org_dir
> and cred.org_dir
> Do the following:
> nischmod n=,og=rmcd,w= passwd.org_dir cred.org_dir
> nistbladm -u public_data=o=m private_data=o=m cred.org_dir
> nistbladm -u passwd=o=rm shadow=o=r passwd.org_dir
>
> If this won't work please try to open your passwd.org_dir:
> First, open it for 'world' users:
> nischmod w=r passwd.org_dir
> and try it again.
>
> Next chance: Open it to 'nobody' users:
> nischmod n=r passwd.org_dir
>
> If this doesn't work ask again.
> If you can login and get error messages like "cannot decrypt
> secret key..." you are a so called 'unknown user'. Your
> credentials are wrong or you haven't any. Do this as an ordinary user:
> Have not: Generate it with nisaddcred
> Wrong: Update it.
> keylogin, Password is you RPC-Pwd (old passwd, 'nisplus', sometimes
> your new one.
> chkey -p
>
> Sometimes NIS+ waits 2-3 min to update the NIS+ Network Tables. It depends
> of your network traffic.
Unfortunately when I received his messages I had already acted
according to a earlier answer, which had lead me to reinstall everything
as this was a new installation and therefore I had no backups yet:
> SRDB ID: 15047
> SYNOPSIS: Unable to authenticate
> NIS+ server
>
> DETAIL DESCRIPTION:
>
> "nisaddcred" failed with the error message "Unable to authenticate NIS+ server"
>
>
> POSSIBLE CAUSE or USER ERRORS
> -----------------------------
> (In no particular order.)
>
> - Change root password in /etc/passwd on a NIS+ server without re-encrypting
> the secret key stored in the cred table. Should do "chkey -p" immediately
> after changing the password.
>
> *Note that this problem may lurk for some time. If the superuser secret
> key is already stored in the keyserv when the root password is changed,
> you'll probably not see any problem until the keyserv is restarted (usually
> at the next system reboot).
>
> - Remove DES cred table entry for any NIS+ server.
>
> - Overwrite existing credentials, by executing nisaddcred,
> chkey (without "-p"), or newkey for any NIS+ server.
>
> - Keyserv killed and not restarted on any NIS+ server.
>
> - Keyserv restarted on NIS+ server, without restarting rpc.nisd. The
> rpc.nisd has an open connection to the existing keyserv, and is
> unable to re-open that connection.
>
> - /etc/.rootkey removed, or replaced with a copy that doesn't match the
> secret key stored in the cred table, and internally in the NIS+ table
> headers.
>
> - The publickey entry in /etc/nsswitch.conf isn't just "nisplus", so
> secure RPC keys can be obtained from some source (NIS, files) that is
> inconsistent with the NIS+ tables.
>
> SOLUTION SUMMARY:
>
> Several SRDBs discuss recovering from the lost or corrupted
> encrypting key, but there is no sure and safe scheme to retrieve
> the public key once it is mingled.
>
> The following two methods will bring the NIS+ back in operation.
>
> 1) Rule #1 with NIS+. BACK UP the /var/nis directory of all the NIS+
> servers. Recovery from tape always works.
>
> 2) If that is not available, dump the contents of NIS+ namespace, and
> reinitialize the NIS+ server.
Thanks!
-- Leandro Guimaraens Faria Corcete Dutra http://www.lge.com.br./ leandro@lge.com.br http://www.terravista.pt./Enseada/1989/ BRASIL
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:41 CDT