The Group Policy extension snap-ins constitute the main nodes in the Group Policy snap-in namespace; they are all loaded by default when the Group Policy snap-in is started. You can modify which extensions are loaded by creating custom consoles for Group Policy, and by specifying policy settings for MMC. For more information, see Creating Custom Group Policy Snap-in Consoles and Specifying Group Policy to Control the Behavior of MMC and Snap-ins in this document.
This section presents additional information on the following topics:
Administrative Templates
Security Settings
Software Installation
Scripts (Startup/Shutdown and Logon/Logoff)
Folder Redirection
Internet Explorer Maintenance
Remote Installation Services
Administrative Templates
In Windows NT 4.0, the System Policy Editor uses files called administrative templates (.adm files) to determine which registry settings can be modified. These files define which settings are displayed by the System Policy Editor user interface.
In Windows 2000, the Administrative Templates node of the Group Policy snap-in uses administrative template (.adm) files to specify the registry settings that can be modified through the Group Policy snap-in user interface.
The Administrative Templates node includes all registry-based Group Policy information. This includes Group Policy for the Windows 2000 operating system and its components and for applications. Policy settings pertaining to a user who logs on to a given workstation or server are written to the User portion of the registry database under HKEY_CURRENT_USER (HKCU). Computer-specific settings are written to the Local Machine portion of the registry under HKEY_LOCAL_MACHINE (HKLM).
The .Adm File
.Adm files are Unicode files which consist of a hierarchy of categories and subcategories that define how the options are displayed through the Group Policy snap-in UI. They also indicate the registry locations where changes should be made if a particular selection is made, specify any options or restrictions (in values) that are associated with the selection, and in some cases, indicate a default value to use if a selection is activated. Windows 2000 includes three .adm files, System.adm, Inetres.adm, and Conf.adm, which contain all the settings initially displayed in the Administrative Templates node. It also includes .adm files for use with the Windows NT 4.0 System Policy Editor tool, as noted in the following table.
.Adm file
|
Use
|
Description
|
System.adm
|
Windows 2000
|
Loaded by default.
|
Inetres.adm
|
Windows 2000
|
Loaded by default.
|
Conf.adm
|
Windows 2000
|
Loaded by default.
|
Winnt.adm
|
Windows NT 4.0
|
Use with System Policy Editor, Poledit.exe.
|
Common.adm
|
Windows NT 4.0, Window 95, and Windows 98
|
Use with System Policy Editor, Poledit.exe.
|
Windows.adm
|
Window 95 and Windows 98
|
Use with System Policy Editor, Poledit.exe.
| Distinguishing True Policies from Group Policy Preferences
In Windows 2000, all shipping policies set registry keys and values in either the \Software\Policies (the preferred location for all new policies) or \Software\Microsoft\Windows\CurrentVersion\Policies trees, in either HKCU or HKLM.
Policy settings that are stored in these specific locations of the registry are known as true policies. Storing settings here has the following advantages:
These trees are secure and cannot be modified by a non-administrator.
When Group Policy changes, for any reason, these trees are cleaned, and the new policies are then rewritten.
This prevents the behavior that was often present in Windows NT 4.0, whereby System Policies resulted in persistent settings in the user and computer registry. The policy remained in effect until the value was reversed, either by a counteracting policy or by editing the registry. These settings are stored outside the approved registry locations above and are known as preferences.
All the policy settings in the System.adm, Inetres.adm, and Conf.adm files use registry settings in the Policies trees of the registry. This means that they will not cause persistent settings in the registry when the GPO that applies them is no longer in effect.
By default, only true policies are displayed in the Group Policy snap-in. The following .adm files are loaded:
System.adm: contains operating system settings
Inetres.adm: contains Internet Explorer restrictions
Conf.adm: contains NetMeeting settings
Note: Because of the persistent nature of non-policy settings, they should be avoided.
It is still possible for administrators to add an additional .adm file that sets registry values outside of the Windows 2000 Group Policy trees mentioned previously. These settings might be more appropriately referred to as preferences because the user, application, or other parts of the system can also change them. In this case, the administrator is ensuring that this registry key or value is set in a particular way. Although it is possible to add any .adm file to the namespace, if you use an .adm file from a previous version of Windows, the registry keys are unlikely to have an effect on Windows 2000, or they actually set preference settings and mark the registry with these settings; that is, the registry settings persist.
Viewing Group Policy Preferences
There is a user preference that allows preferences to be displayed in the Group Policy user interface; it is called Show Policies Only and is located in the View menu of the MMC. The ability to clear the checkbox for this setting and allow non-policy settings to be displayed may be prevented by using a policy setting located in User Configuration\Administrative Templates\System\Group Policy. If the preference (or policy) is not set to Show Policies Only, the icon for those settings is displayed in red. True policies are displayed in blue. Note that it is not possible for the selected state for this policy to persist; that is, there is no preference for this policy setting.
A Group Policy called Enforce Show Policies Only is available in User Configuration\Administrative Templates, under the System\Group Policy nodes. If you set this policy to Enabled, the Show policies only command is turned on and administrators cannot turn it off; in addition, the Group Policy snap-in displays only true policies. If you set this policy to Disabled or Not configured, the Show policies only command is turned on by default; however, you can view preferences by turning off the Show policies only command. To view preferences, you must turn off the Show policies only command, which you access by selecting the Administrative Templates node (under either the User Configuration or the Computer Configuration node), and then clicking the View menu on the Group Policy console and clearing the Show policies only check box.
In Group Policy, preferences are indicated by a red icon to distinguish them from true policies, which are indicated by a blue icon.
Use of non-policies within the Group Policy infrastructure is strongly discouraged because of the persistent registry settings behavior mentioned previously. To set registry policies on Windows NT 4.0, Windows 95, and Windows 98 clients, use the Windows NT 4.0 System Policy Editor tool, Poledit.exe.
Security Settings
You can define a security configuration within a Group Policy Object. A security configuration consists of settings applied to one or more security areas supported on Windows 2000 Professional or Windows 2000 Server. The specified security configuration is then applied to computers as part of the Group Policy application.
The Security Settings extension of the Group Policy snap-in complements existing system security tools such as the Security tab on the Properties page (of an object, file, folder, and so on), and Local Users and Groups in Computer Management. You can continue to use existing tools to change specific settings, whenever necessary.
The security areas that can be configured for computers include the following:
Account Policies. These are computer security settings for password policy, lockout policy, and Kerberos policy in Windows 2000 domains.
Local Policies. These include security settings for audit policy, user rights assignment, and security options. Local policy allows you to configure who has local or network access to the computer and whether or how local events are audited.
Event Log. This controls security settings for the Application, Security, and System event logs. You can access these logs using the Event Viewer.
Restricted Groups. Allows you to control who should and should not belong to a restricted group, as well as which groups a restricted group should belong to. This allows administrators to enforce security policies regarding sensitive groups, such as Enterprise Administrators or Payroll. For example, it may be decided that only Joe and Mary should be members of the Enterprise Administrators group. Restricted groups can be used to enforce that policy. If a third user is added to the group (for example, to accomplish some task in an emergency situation), the next time policy is enforced, that third user is automatically removed from the Enterprise Administrators group.
System Services. These control startup mode and security options (security descriptors) for system services such as network services, file and print services, telephone and fax services, Internet and intranet services, and so on.
Registry. This is used to configure security settings for registry keys including access control, audit, and ownership. When you apply security on registry keys, the Security Settings extension follows the same inheritance model as that used for all tree-structured hierarchies in Windows 2000 (such as the Active Directory and NTFS). Microsoft recommends that you use the inheritance capabilities to specify security only at top-level objects, and redefine security only for those child objects that require it. This approach greatly simplifies your security structure and reduces the administrative overhead that results from a needlessly complex access-control structure.
File System. This is used to configure security settings for file-system objects, including access control, audit, and ownership.
Public Key Policies. You use these settings to:
Specify that computers automatically submit a certificate request to an enterprise certification authority and install the issued certificate.
Create and distribute a certificate trust list.
Establish common trusted root certification authorities.
Add encrypted data recovery agents and change the encrypted data recovery policy settings.
IP Security Policies on Active Directory. IP Security (IPSec) policy can be applied to the GPO of an Active Directory object. This propagates that IPSec policy to any computer accounts affected by that Group Policy object.
For more information on security settings and IPSec issues, refer to the Windows 2000 Server Online Help at http://www.microsoft.com/windows2000/support/onlinedocs/default.asp.Windows 2000 Default Security Templates
Windows 2000 includes three default security templates called Basic. These new default security settings are applied to Windows 2000 systems that have been installed onto an NTFS partition. When Windows 2000 is installed onto a FAT file system, security cannot be applied.
The following Basic security templates are used:
Basicwk.inf for workstations
Basicsv.inf for servers
Basicdc.inf for domain controllers
The Basic security templates specify default Windows 2000 security settings for all security areas, with the exception of User Rights and Groups. These templates can be applied to Windows 2000 systems using the Security Configuration and Analysis MMC snap-in or by using the Secedit.exe command-line tool.
Incremental Security Templates
Windows 2000 includes several incremental security templates. By default, these templates are stored in %systemroot%\Security\Templates. These predefined templates can be customized using the Security Templates MMC snap-in and can be imported into the Security Settings extension of the Group Policy snap-in.
These security templates were constructed based on the assumption that they would be applied to Windows 2000 computers that are configured with the new Windows 2000 default security settings. In other words, these templates incrementally modify the default security settings. They do not include the default security settings plus the modifications.
The following table lists the incremental security templates included in Windows 2000.
Security Configuration
|
Computer
|
Templates
|
Description
|
Compatible
|
Workstation, and server
|
Compatws.inf
|
For customers who do not want their users to run as Power Users (by default all users are Power Users on Windows 2000 professional), the Compatible configuration opens up the default permissions for the Users group so that legacy applications are more likely to run. Office 97 should run successfully when users are logged on as a User to a Windows 2000 computer that has had the Compatible security template applied over the default settings. Note that this is not considered a secure environment.
|
Secure
|
Workstation, server, and domain controller
|
Securews.inf and Securedc.inf
|
The Secure configuration provides increased security for areas of the operating system that are not covered by permissions. This 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 configurations because the secure configurations assume that default Windows 2000 security settings are in effect.
|
Highly Secure
|
Workstation, server, and domain controller
|
Hisecws.inf and Hisecdc.inf
|
The Highly Secure configuration is provided for Windows 2000 computers that operate in native (or pure) Windows 2000 environments only. In this configuration, it is required that all network communications be digitally signed and encrypted at a level that can only be provided by Windows 2000. Thus, a Windows 2000 highly secure computer cannot communicate with a Windows 95, Windows 98, or Windows NT client.
| Security Levels
The following table describes the relative levels of security that can be associated with the operating system, based on the templates that have been applied and the type of user accessing the system. No inference should be made with respect to the security of applications running in this environment. The items are listed in the table in order of increasing security level.
Templates applied
|
User level
|
Default
|
Power User
|
Default + Compatible
|
User
|
Default
|
User
|
Default + Secure
|
User
|
Default + Secure + Highly Secure
|
User
|
Thus, logging in as a Power User to a Windows 2000 system that has been installed onto an NTFS system can be less secure than logging into that same system as a User.
For more information on security settings, see the "Step-by-Step Guide to Configuring Enterprise Security Policies" at http://www.microsoft.com/windows2000/library/planning/security/entsecsteps.asp, and the "Step-by-Step Guide to Internet Protocol Security (IPSec)" at http://www.microsoft.com/windows2000/lirary.planning/security/ipsecsteps.asp.For information on the default security settings contained in the Default Domain Policy GPO and Default Domain Controller Policy GPO, see Appendix A: Security Settings and User Rights later in this paper.
Software Installation
You 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 computers.
You assign applications to groups of users so that all users who require the applications automatically have the application on their desktops—without requiring the administrator or technical personnel to set up the application on each desktop. When you assign an application to a group of users, you are actually advertising the application on all the users’ desktops. The next time a user logs on to Microsoft Windows 2000, the application is advertised. This means that 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 on the user’s computer, the application is installed the first time the user activates the application.
When the user selects the application from the Start menu the first time, it sets up automatically, and then opens.
You can also publish applications to groups of users, making the application available for users to install should 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. Published applications store their advertisement information in the Active Directory.
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. Alternatively, if the administrator has configured this feature, users can open a document file associated with a published application (for example, an .xls file to install Microsoft Excel).
For more information, see the "Software Installation and Maintenance" white paper at http://www.microsoft.com/windows2000/library/operations/management/siamwp.asp and the Step-by-Step Guide to Software Installation and Maintenance at http://www.microsoft.com/windows2000/library/planning/management/swinstall.asp.
|
