You can run an inf that wil relax the security settings on the applications.
The compatws.inf is discussed below. It can be used when legacy apps don't
work well with the restricted security settings of Windows 2000.
Ensuring Application Compatibility
If you use applications designed to run on Microsoft Windows NT® version
4.0, Microsoft Windows 95, or Microsoft Windows 98, you might need to modify
some security settings to allow these applications to run properly on
Windows 2000-based computers that use these scenarios. This is because the
security configurations and Group Policy restrictions in Windows 2000 are
much stricter than in previous versions of Microsoft Windows.
Note Applications that comply with the Application Specification for Windows
2000 (
http://msdn.microsoft.com/certification/appspec.asp ) should be able
to run properly in these scenarios without any modifications to the
scenarios.
You need to test the applications you use before deploying them to users.
Examples of areas where you might need to modify security settings are as
follows:
a.. Allow users Write/Create access in application directories because the
application saves data or user configuration information in its own
directories.
b.. Allow Create and selective Write access to files in the %Systemroot%
directory because the application might save user configuration information
to this directory.
c.. Allow Write access to parts of the computer registry hive
(HKEY_LOCAL_MACHINE) because the application saves user configuration
information to the computer registry.
Caution Avoid weakening access controls more than necessary, particularly in
environments that require higher security. Start with the most restrictive
setting and selectively remove restrictions file-by-file until the
application works properly. Avoid giving Full Control permissions to
users-especially on directories. Change permission should be the maximum
permission needed. Full Control allows the user to change the permissions on
the object, potentially removing access for other valid users or granting
access to a user who should not have access. For example, if the user only
needs to create, write to, and delete data files in a directory, apply the
permissions as they appear in Table 4.
Table 4 Set Permissions to Protect Files Group
Permission
Users
Create Files
Creator-Owner
Change
Applying the preceding permissions prevents users from modifying or deleting
files that they did not create.
What if I don't want end users to be Power Users when running legacy
applications?
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:
a.. Create local users and groups.
b.. Modify users and groups that they have created.
c.. Create and delete non-admin file shares.
d.. 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.
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.
