Unicode Explained
|
|
The System policies provide another instrument to help system administrators control user access to the network and manage desktop settings, including data sharing and configuring system settings. The system policy represents registry settings that are automatically loaded when the user logs on to the system. The main difference between system policies and user profiles is that the system policy is applicable to users, user groups, and individual computers. Administrators can specify, modify, and support registry settings for each of the components just listed. By combining system policies for individual users, specific computers from which the user logs on, and for user groups, to which the user may belong, the administrator can get complete control over the types of user environments and user rights and permissions. To define the system policy settings, the administrator simply creates system policy templates.
The System Policy Editor tool was first introduced in the Windows NT 4.0 operating system. It allowed administrators to specify configuration settings for users and computers, and store these settings in the Windows NT registry. Using this utility, administrators could manage user work environments and specify configuration settings for all Windows NT 4.0 computers (both Workstation and Server). Starting with Windows 2000, this tool was replaced by the Group Policy MMC snap-in, which extends the capabilities of the System Policy Editor (SPE) and provides many additional options for managing client computer configurations, including registry based policies, security settings, scripts, and folder redirection. Group policy settings specified by the administrator are stored in the Group Policy Object (GPO), which, in turn, is associated with one of the Active Directory objects (site, domain, or organizational unit).
Group Policy implemented in newer versions of Windows NT-based operating systems has many significant advantages over the Windows NT 4.0 system policy (not to mention Windows 95/98). These advantages include:
-
The possibility of associating with Active Directory objects (sites, domains, or organizational units). The policy associated with the Active Directory container influences all other computers and all the users within that container (site, domain, or organizational unit).
-
Extended configuration capabilities. Both users and computers may be joined into groups.
-
Improved security in comparison to Windows NT 4.0.
-
Windows NT 4.0 policies were stored in the user profiles (this was sometimes called "tattooing the registry"). The specified registry setting using the System Policy Editor retained its value until it was changed by the administrator for the given policy, or manually changed by the user who edited the registry directly. This situation represented a problem (for example, when you decided to change group membership). This problem has been solved with Windows 2000, because registry settings specified by the group policy are written to the protected registry keys (\Software\Policies and \Software\Microsoft\Windows\CurrentVersion\Policies). When the group policy object (GPO) is no longer applicable, these settings are cleared.
Administrative Templates
The System Policy Editor utility included with Windows NT 4.0 Server uses administrative templates (ADM files). These templates allow you to define which registry settings are available for editing using the System Policy Editor.
Windows 2000 ADM files also specify registry settings that can be modified using the UI provided by the MMC Group Policy snap-in. The policy settings related to the user who logs on are written to the registry under the HKEY_CURRENT_USER root key (HKCU). The policy settings that relate to the software installed on the computer, and to the computer itself are written to the registry under the HKEY_LOCAL_MACHINE root key (HKLM).
ADM files are text files containing the hierarchy of categories and subcategories. These categories and subcategories define fully qualified registry settings that can be modified using the Group Policy user interface. The term "fully qualified registry setting" means that these settings also specify registry paths to the settings that will be modified using the Group Policy snap-in when you select the appropriate option.
Security Settings
The Group Policy MMC snap-in allows you to specify the security configuration applicable to one or more security areas. The security configuration specified using Group Policy is then applied to all computers within the Active Directory container.
Group Policy, which allows administrators to specify security settings, extends the existing operating system functionality. For example, the following capabilities are provided:
-
Account Policies. These are security settings related to passwords, the account lockout policy, and Kerberos-related policy (within Windows 2000 domains).
-
Local Policies. This is a group of settings that specify the auditing policy, user permissions, and other security settings. The Local policies allow administrators to configure access to the computer both locally and through the network, and specify the events that should be audited.
-
Event Log. These are security settings that control the security of the system event logs (Application, Security, and System), accessed using Event Viewer.
-
Restricted Groups. These settings allow you to specify the users who belong to restricted groups. Thus, the administrator can enforce the security policy in relation to groups like Enterprise Administrators, for example. If another user is added to this restricted group (for example, when there's an emergency and it's necessary to perform an urgent job), the user will automatically be deleted from this group when the group policy comes into force next time.
-
System Services. These options manage the starting mode and security handles for the system and network services.
-
Registry. Used for configuring the security settings for registry keys, including access control, auditing, and owner rights. Security settings for the registry keys are specified according to the same inheritance modes that are used in all Windows 2000 hierarchical structures. Microsoft officially recommends using access rights inheritance when defining security settings for top-level objects, and that users redefine security settings for child objects only when necessary.
-
File System. Used for configuring security settings related to file system objects, including ACLS, auditing, and owner rights.
Incremental Security Templates
Windows 2000, Windows XP, and Windows Server 2003 include incremental security templates. By default, these templates are stored in the %SystemRoot%\Security\Templates folder. These predefined templates may be further customized using the Security Templates MMC snap-in, and then imported into the Security Settings extension of the MMC Group Policy snap-in.
Incremental security templates have been developed for step-by-step modifications of the standard security settings.
| Note | Incremental security templates may be applied only if you've installed a new copy of the operating system, and only when you've installed it on the NTFS partition. If you've installed the OS on the NTFS partition as an upgrade of Windows NT 4.0 or an even earlier Windows NT version, use the standard security template (Basic). The Basic security template is used to configure the system according to the standard security requirements applied by default. Windows 2000/XP and Windows Server 2003 systems installed on FAT partitions can't be protected. |
Incremental security templates are listed in Table 10.4.
| Configuration | Computer Type | Template | Description |
|---|---|---|---|
| | |||
| Compatible | Workstations and servers | Compatws.inf | Intended for organizations where most users don't need to be included in the Power Users group. |
| Secure | Workstations, servers, and domain controllers | Securews.inf and Securedc.inf | This configuration provides a higher level of security, including account policy, auditing, and access rights to certain registry keys that directly relate to the system security. |
| High Secure | Workstations, servers, and domain controllers | Hisecws.inf and Hisecdc.inf | This configuration is intended for computers that work in a pure Windows 2000 or Windows Server 2003 environment. It requires that all network communications be signed by a digital signature and encrypted. Thus, computers that are configured using the High Secure template can't interact with computers running earlier versions of the OS. |
How Group Policy Is Stored
Group Policy Objects (GPO) store their information in the Group Policy Container and in the Group Policy Template. The Group Policy Container (GPC) is an Active Directory container that stores Group Policy Object (GPO) properties. It can include nested containers for storing information of the group policy related to both users and computers.
Group Policy Templates
Group Policy Objects (GPOs) store their policy information in the folder structure called Group Policy Template (GPT). GPTs are stored in the \Policies subfolder within the \Sysvol folder on domain controllers.
When modifying the GPO, the template is assigned a directory name, which is actually a Globally Unique Identifier (GUID) of the Group Policy Object that was modified. An example of the name of the Group Policy Template folder is shown below:
%SystemRoot%\sysvol\<SYSVOL>\<Domain_Name>\Policies \{47636445-af79-11d0-91fe-080036644603}
| Note | Notice that the \<SYSVOL> folder becomes a shared directory named SYSVOL. |
The Gpt.ini File
The root level of each GPT folder contains the Gpt.ini file, which keeps the following information for all valid group policy objects:
-
Client extensions of the Group Policy snap-in that contain the user or computer data within the group policy object
-
Whether or not the settings specifying the user or computer policy are disabled
-
Version number for the Group Policy snap-in extension used to create the Group Policy Object
Local Group Policy Objects
Local Group Policy Objects exist on each computer. By default, they only contain the security policy. Local Group Policy Objects are stored in the %SystemRoot%\System32\GroupPolicy folder, and users only have Read access to the folder (administrators and the operating system have full control access to this folder).
Group Policy Template Folders
The Group Policy Template folder contains the following subfolders:
-
\Adm-contains all ADM-files used by the Group Policy Template (GPT).
-
\Scripts-contains all the scripts used by the GPT.
-
\User-contains the Registry.pol file, which lists all registry settings that should be in force in relation to the users. When the user logs on, the system reads this file and loads it to the HKEY_CURRENT_USER registry key. The folder contains the following subfolders:
-
\Apps-contains all files used by Windows Installer
-
\Files-contains a list of files that need to be installed
-
-
\Machine-contains the Registry.pol file that lists all the registry settings, which should be in force in relation to the computers. When the computer is initialized, the Registry.pol file is loaded into the HKEY_LOCAL_MACHINE root key. This folder contains the following subfolders:
-
\Apps-contains all the files that are used by Windows Installer
-
\Files-contains a list of files that need to be installed
-
\Microsoft\Windows NT\SecEdit-stores the file that contains security settings (Gpttmpl.inf)
-
The \User and \Machine subfolders are created automatically during installation, and all the other folders are created when you install the group policy.
The Registry.pol Files
The Administrative Templates extension of the MMC Group Policy snap-in contains information about the group policy templates such as ASCII formatted files like the one named Registry.pol. These files contain individual registry settings specified by the system administrator using the Group Policy snap-in. As I discussed earlier, these settings must be loaded into the registry under HKLM and HKCU keys.
For each group policy template, there are two Registry.pol files: one for computer configuration in the \Machine folder, and another for user configuration in the \User folder.
| Note | Format of the Registry.pol files in Windows 2000/XP is different from the Registry.pol format in Windows NT 4.0 and Windows 95. Notice that you need to use Registry.pol files only with the operating system for which these files were created. |
The Registry.pol files created in Windows NT 4.0 using the System Policy Editor tool were binary files. In contrast, Registry.pol files created by the Group Policy snap-in in Windows 2000 are text files that contain binary strings.
Registry.pol files created in Windows 2000/XP contain the header and registry settings. The header contains version data and a signature, and it has a DWORD format.
Registry settings are specified in the following format:
[key; value; type; size; data]
where:
key - the path to the registry key (notice that you don't need to specify the root key; for example, HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER). That's because the file location itself (in the \User or \Machine folders) specifies the root key where this key should be loaded.
value-list of the registry keys to be deleted (semicolon used as a separator), for example: **DeleteKeys NoRun;NoFind.
type-data type. Notice that the file format supports all registry data types (see Chapter 1). However, the Administrative Templates snap-in only distinguishes between REG_DWORD, REG_EXPAND_SZ, and REG_SZ.
size - the size of the data field (in bytes).
data - this is the data itself.
|
|