Security Configurations

Security configurations provide preconfigured sets of security settings that you can apply. You can configure them to Compatible, Secure, or High Secure Settings.

Compatible

The compatible template is provided in case you do not want to risk making end users into Power Users so that they can run older applications. This works on workstations and servers, and the template is called Compatws.inf.

Using this template, normal users — that is non-administrator and non-Power Users — cannot run most older applications on Windows 2000. This is because the default permissions granted to normal users are secure and most applications need to be rewritten to function properly in this environment. Applications that are Certified For Windows 2000 can be run successfully by a normal user. The Compatible configuration liberalizes the default permissions for the Users group so that older applications are more likely to run. Microsoft® Office 97 should run successfully when users are logged on as a User to a Windows 2000–based computer that has had the Compatible security template applied over the default settings. This is not considered a secure environment.

Secure

The Secure configuration provides increased security for areas of the operating system that are not secured by the default access control permissions. This works on workstations, servers, and domain controllers, and the templates are called Securews.inf and Securedc.inf

This configuration includes increased security settings for Account Policy, Auditing, and some well-known security-relevant registry keys. Access control lists are not modified by the secure configuration because this configuration assumes that default Windows 2000 security settings are in effect, and that users are members of the Users group. The Secure configuration removes all members of the Power Users group to enforce this assumption.

High Secure

The High Secure configuration provides increased security over the secure configuration. This works on workstations, servers, and domain controllers, and the templates are called Hisecws.inf and Hisecdc.inf.

The High Secure configuration requires that all network communications be digitally signed and encrypted. Because of these requirements, Windows 2000–based computers configured with the High Secure template might not be able to communicate with previous version clients such as Microsoft® Windows 98®–based (or earlier) computers that do not support the same network communication protections. The High Secure configuration also grants Power Users the same access to file system and registry keys as normal users. This allows users running Certified For Windows 2000 applications to offer inherent Power User capabilities such as the ability to create shares and change the system time without giving those same Power Users the lax permissions necessary to run noncertified applications. The High Secure template, when applied to servers, removes the Terminal Server user from all file system and registry ACLs, thus ensuring that users logging on to Terminal Server environments are also subject to the same secure access control policy as normal users.

Windows 2000 Default Security Templates

As noted earlier, the security templates described above (Compatible, Secure, and High Secure) incrementally modify the default Windows 2000 security settings that exist when Windows 2000 is clean-installed onto an NTFS partition. If you would like to apply these defaults to upgraded computers, or to clean-installed computers that have been subsequently modified, the following templates can be used:

• Basicwk.inf — applies default settings for Windows 2000 Professional–based computers for all areas except User Rights and Group Membership.

• Basicsv.inf — applies default settings for Windows 2000 Server–based computers for all areas except User Rights and Group Membership.

• Basicdc.inf — applies default settings for Windows 2000 Domain Controllers for all areas except User Rights and Group Membership. User Rights and Group Memberships are not modified by the basic templates because these templates are most often used for undoing file system or registry ACL changes, or to apply the default Windows 2000 ACLs to computers which have been upgraded from Windows NT 4.0. In these cases, customers usually want to maintain the existing User Rights and Group Memberships.

Software Installation

You can use the Software Installation snap-in to centrally manage software distribution in your organization. You can assign and publish software for groups of users, and you can assign software for groups of computers.

You assign applications to groups of users so that all users who require the applications have them on their desktops, without you or other technical personnel having to install the application on each desktop. When you assign an application to a group of users, you can be sure it is always available to them. When users log on to Windows 2000, the application shortcut appears on the Start menu, and the registry is updated with information about the application, including the location of the application package and the location of the source files for the installation. With this "advertisement" information about users' computers, the application is installed the first time users activate the application. When users select the application from the Start menu the first time, it installs and then opens. Users can remove assigned applications using Add/Remove Programs in Control Panel, but only for the duration of a logon session. The next time they start their computer, the application icon reappears.

You can also publish applications to groups of users, making the application available for users to install if they choose to do so. When you publish an application, no shortcuts to the application appear on users' desktops, and no local registry entries are made. That is, the application has no presence on the user's desktop. Information needed to published applications is stored in the Group Policy object.

