[458] in winnt
Re: Admin privs restricted to workstation in domain
daemon@ATHENA.MIT.EDU (Tom Fitzgerald)
Mon Dec 13 14:06:12 1999
Message-Id: <199912131905.OAA28854@sligo.mit.edu>
To: bcvernon@MIT.EDU
cc: Tom Fitzgerald <tfitz@MIT.EDU>, Don Nelson <dnelson@psfc.MIT.EDU>,
ntpartners@MIT.EDU
In-Reply-To: Your message of "Mon, 13 Dec 1999 11:27:11 EST."
<9912131624.AA14649@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 13 Dec 1999 14:05:53 -0500
From: Tom Fitzgerald <tfitz@MIT.EDU>
> In general, giving out the administrator password is a bad idea, especially
> if all the workstation administrator passwords are syncronized. And it is
> different, especially because logging on as yourself provides useful
> auditing information.
My only major objection to giving admin privs to a normal user account is
that mistakes can potentially be more destructive (formatting a D: drive
when you meant to format a floppy, for instance).
This may be a good summary:
Giving user admin password:
- insulates user somewhat from bad mistakes
- makes it less likely user will leave system unattended when logged in
with administrative account
Making user member of local admin group:
- allows common admin password to be used on all systems
- allows user to do administrative tasks quickly without logout/login
- improves auditing if multiple people are administering system
If the user is determined to make things difficult for the staff, there's
really no difference between giving him the local admin password and adding
him to the administrators group: if he's in the administrators group he
can change the local admin password, and if he has the local admin password
he can add himself to the the administrators group.
> If the user does not know what he/she is doing,
> which would lead any administrator to question their having administrative
> rights, then it would be best to grant permission to a user to perform the
> few functions they need to perform (adding printers, installing programs,
> etc) instead of giving them full administrative rights.
This is a good point, especially if the user's needs are well-defined -
otherwise you may have to go back constantly giving him additional rights.
A fourth option is to create an additional local account that's a member
of the administrators group. This way the password of the "administrator"
account is still the lab standard (or whatever), and the user must logout
and login to his personal admin account to do administrative (and
possibly dangerous) things. This gives you even more auditing capability.
