Perhaps your situation is like ours, where our users use a lot of
scientific programs that aren't rewritten every time Microsoft wants to
renew the revenue stream...., ahhh- that is - add security features to
their latest Op Sys. Or perhaps your users don't care for the words, '
Sorry, your security settings prohibit running ActiveX controls on this
page' when they are just trying to use a tool to do a job. Well, I have
finally found a white paper explaining this whole thing and offering a
work-around. Granted, most of you probably already know this, but for
For a Word download [on the Default Access Control Settings in Windows
On pg1 you will find:
A significant portion of the Microsoft® Windows® 2000 operating system
security is defined by the default access permissions granted to three
groups: Administrators, Power Users, and Users.
In practice, members of the Users group will not be able to run most
legacy applications because most legacy applications were not designed
with operating system security in mind. Members of the Power Users group
should be able to run such applications.
In practice, administrative accounts must often be used to install and
run legacy Windows-based applications.
from page 2
Applications that comply with the Windows 2000 Application Specification
can successfully run in a normal Users context. [rossi note: many
scientific programs are not updated in a timely manner because the
authors are busy , well - doing science. However, even Visual Basic 6.0
controls are sometimes restricted by the Win 2K scenario.]
By default, non-administrative users that log onto clean-installed
Windows 2000 computers are members of the Users group, so an
administrator will need to add these users to the less secure Power
Users group in order to run non-certified legacy applications.
Non-administrative users that log onto a Windows 2000-based workstation
that was upgraded from Windows NT 4.0 will automatically be a member of
the Power Users group. Applications that meet the Windows 2000
Application Specification do not require Power User capabilities in
order to run successfully.
And later [pg13]:
What if I don't want end users to be Power Users when running legacy
Some system administrators may consider the Power Users group too
liberal because of the built-in permissions that members of the Power
Users group have:
. Create local users and groups.
. Modify users and groups that they have created.
. Create and delete non-admin file shares.
. Create, manage, delete and share local printers.
All other additional rights, such as Change System Time, or Stop and
Start non-autostarted services, can be reconfigured for the Power User
by modifying the appropriate user rights or configuring the appropriate ACL.
And finally how to do it[!]:
Since there is no way to disable the built-in permissions allotted to
Power Users, administrators who need to support non-certified legacy
applications must loosen up the permissions allotted to members of the
Users group to the point where their installed base of applications can
be successfully run. The Windows 2000 operating system includes a
security template for precisely this purpose. The template is named
compatws.inf and can be found in the %windir%\security\templates
directory. The template can be applied to a system using the Security
Configuration Toolset. For example, the secedit.exe command line
component of the Toolset can apply the template as follows:
secedit /configure /cfg compatws.inf /db compatws.sdb
This template loosens up security for Users in a matter consistent with
the requirements of most legacy applications.
secedit.exe is in the default path of c:\winnt\system32\. But I had to
give a full path for compatws.inf of
c:\winnt\security\templates\compatws.inf for this to work for me.