I thought this article might be of interest to some people in this group...
-------------------------------------------
==== 1. Commentary: Log Out of the Administrator Account--and Still Work
==== by Mark Minasi, senior contributing editor, help@minasi.com
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_MACHINE\SOFTWARE and one in HKEY_CURRENT_USER\Software. 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_MACHINE\SOFTWARE key, but they
can write to their individual HKEY_CURRENT_USER\Software 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_MACHINE\SOFTWARE 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
subtree\Software\vendor-name. Thus, a look in the registry would
probably yield a key named HKEY_LOCAL_MACHINE\SOFTWARE\AutoDesk 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://list.windowsitpro.com/t?ctl=660D:398C0 )
You can also download Microsoft's Windows Application Compatibility
Toolkit 3.0
( http://list.windowsitpro.com/t?ctl=65E1:398C0 ),
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.
---
Subscribe to Windows IT Pro:
http://list.windowsitpro.com/t?ctl=660A:398C0
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")