home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.sun.admin:6210 comp.unix.admin:4951
- Newsgroups: comp.sys.sun.admin,comp.unix.admin
- Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!terminator!ivrit.ra.itd.umich.edu!cmclark
- From: cmclark@umich.edu (Charles Clark)
- Subject: Re: NIS, slave servers and DNS access (actually disabling accounts)
- Message-ID: <1992Sep9.021746.25694@terminator.cc.umich.edu>
- Summary: clip the .rhosts file
- Originator: cmclark@ivrit.ra.itd.umich.edu
- Sender: news@terminator.cc.umich.edu (Usenet Owner)
- Organization: Lemon Mist Torte
- References: <1992Sep1.001928.17876@zia.aoc.nrao.edu> <21452@rpp386.lonestar.org> <ivan.715993948@durras>
- Date: Wed, 9 Sep 1992 02:17:46 GMT
- Lines: 23
-
- ivan@durras.anu.edu.au (Ivan Dean) writes:
- >This thread has moved off into the area of disabling accounts, which is
- >something I have had a bit of experience in. Recently we acquired sixty
- >Xterminals for our teaching laboratories, and they change things quite
- >noticeably.
- >
- >To recap, we've seen the following suggestions for disabling accounts :
- >
- >1. Alter the password field of the user
- >2. Alter the shell of the user
- >
- >Suggestion 1. doesn't work if the user has a .rhosts file, or the
- >/etc/hosts.equiv file allows them to log on directly, i.e. if a
- >"trust relationship" is set up from another working account, because the
- >user doesn't have to enter a password at all.
-
- Presumably, you are going to nix them from every system you have admin
- control of, and would not put a hosts.equiv in (at all, really) to a
- machine that is not one of your group's. So, if you do the above two
- actions, and clip their .rhosts file, doesn't that take care of it?
-
- --
- Charles Clark
-