Group Policy
Group Policy |
|
Security configurations provide preconfigured sets of security settings that you can apply. You can configure them to Compatible, Secure, or High Secure Settings.
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.
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.
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.
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:
You can use the Software Installation
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).
Previously, the only native scripting language supported by the Windows operating system was the
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:
Table 22.1 shows some Group Policy settings that control how scripts are run.
Table 22.1 Group Policy Settings That Control Scripts
| Location | Group Policy settings |
|---|---|
| Computer Configuration/Administrative Templates/System/Logon/ | Run Logon Scripts Synchronously
Run Startup Scripts Asynchronously Run Shutdown Scripts Visible Run Startup Scripts Visible |
| User Configuration/Administrative Templates/System/Logon/Logoff | Run Logon Scripts Synchronously
Run Legacy Logon Scripts Hidden Run Logon Scripts Visible Run Logoff Scripts Visible |
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 http://windows.microsoft.com/windows2000/reskit/webresources.
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):
You can redirect a user's My Documents folder to \\<server name>\
<share name>\
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.