nisplus authentication problem

Aaron Cheek aaron_cheek at
Mon Jan 6 23:37:17 EST 2003

> If nisdefaults runs OK, then try "nismatch someuser
> ("someuser" is replaced by some real username in the
NIS+ server database).
> If all is well, you should see an encrypted passwd
entry in the second field
> (after the first colon) of the output. If you see
something like "*NP*"
> instead, then again, the NIS+ server is not giving
the password back to the
> client (doesn't trust it).

A small comment to this.

The above should only happen if you have correctly
authenticated in front of NIS+ as someuser, which
usually happens when you login as that user. When
doing niscat passwd.org_dir after correctly
authenticating, someuser should only see the
unencrypted password file for him, but the password
fields for the rest of the users should be *NP* (i.e.
no permission).

You should not see the encrypted passwords of any user
when running nismatch or niscat as any other user
(root included) from any client system, except in the
hosts that belong to the admin group: 

# niscat -o passwd.org_dir
Object Name   : passwd                                
Owner         :                  
Group         :                   
Domain        :                 
Access Rights : ----rmcdrmcd----                      

Root of systems in this group should be able to see
them. In general, no host should belong to the admin
group except for NIS+ masters/replicas.

There is a classic problem with a broken default
configuration of NIS+ where the permissions are too
loose, so root from any workstation can niscat the
NIS+ tables (sometimes even non-root users). If this
is the case, permissions must be tigthened, because on
the contrary security goes back to pre-shadow times,
where passwords can be listed and crack may be
attempted against them.

(If you need more information about this, don't
hesitate to ask)


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

More information about the linux-nisplus mailing list