From: haley@husc10.harvard.edu (Elizabeth Haley)
Newsgroups: comp.unix.shell,comp.unix.admin,comp.unix.wizards
Subject: Re: Locking out users
Date: 27 Sep 92 08:10:50 GMT
Article-I.D.: husc3.1992Sep27.041052.15880
Organization: Harvard University Science Center

In article <BZS.92Sep26222930@ussr.std.com> bzs@ussr.std.com (Barry Shein) writes:
>
>Errr, bad idea.
>
>On large servers a sync can pause the entire system for a few seconds,
>it's not always a "favor", and may even give a malicious user a way to
>harass you by causing the system to sync repeatedly.
Hmm, good point...

>>But all in all it seems easier to remove their directory to
>>some tar device, can the passwd line, and send them snail-mail to say
>>yer mad at them, or some script that prints this on the screen when
>>they try a log on...
>
>Seems like you're setting yourself up for a lot of work if it was just
>some misunderstanding (like if the trouble was caused by someone
>getting into an honest user's account and all that's really needed is
>a change of password or something.) I don't know why you think this is
>easier than, eg, just putting a * in front of the person's passwd
>encryption and/or the message.
>
The whole point is that it shouldn't be extremely easy, at least where
the administrator of the machine is not the owner...

If someones doing something wrong, and does it enough to warrant a
lock out, you should probably can them. If someones account is being
used without their permission, and you figure it out, change their
passwd, so that they have to come to you to get back on...

My method is this:
1. Is someone doing something *very* wrong? Kill the process, and send
a note explaining why.
2. Do they continue to do it?
	Send another note, asking why they have continued this
behavior.
3. And more? passwd change.
4. User comes by to find out why account is locked, ask why they have
continued whatever behavior. If the explaination is resonable, find
compromise. If not suggest that privs will be terminated unless it is
stopped.
5. Continued? Terminate priveledges. No bulls**t suspension or
whatever, if they are being stupid, can them, cause you can't always
cure stupidity, but that doesn't mean you have to put up with it.

The only reason I suggest saving their files, etc to offline storage
is that their work might be owned by someone else, for example, a
research assistant for a professor. When whoever comes to claim the
data, etc. you can let them know why it was being held offline, and
perhaps proper disiplinary action could take place...

Of course, in the case of someone going on sabbatical somewhere and
someone else abusing the account... Hmm I don't know. You might need
to keep the physical account for the maintainence of .forward files or
mail collection, whatever. I think the passwd change might suffice
there, with a bit of monitoring.
You might even be able to rig a bit of authentication in the task
scheduler, perhaps having it check to see if an account is "active"
before allowing a job to enter the queue.  Then you could catch
malicious types by the clue that an inactive user is trying to submit
jobs, when the account owner should know that they are "inactive" and
probably in another state...
Sorry if I ramble...