NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/sun/admin/5995

Internet Message Format | 1992-08-31 | 2.7 KB

Xref: sparky comp.sys.sun.admin:5995 comp.unix.admin:4804
Path: sparky!uunet!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!news.cs.indiana.edu!umn.edu!lynx!zia.aoc.nrao.edu!rmilner
From: [e-mail] (Ruth Milner)
Newsgroups: comp.sys.sun.admin,comp.unix.admin
Subject: Re: NIS, slave servers and DNS access
Message-ID: <[e-mail]>
Date: 1 Sep 92 00:19:28 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Ruth Milner)
Organization: National Radio Astronomy Observatory, Socorro NM
Lines: 47

In article <[e-mail]> [e-mail] (Casper H.S. Dik) writes:
>[e-mail] (Alan Thew) writes:
>
>>I have a machine that requires DNS access which normally means running
>>NIS (yes I know it can be done without NIS but that's not possible in my
>>case). The machine will be a mail hub.
>
>>2) Can I take the password maps and somehow disable the passwords so that I
>>   have a list of usernames but they cannot logon to the mail hub.
>
>Disable passwords:
>
>+:*:0:0:::

Well, I've held off a few days waiting to see whether anyone else would
emphasize this, and nobody has (only Casper's brief mention below).

Disabling an account by putting some string, such as an asterisk, in the
password field *does not work* if the user is coming in with rsh or rlogin
from a trusted host (i.e. one listed in /etc/hosts or the user's .rhosts).
In this case, the password field is simply not looked at, period. If the
user can get onto some other system, say, their private workstation, they
can log onto any other system so long as their account name exists and their
hostname is in /etc/hosts.equiv (or in their own .rhosts file - which may be
provided to them by the server).

This goes for *all* accounts, not just general users. For example, bin.

Perhaps some of you will say "this is obvious", and perhaps, if you sit down
and think the whole process through, it should be. However, it is *not* obvious
simply from the documentation (passwd(5), for example, says nothing about
this being bypassed by the trusted hosts mechanism), and from many of the
messages I've seen here recently, it doesn't seem to be something that a lot
of people are consciously aware of.

This is why CERT recommends giving accounts like bin and sys false shells to
prevent access. If you haven't done so yet, do it *now*, and any other accounts
you have "disabled" as well.

>But better is a different login shell (.rhosts and all that):
>
>+::0:0:::/etc/nologin

This is the *only* way to truly disable an account (other than deleting it).
--
Ruth Milner                          NRAO/VLA                  Socorro NM
Computing Division Head      [e-mail]