Windows Tip Sheet

Seriously, Least Access

Run legacy apps without hitting the security barrier.

I recently gave a talk to a bunch of network admins who work for a BrainCore.Net client. We were talking about security and the Principle of Least Access—you know, the idea of logging onto your computer with an ordinary user account, and never logging on with an administrator account, because if you happen to (for example) get hit by a virus or something, that ordinary user account will offer less power for the virus to take advantage of. They said they'd love to do that. In fact, they'd tried once, using Windows XP's RUNAS command to execute administrative utilities under a separate administrator account. But it turned out many of their users' apps—legacy apps, that is—required administrative privileges, so they had to abandon the idea. No way!

The Legacy Solution
One reason a legacy app might "need" administrative rights is to get free access to the HKEY_LOCAL_MACHINE portion of the Windows registry, a portion which ordinary users have read-only rights to. It's a horrible programming practice on the part of the application developer, but that's why we call these things legacy apps, right? Easy fix, though: Simply apply the "compatws" security template to computers that run the app. This template, included with Windows, dumbs down security on HKEY_LOCAL_MACHINE so that users have more access. You will be opening the door to greater security threats, since many viruses try to modify HKEY_LOCAL_MACHINE if they can get to it, but you won't be as wide-open as you would if all your users were administrators.

And RUNAS isn't just for using administrative applications like AD Users & Computers! It can also be a solution for those legacy apps. Here's how: Remove all Desktop and Start menu shortcuts to the app and replace them with shortcuts that launch the application by using RUNAS. In the shortcut's command-line, simply specify RUNAS, along with a user account that has the needed privileges. Users will be prompted for a password when the application runs, but that's surely a better thing than leaving your entire network, or the user's computer, open to bigger threats.

What user account should RUNAS utilize? That depends. If the legacy app in question only accesses local system resources, then have RUNAS use an alternate local user account that's a member of the local Administrators group (or Power Users, or whatever you need to get the app to run). That local account won't have domain-wide privileges, so any damage done by the legacy app (or by something the legacy app launches) will be restricted to the local machine. Worst-case would be to use a domain user account that's a member of the local Administrators group, which is what you'd need to do if the legacy app needs network access. That domain account won't usually need to be a Domain Admin, though, so the damage it can inflict on the network should still be limited.

Micro Tip Sheet

Ever try to consolidate Security event log information from a hundred servers? Don't—it's a painful process without tools. Watch the Windows Server 2003 Web site for an upcoming feature pack named MACS, the Microsoft Audit Collection Service, which will do the grunt work for you.

Still getting annoying pop-up ads in Internet Explorer? IE is the last major browser to include integrated pop-up blocking; it'll be included in an upcoming service pack. In the meantime, try the free Google toolbar (http://toolbar.google.com), which now blocks popups in IE.

More Resources
Read about the RUNAS command on Microsoft's Web site: http://www.microsoft.com/resources/documentation/WindowsServ/2003/
enterprise/proddocs/en-us/Default.asp?url=/resources/documentation/
WindowsServ/2003/enterprise/proddocs/en-us/
windows_security_runas_shortcut.asp

Read about the Windows service that makes RUNAS possible: http://www.microsoft.com/windows2000/en/server/help/default.asp?
url=/windows2000/en/server/help/sys_srv_secondary_logon.htm

About the Author

With more than fifteen years of IT experience, Don Jones is one of the world’s leading experts on the Microsoft business technology platform. He’s the author of more than 35 books, including Windows PowerShell: TFM, Windows Administrator’s Scripting Toolkit, VBScript WMI and ADSI Unleashed, PHP-Nuke Garage, Special Edition Using Commerce Server 2002, Definitive Guide to SQL Server Performance Optimization, and many more. Don is a top-rated and in-demand speaker and serves on the advisory board for TechMentor. He is an accomplished IT journalist with features and monthly columns in Microsoft TechNet Magazine, Redmond Magazine, and on Web sites such as TechTarget and MCPMag.com. Don is also a multiple-year recipient of Microsoft’s prestigious Most Valuable Professional (MVP) Award, and is the Editor-in-Chief for Realtime Publishers.

comments powered by Disqus

Reader Comments:

Thu, May 13, 2004 daved1948 Baltimore

This is something MS should have fixed years ago, and you're discussing it as if it's normal that IT staff should have to manage it instead. You have the OS developer full of programmers, many of whom were bred on Unix, and they can't even self-discipline themselves to keep their own wistle clean. Legacy shmegacy. AutoCAD 2005, QuickBooks 2004, Sumantec, CA and even dozens of MS' own apps all require unfettered access to areas of the registry which they have absolutely no business messing with. It's about time MS provided some other levels of security, and locked users and their apps out of the engine room!

Tue, May 4, 2004 Robert L Anonymous

This I found out before I read your article because if you read the help files in w2k it tells you not to run your machine on Administrator for the reason which you stated ; that is a virus has less power to destroy your drives. Goos stuff! Those that don't listen ...well you can always say "We Told You So!"

Mon, Apr 26, 2004 Bob Fuller Arizona

RUNAS has some obvious ability to reduce security exposures. I can certainly create and use them on my own workstation. Thanx for the additional comment by Andrey K. (savecred).

