Having talked to a lot of new network administrators, = and having been one at one time myself, I’ve seen a lot of pitfalls that = are easy to land in if you don’t know any better. This time around we’re going to look at one of the most common mistakes that sometimes even experienced network administrators make, misusing the administrator account or administrator level permissions.
One of the most common mistakes I’ve seen and he= ard about over and over, especially with NT administrators, is with respect to = the use of administrator accounts. The mistake is in using the administrator account or an account with administrator (local or domain) permissions to perform day-to-day tasks on a computer. Why is this a problem? Well, consider that many security exploits work by operating under= the context of the currently logged in user account. For example, someone sends= you an email infected with a Trojan virus, which you accidentally execute. The program will only be able to gain a level of access to your system (and network) equivalent to what the account it was launched under has access to= . If your user account is only a member of the local users group (assuming an NT-based workstation such as NT Workstation, Windows 2000 Professional, or Windows XP Professional … disregard if on a Win9x based workstation),= or a member of Domain Users, the trojan won’t be able to cause nearly as much damage as if it were run under an account that is a member of the local administrators group or Domain Admins group.
Even though Microsoft (and every other network operati= ng system vendor) recommends not using your administrator account except for w= hen you specifically need that level of permission to complete a task, many administrators don’t pay attention. The reason for ignoring this recommendation usually comes down to one of two things … ignoran= ce or laziness. We can’t help much with the latter other than to suggest that you strongly consider what is in the best interest of your network security, but here we’ll help overcome the former.
It has been standard practice in the Unix world for a = very long time to have a standard user account for your day-to-day operating of = the computer, and only using the root account (the Unix equivalent of Administrator) as needed. In fact, it is even made very easy because you ha= ve the command su (i.e. “superuser”) that you can invoke to instantly switch on the fly to the root account when you need to complete a certain task. For a long time Windows NT administrators had no such command, making it more inconvenient to go back and forth between a standard Domain = User account and a Domain Admin account. The process involved closing all progra= ms you were in and logging off, then logging in as an administrator in order t= o do what you needed, then logging off and logging back on with your user accoun= t. It’s little wonder that network administrators got frustrated with the process and started using their Domain Admin account for everything!
Fortunately, with Windows 2000 and later we have a new command, runas, that gives us the ability to perform tasks on the fl= y as an administrator without having to close everything and logoff first. If we issue the command runas /? From a command prompt, we get the followi= ng help text:
Microsoft Windows XP [=
Version
5.1.2600]
(C) Copyright 1985-2001
Microsoft Corp.
C:\WINNT>runas /?
RUNAS USAGE:
RUNAS [ [/noprofile
| /profile] [/env] [/netonly] ]
/user:<UserName> program
RUNAS [ [/noprofile
| /profile] [/env] [/netonly] ]
/smartcard [/user:<UserName>] progr=
am
/noprofile
specifies that the user's profile should not be loaded.
=
This causes the application to load more quickly, but
=
can cause some applications to malfunction.
/profile =
specifies that the user's profile should be loaded.
=
This is the default.
/env =
to use current environment instead of user's.
/netonly =
use
if the credentials specified are for remote
=
access only.
/savecred
to use credentials previously saved by the user.
=
This option is not available on Windows XP Home Edition
=
and will be ignored.
/smartcard use
if the credentials are to be supplied from a
=
smartcard.
/user =
<UserName> should be in form USER@DOMAIN or DOMAIN\USER
program<=
/span>
command line for EXE. =
See
below for examples
Examples:
> runas
/noprofile /user:mymachine\administrator cmd
> runas
/profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc"=
;
> runas /env
/user:user@domain.microsoft.com "notepad \"my file.txt\"&quo=
t;
NOTE: Enter user's password only when
prompted.
NOTE: USER@DOMAIN is not compatible with
/netonly.
NOTE: /profile is not compatible with
/netonly.
As you can see, we can now easily use a standard Domai= n User account for our day-to-day tasks such as email, word processing, etc., and = invoke the runas command to perform administrator tasks as necessary. This = is especially helpful when working on an NT-based workstation where administra= tor level access is required to install programs that modify the Registry. You = can use the runas command to run the setup program as an administrator without having to keep your user account a permanent member of the administrators group or without having to logoff and logon as a different u= ser.
Even with using the above, it is highly recommended th= at each administrator in a domain environment have their own separate Domain A= dmin user account. In a future article we will discuss audit policies as a part = of maintaining network security. Auditing allows you to see who is performing = what security related tasks and at what time. If you have multiple administrators sharing an administrator account, it will be impossible to identify who specifically is doing what when you view the security event log. That can be problematic if you have an administrator who is doing things they shouldn’t, or if you have an account that is compromised and can̵= 7;t figure out how/where it happened. Therefore, every administrator should have their own administrator account that they can invoke the runas comma= nd under, and a Domain User account that they normally login to the network wi= th.
It is easy to get in the habit of simply logging in as= a Domain Admin and doing all of your computing tasks under that context, but = it is a potential security problem waiting to happen. While it has been very inconvenient for NT administrators in the past to stop what they were doing= in order to switch user accounts, today there is little excuse since you can r= un commands under a different security context on the fly, without changing accounts. Network administrators need to be conscious of their own role in = the overall security of the network, and not create unnecessary risks that they wouldn’t let their users do. Be considerate of the security needs of = your company, and make sure you aren’t a potential liability.
Questions or Comments?
Will Willis can be reached at WWillis@Transcender.com