[465] in winnt
Re: Admin privs restricted to workstation in domain
daemon@ATHENA.MIT.EDU (Bob Kaynor)
Tue Jan 4 13:02:03 2000
Message-Id: <3.0.5.32.20000104130149.01854a30@po12.mit.edu>
Date: Tue, 04 Jan 2000 13:01:49 -0500
To: Tom Fitzgerald <tfitz@mit.edu>, bcvernon@mit.edu
From: Bob Kaynor <bkaynor@MIT.EDU>
Cc: ntpartners@mit.edu
In-Reply-To: <199912131905.OAA28854@sligo.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Regarding this thread which ran a few weeks ago on the ntpartners list, I
thought you might be interested in the following note on Win 2000 from the
SANS NT Digest...
-RKK
-------------------------------
6 Tip of the month: Use Run As... under Windows 2000
Since Windows 2000 is on the way to manufacturing, we thought we would
give you a heads-up on what to expect. One way we will do that is to
give you some tips on how to use Windows 2000 to make your job easier.
Windows 2000 finally provides a built-in way to easily run programs that
require administrative privileges without having to be logged on as an
administrator. This allows us to stay logged on as a regular user and
still do most of our required administrative tasks. Under NT 4.0, we
had the su.exe command from the resource kit. However, it was kludgy at
best, and worked poorly, or not at all, with many programs requiring
user interfaces, such as control panels.
If you hold down the shift key while right-clicking on executables,
control panels, and MMC scripts (.msc files) you get an option to Run
As... That option lets you run the program in the context of a different
user. You can also use this to right-click on short-cuts in the start
menu or on the task bar. This is also very useful if you are
trouble-shooting a user's machine and need to quickly make some
administrative changes to it. No more logging off and then back on.
Oh, by the way, you do not need to use Run As... explicitly to install
software. The OS will recognize an installer program and ask if you
would like to run it as another user. And, of course Power Users can
now install software.
=======================================================================
The SANS NT Digest is provided at no cost to those people who attend
SANS and SANS Network Security conferences. Email <sans@sans.org> with
complete instructions and your SD number (from the headers) for subscribe,
unsubscribe, change address, add other digests, or any other comments.
-------------------------------
At 02:05 PM 12/13/1999 -0500, Tom Fitzgerald wrote:
>> 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.
>
>
>
>
