The Win9x series of home operating systems and the less restrictive NT 4.0 systems of the past didn’t apply or enforce strong user privilege structures, so most configurations allowed any user to run and possibly install almost any software s/he had without a problem. However, with Windows 2000 and XP, Microsoft has finally brought an extensive privilege structure to the Windows OS that defaults to be quite restrictive for all except the Administrator user account. This is great news for sysadmins and techs who are trying to restrict users from messing up their own systems, but it can also be hard to figure out what’s going on if you haven’t worked within the permissions rules before.

I’ve had over a decade of experiences designing and administering secure, restricted, locked-down images for Windows NT 4.0 and higher. Over this time I have developed and taught a number of helpful tricks for working with restricted permissions, in particular in the area of getting older, permissions-unaware programs to work properly within a locked-down environment.

The problem for the admin is that a vast majority of software does not follow the rules that Microsoft has been publishing for years about how Windows programs should store their information. The unruly programs create user data directories under their Program Files folder, try to overwrite system DLL’s in “C:\Windows\System32”, and modify HKEY_CLASSES_ROOT at startup-all causing a general mess. Here’s the “short list” of Microsoft’s recommendations:

  • After installation, the program cannot write to or store its configuration information to the “C:\Program Files” directory.
  • The program should not add DLL’s or configuration in the SystemRoot directory (e.g. C:\WINNT or C:\Windows).
  • The program should not store its volatile configuration information in the HKEY_LOCAL_MACHINE registry hive, because regular users should not have the privileges to write there.
  • In general, the program should only store user-specific configuration info in the user’s profile directory (e.g. “C:\Documents and Settings\USERNAME”) or the HKEY_CURRENT_USERS registry hive.
  • No program should try to overwrite a DLL or other file which was installed by the operating system, such as those in the C:\Windows\System32 folder.

These rules are similar to the basic tenets of a locked-down system:

  • Give the users the least permissions they need to do their job (i.e. run programs, configure the look-and-feel of their own environment, etc.).
  • Users cannot install software on the PC.
  • Users can only write files to certain directories on the computer, such as their own profile (“C:\Documents and Settings\USERNAME\…”).
  • You never ever give a local user “Administrator” rights.

Since so many software developers just assume that the user has full rights to the system, you will need to squeeze the programs a bit to work with the “no admin rights” rule. But trust me, it can be done. Some non-compliant programs may allow you to change where some configuration or user data is stored-thus easily solving the problem-but most will just blindly assume that the user can write to the disk or the registry where it wants. To make this program work for restricted users (that’s what I call “normal” users with non-admin rights), you’re going to need to find out what places the program needs to write to, and open up the permissions so that the users can run the program without errors.

By the way, there are several practices on how you want to open the permissions. One says that on the files/keys which need it, you give “change” rights to the BUILTIN\Users group, which covers just about everybody who logs in locally. Another tactic is used more for multi-user systems with limited license software; that is, one user of the computer may be allowed to run a certain program, but another local user should not be allowed to run it even on the same machine. Admins can easily control this kind of environment by creating domain groups specific to the limited-use programs, and then setting the software distribution and the local file and registry permissions to use those groups only. In this method, the Help Desk may simply add the user account to the domain group and the software may be installed and start working immediately (depending on the distribution method, of course).