Log Out of the Administrator Account--and Still Work

In discussing root kits in my previous two columns, I mentioned that root kits and other malicious software (malware) are usually installed by accident, typically when someone is browsing the Web, sending email, or editing documents while logged on as an Administrator. I argued that one of the best things that we in the PC world can do to slow the spread of viruses is to spend our days logged in as users rather than as Administrators. I also stated that although spending the day logged on as an Administrator might make some tasks easier, the real reason we do so is habit: It's what we've always done.

Many of you wrote to disagree with me, claiming that running as a user isn't practical because users can't install or run a lot of software. Yes, running as a user will provide some really annoying moments, and a few situations will force the administrator logged on as a user to log off and log back on as an Administrator, but the problem isn't nearly as pervasive as many people think. So let's consider the two most common fixes to the administrator-running-as-user scenario--NTFS and registry permissions.

First, let me dispel a myth that I'm frequently asked about: "What right can I change to let a user install software or, inversely, to prevent a user from installing software?" Unfortunately, no such right exists as a single right per se. No simple Group Policy Object (GPO) setting gives or removes that right. In general, though, most application installation and operation problems boil down to permissions, whether registry or NTFS.

In Windows 2000, Microsoft tightened the default permissions on the winnt/windows directory, including the system32 folder. Nonadministrators or non-Power Users can read from system32 but not write to it. Because many applications install files to the system32 folder, many installation programs fail unless the installing person has Administrator privileges.

Ironically, most applications don't need to write files to the system32 folder--making them do so is just a bad habit that developers haven't shaken. Yes, at one time there was a good reason to dump things into system32 because of the way that the OS looks for .dll files, but that hasn't been a concern since Win2K came out. Of course, if the application happens to be malware that tries to replace some legitimate part of the OS--most of which lives in system32--with a Trojan, then installing that application would fail unless the installing person was running as an Administrator. This scenario is, of course, one reason why we shouldn't spend our days logged on as Administrators; users running under nonadministrator accounts can't accidentally rewrite ntoskrnl.exe.

How, then, do you install legitimate applications? Simple: Use Runas when installing them. No one that I know of has ever said that we should "never" do things as a local Administrator, just that we shouldn't perform every function indiscriminately as an Administrator. And, if worse comes to worst, an Administrator can always log off his or her user account and log back on with the Administrator account to accomplish that installation.

Registry permissions can also hinder application installation and operation. Most applications store information in the registry about how to operate. That means that the initial installation program needs to be able to create new keys and value entries in the registry. But the program also needs to store user-preference information in the registry; for example, if I enable or disable word wrap in Notepad, then Notepad must be able to store that information in the registry so that Notepad remembers the word-wrap setting the next time I start the program.

You solve the problem of giving the installation program the power to create registry keys and entries the same way that you solve the NTFS permissions problem: Run as an Administrator when installing a program. Or, if you're in an Active Directory (AD) environment, you can use a software-deployment GPO to deliver an application. In that case, the Windows Installer service does the heavy lifting and runs under the credentials of the System account, so NTFS and registry permissions don't present a problem.

But registry permissions can cause problems in day-to-day application use. That's because of a change that Win2K made to the registry's default permissions. The registry's two main subtrees are HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. The former is intended to contain settings relevant to the computer; the latter is intended to hold user-specific settings. Because more than one person might use a given desktop, Windows supports multiple HKEY_CURRENT_USER registry hives so that if Jane wants Notepad to remember to use word wrap and Joe doesn't like word wrap, then Windows can store Joe's preferences in Joes's HKEY_CURRENT_USER registry subtree and Jane's preferences in Jane's HKEY_CURRENT_USER subtree.

But not all application settings are user-specific. For example, Microsoft Word stores information about any installed add-ins. It doesn't really make sense to store the information about these add-ins in any given user's HKEY_CURRENT_USER subtree, nor could the application know at installation which users might use Word at some time in the future, so Word stores that information in HKEY_LOCAL_MACHINE. Therefore, it's very common to see applications with two keys--one in HKEY_LOCAL_MACHINESOFTWARE and one in HKEY_CURRENT_USERSoftware. The settings in HKEY_LOCAL_MACHINE are created at installation and rarely modified; the settings in HKEY_CURRENT_USER are the user preferences, which probably change with some regularity.

Users can't write to the HKEY_LOCAL_MACHINESOFTWARE key, but they can write to their individual HKEY_CURRENT_USERSoftware key. Therefore, if an application writes user preferences to the HKEY_CURRENT_USER subtree, then all's fine. But some developers don't seem to understand the difference between HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, probably because the Windows 9x registry lacks security and Windows NT 4.0 and earlier versions had loose security on the HKEY_LOCAL_MACHINESOFTWARE key. When those developers started doing 32-bit coding, they didn't need to learn the difference between HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. For example, Autodesk developers built the 32-bit version of AutoCAD back in the days when HKEY_LOCAL_MACHINE had weak registry permissions, so AutoCAD's developers stuck everything in HKEY_LOCAL_MACHINE. Users running Win2K soon learned that they had to be logged on as Administrators to run AutoCAD.

Running as an Administrator is one answer to this developer mistake, but it's not the only answer. Another approach is to determine which registry keys AutoCAD uses and relax permissions on those keys. You can use several methods to find the relevant keys. For example, software keys in HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER are structured as subtreeSoftwarevendor-name. Thus, a look in the registry would probably yield a key named HKEY_LOCAL_MACHINESOFTWAREAutoDesk or the like.

Another method for determining the correct registry key is to run Sysinternals' Regmon program, which tracks registry activity. By looking in the Regmon logs, you can tell where the system tried to write data, revealing the registry key in question. (And while I'm discussing Sysinternals, you might want to download its new RootkitRevealer tool, which pulls a few sneaky tricks to point out suspected root kits. You can download it at http://www.sysinternals.com )

You can also download Microsoft's Windows Application Compatibility Toolkit 3.0 ( http://www.microsoft.com/downloads/details.aspx?familyid=7fc46855-b8a4-46cd-a236-3159970fde94&displaylang=en ), which includes a bunch of fixes for incorrectly written programs as well as a neat tool called the Application Verifier. You run your troubled program inside the tool, and when the application blows up, you just examine the tool's logs to see what caused the problem and that will point to the registry problem in question. (But that's not all; Application Verifier can detect more than 200 sources of application incompatibility. And the price is right.)

After you determine the relevant registry key, add the write permission to that key for the Users group or, perhaps better, create a separate permission for your specific user account. (Right-click the key in question and select the Security option.) If you need to roll out a change in registry permissions to your entire enterprise, use a GPO.

NTFS and registry permissions aren't the only cause of user/administrator application compatibility problems, but they're a big one. A little detective work can smoke out permission problems, and a few minutes spent adjusting permissions can fix those problems.