I haven't really found a way to deploy shortcuts with RUNAS utilization to remote systems. I don't want to supply the end user with an admin equivalent account password. Is there a 'safe' way to deploy RUNAS type shortcuts to end users via script or gpo?

Sun, Apr 25, 2004 mailpete405 Anonymous

Max from NY- You did not read the post immediately before yours. You can change permissions for files and directories via group policy, and if you do so, XP SP2 application is irrelevant. Any permissions modified by XP SP2 are reset via group policy.

Sun, Apr 25, 2004 Max NY

It is not only the registry, but file permissions too. By default the file permissions in XP set to read only on C: with rare exceptions for regular users. A lot of custom written apps tend to write all over C: and they crap out due to read only permissions. Now you have to relax that - usually done during image creation.
Now XP SP2 comes out - and you'll have to go through all that again. There is no easy way out.

Sat, Apr 24, 2004 mailpete405 Anonymous

Just change the security permissions for the specific registry keys, files, or directories required for the legacy application via group policy. No special user rights, runas, or other annoying workarounds.
Give only the minimum permissions required to make the application function.
This would be a ton easier if M$ provided a quick and easy means to audit failed access to registry keys without having to acquire and install 3rd party tools. Guess their "focus on security" is more marketing than substance.

Sat, Apr 24, 2004 Philip Colmer UK

Microsoft need to set the best example. Requiring administrator rights in order to read DRM-protected Reader books is not the right way to go about things. I've had this confirmed by MS and yet they won't or can't fix it.

Fri, Apr 23, 2004 mrobinson52 Florida

I worked briefly at a major company that had outsourced the IT functions to IBM. Instead of trying to set up a runas, they simply made even the temp help Power Users, since it seems that you cannot use Spellcheck in Word, or run Adobe Distiller without excessive permissions. I agree that the programmers need to learn to make the applications work under normal user privileges.

Fri, Apr 23, 2004 Anonymous Anonymous

Article is a start. Comments add a lot of good info. But the root of the problem is the application developers who need to get out of the Win9x (or DOS) mode of operation and realize "security is necessary". It troubles me that Windows application developers don't understand the operating system enough to set up the install process to set the security at the same time so that a "user" could run it. It is even more troubling that these "programmers" don't work for fly-by-night operations but supposedly security conscious companies like McAfee and Norton (won't do updates without being administrator). Someone wake these folks up!

Fri, Apr 23, 2004 Anonymous Anonymous

Good article. We were actually forced to begin this practice about six months ago. I've created shortcuts and selected the RUNAS different user in the properties. The only annoyance is that I have to type in the username and domain name each time I use the shortcut (Windows 2000.) Does anyone know how I can get around this, reghack maybe?

Fri, Apr 23, 2004 David T. Anonymous

First... great tip Andrey k. from New York... savecred is a good thing. A better way to follow the principle of least privilage is to identify the proper registry security permissions for the user account (or for a separate account in the case that creation of proper permissions presents too great of a security threat to run under the users account). As "KB" mentioned Regmon (sysinternals.com) is one tool to identify which keys are being accessed. Another method which is freqently overlooked, but highly effective, is to setup a test workstation and enable full auditing of file and registry access failures. After doing so, install the application and perform a function test. When errors occur because of insufficient rights, check the audit log for reported access rights failures. Document the problem and make a change to loosen rights for that item (file or registry) as granular as possible. Repeat this process until the application installs and works as expected. Then decide wethor to implement the changes in the production environement for existing user account or for a separate account...as determined by a sober risk analysis. The great thing with using the auditing system to identify these issues is that the generated logs usually indicate the type of access that was denied - providing an oportunity to allow least privilage assignment instead of just selecting "full control" as the permission for the selected user. Be aware that sometimes applications need more rights to install than they need to operate. It may be possible to reduce "full control" to read-only in many instances. - David T.

Fri, Apr 23, 2004 SysAdmin NJ

So far I didn't need to give any user admin access to the local machine to run legacy applications. I made the users group member of the power users local group and that worked perfect.

Fri, Apr 23, 2004 Anonymous Anonymous

Surely a far more controlled way would be to allow the user to write to the required part of the registry (which as KB says could be indentified by regmon). Thats I would want to do it as that still retains registry security and has least access for the user

Fri, Apr 23, 2004 KB Anonymous

Using tools like regmon from www.sysinternals.com you can track the exact keys users need write rights to in order to run the application. You can then have SMS or whatever deployment tool you use, give the users only that access.

Fri, Apr 23, 2004 John Cox Huntsvile, AL

I agree that we should apply security to the individual subkeys , but wouldn't it be nice if M$oft would log the specific access violation when an application fails to load due to security.

Fri, Apr 23, 2004 Anonymous Anonymous

Oops, don't understand software very well do we? Subkeys under HKEY_LOCAL_MACHINE are used to hold machine wide software settings (at least that's what MS told us to do until in .NET they went off the idea of applications using the registry). Correct solution is to set appropriate permissions on the registry subkeys!

Fri, Apr 23, 2004 Andrey k. New York

RUNAS on WinXP has a switch /savecred, which can be used to safe a password in a hash. Next time an application called from a runas command and this switch is used there is no prompt for a password. Works on shortcuts as well. When, at some point in time, the password of the account used to run the command changes, the user will be presented with the standard RUNAS prompt for the password. And it saves it again.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above
Close this Advertisement