To install a published application, users can use the Add/Remove Programs in Control Panel, which includes a list of all published applications that are available for them to use. Or, users can open a document file associated with a published application (for example, an .xls file to install Microsoft® Excel).

Scripts

Previously, the only native scripting language supported by the Windows operating system was the MS-DOS command language. In Windows 2000 this is expanded to include the Microsoft® ActiveX® scripting architecture. Windows 2000 includes Windows Script Host (WSH), a language-independent scripting host for 32-bit Windows platforms. WSH has low memory requirements and serves as a controller of ActiveX scripting engines. With WSH, you can run scripts directly in Windows 2000 by double-clicking a script file, or by typing the name of a script file at the command prompt. You can use any WSH scripting tool including VBScript programming system and Microsoft® JScript® programming system to create scripts. Independent software vendors provide WSH support for other popular scripting languages. You can use Windows Script Host to run .vbs and .js scripts directly on the Windows desktop or command console, without the need to embed the scripts in an HTML document. MS-DOS-type batch files (with .bat and .cmd extensions) also function using Windows 2000.

The Scripts node located under Computer Configuration allows you to specify startup and shutdown scripts, and to specify logon and logoff scripts.

In Windows 2000 the following five script types are supported:

• Legacy Logon scripts

• Group Policy Logon scripts

• Group Policy Logoff scripts

• Group Policy Startup scripts

• Group Policy Shutdown scripts

Table 22.1 shows some Group Policy settings that control how scripts are run.

Table   22.1 Group Policy Settings That Control Scripts

Scripts can cause the system to appear hung if an errant script (one that prompts the user for input) runs hidden. This occurs because the default wait time is 600 seconds. You can change this default using Group Policy. The setting is in the following location: Computer Configuration\Administrative Templates\System\Logon\Maximum wait time for Group Policy scripts.

If you run scripts in a minimized window, you can stop the scripts processing by normalizing the window.

You can also use the Disable the Command Prompt setting found under User Configuration\Administrative Templates\System. This prevents batch files from running (files with .cmd and .bat extensions). This optional setting should not be used for Terminal Services clients, because it prevents the Application Compatibility scripts from running. See Windows Explain text for details.

Legacy logon scripts are those scripts specified in the User object. You need to carefully consider these scripts if you have a mixed environment that includes Windows NT 4.0, Microsoft® Windows® 95, Windows 98, and Windows 2000 clients. The Windows 2000 and the Windows 98 clients properly run .vbs and .js scripts. However, to run .vbs and .js scripts on Windows NT 4.0 and Windows 95 clients, you need to embed the scripts in batch (.bat) files. The scripts continue to run in a normal window. Alternatively, you can install Windows Script Host to run unembedded scripts on Windows NT 4.0 and Windows 95 clients. The names of scripts and their command lines are stored in a .pol file in the form of registry keys and values.

For more information about Windows Script Host, see the Windows Script Technologies link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

Folder Redirection

You use the Folder Redirection extension to redirect any of the following special folders in a user profile to an alternate location (such as a network share):

• Application Data

• Desktop

• My Documents

  • My Pictures

• Start Menu

You can redirect a user's My Documents folder to \\< server name >\ < share name >\%username% and provide them with the following advantages:

• You can ensure that a user's documents are available when they roam from one computer to another, with or without roaming user profiles.

• When using roaming user profiles, you can reduce the time it takes to log on to and log off from the network. In Windows NT 4.0, the My Documents folder is part of the Roaming User Profile. This means that the My Documents folder and its contents are copied back and forth between the client computer and the server when the user logs on and logs off. By moving the My Documents folder out of the user profile, you can expedite user logon and logoff.

• You can store user data on the network rather than on the local computer, which allows you to manage and protect it.

• You can make a user's network-based folders available to them when they are disconnected from the corporate network by using Offline Folder technologies.

Analogous advantages apply to any redirected folder, not to only the My Documents folder. Redirecting to a Dfs share provides a degree of safety in case of server failure. For more information about using offline folders, see "Remote OS Installation" in this book.