This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding and Implementing Group Policy
One of the most powerful aspects of Windows XP Professional and Windows 2000 Active Directory is the implementation of Group Policy. Group Policy is the capability to control finite details of a computer or user quickly and easily. These policies can either be configured at the local level or within the Active Directory structure. Regardless of the location of implementation, these settings are extremely powerful and can change the way normal control and administration is done within a company.
Local Group Policy
Actually, you can administer Local Policies from two locations: a Local Group Policy and a Local Security Policy. The Local Group Policy can be accessed by opening the Group Policy snap-in within a Microsoft Management Console and then selecting the Local Computer option. You can configure security-related settings using the Local Security Policy. Choose Start, Administrative Tools, Local Security Policy. Each of the nodes in the Local Security Policy Console is a security area or scope, within which you will find dozens of security-related settings. The Local Security Policy is nothing more than a subset of the Local Group Policy. So, when you open the Local Group Policy, you are also accessing the Local Security Policy.
Managing Local Group Policies
The Local Group Policy and the Local Security Policy tools are most helpful on standalone systems and laptops that roam away from the network environment. The Local Group Policy controls the configuration of the local computer and user. The policy-based settings will apply to a computer at startup and to a user at logon. Also, these policy settings are applied at a refresh interval, which does not require a reboot or logging off. The default refresh interval for all Group Policy Object settings on a Windows XP client is 90 minutes.
In a workgroup environment, you will need to access each computer and make the desired settings on each computer individually. Methods exist to make this more efficient by using security templates, but the process is still a manual one that requires decentralized administration of the policy settings. The solution to this decentralized administration is to implement Active Directory and apply the desired settings to a grouping of computers or users by using Group Policy Objects within Active Directory.
Group Policy Objects (GPO)
Group Policy Objects (GPOs) within Active Directory take the concept of policy-enforced configurations and apply it to multiple computers or users. Unlike Local Group Policy, GPOs provide a centralized enumeration of configuration settings. You can apply, or link, GPOs to the following:
A site—This is an Active Directory object that represents a portion of your network topology with good connectivity—a local area network (LAN), for example.
A domain—This causes the configuration specified by the policy to be applied to every user or computer in the domain.
An OU—This applies policies to users or computers in the OU or any child OUs.
To access Group Policy, you must go to the properties of a site, domain, or OU (SDOU), and click the Group Policy tab. Therefore, to work with group policy for a site, you use the Active Directory Sites and Services Console, whereas to work with group policy for a domain or OU, you use Active Directory Users and Computers.
An individual machine can have only one Local Group Policy, whereas an SDOU can have multiple GPOs linked to them. In the Group Policy Properties dialog box, you can create a new GPO by clicking New, or link an existing GPO to the SDOU by clicking Add. If you select a group policy and click Edit, you expose the GPO in the Group Policy Editor. The GPMC removes much of the complexity of creating and linking GPOs to Active Directory objects. The GPMC displays the domain, OUs, and sites clearly, which can all be right-clicked to expose options for creating and linking GPOs to these nodes.
Application of Group Policy Objects
GPOs are divided into the Computer Configuration and User Configuration nodes. The computer settings apply to every computer in the site, domain, or OU to which the policy is linked, and, by default, to all child OUs. Computer settings take effect at startup and at every refresh interval, which by default is 90 minutes. User settings affect every user in the site, domain, or OU and its children at logon, and after each refresh interval.
When a computer starts, its current settings are modified first by any configuration specified by the Local Group Policy. Then the configurations for the SDOU GPOs are applied. The SDOU policies are applied in order: first, the policies linked to the computer’s site, then the policies for its domain, and finally the policies for each OU in the branch that leads to the object’s OU. The policy settings from the Local Group Policy and the SDOU will append to each other if no conflict exists. If a conflict occurs in a specific configuration setting, the last setting applied has control. Therefore, the policies that are "closest" to the computer—the policies linked to its OU, for example—take precedence if a conflict arises. The same application of policies applies to a user at logon: local policy, site policy, domain policy, and OU policy.
User Rights Assignment
User rights, also called privileges, enable a user or group to perform system functions such as changing the system time, backing up or restoring files, and formatting a disk volume. Some rights are assigned to Built-in groups. For example, all members of the Administrators group can format a disk volume. You cannot deny that right to the members of the Administrators group, nor can you assign that right to a user or group you create. Other rights are assignable. For example, the right to back up files and folders is given by default to all members of the Administrators and Backup Operators, but you can remove the right for those groups or assign the right to other users or groups. You can modify the rights that are visible in the Local Security Policy Console. You do not see the "hard wired" rights in this interface.
User rights, because they are system oriented, override object permissions when the two are in conflict with each other. For example, a user may be denied permission to read a folder on a disk volume. However, if the user has been given the privilege to back up files and folders, a backup of the folder succeeds, even though the user is denied permission to the folder.
Security Options
In the Security Options node are a number of useful security settings. This node highlights one of the advantages of policies, because while many of these settings are accessible elsewhere in the user interface (for example, you can specify driver signing in the System applet), a policy enables you to configure all those settings, from all the tools and applets, into a centralized location.
Some particularly useful options to be familiar with are the following:
Clear the Virtual Memory Pagefile When the System Shuts Down—By default, the pagefile is not cleared and could allow unauthorized access to sensitive information that remains in the pagefile.
Do Not Display Last Username in Logon Screen—This option forces users to enter both their username and password at logon. By default, the policy is disabled and the name of the previously logged-on user is displayed.
Number of Previous Logons to Cache—This policy limits the number of cached profiles that are on a system. Not only will this clean up the hard drive space on a system, but if no cached profiles exist, users will be forced to access a domain controller when logging on to the domain, instead of using cached credentials.
Account Policies
Account policies control the password requirements and how the system responds to invalid logon attempts. The policies you can specify include the following:
Maximum Password Age—Specifies the period of time after which a password must be changed.
Minimum Password Length—Specifies the number of characters in a password. Passwords can contain up to 127 characters; however, most passwords should not exceed 14 characters.
Passwords Must Meet Complexity Requirements—This policy, if in effect, does not allow a password change unless the new password contains at least three of four character types: uppercase (A through Z), lowercase (a through z), numeric (0 through 9), and nonalphanumeric (such as !). All passwords must also be at least six characters long to meet complexity requirements.
Enforce Password History—The system can remember a specified number of previous passwords. When a user attempts to change his or her password, the new password is compared against the history; if the new password is unique, the change is allowed.
Minimum Password Age—Specifies the number of days that a new password must be used before it can be changed again.
Account Lockout Threshold—Specifies the number of denied logon attempts after which an account is locked out. For example, if this is set to 3, a lockout occurs if a user enters the wrong password three times; any further logon attempt will be denied. If this is set to 0, there is no lockout threshold.
Reset Account Lockout Counter After—Specifies the number of minutes after which the counter that applies to the lockout threshold is reset. For example, if the counter is reset after 5 minutes and the account lockout threshold is 3, a user can log on twice with the incorrect password. After 5 minutes, the counter is reset, so the user can log on twice more. A third invalid logon during a 5-minute period locks out the account.
Account Lockout Duration—Specifies how long logon attempts are denied after a lockout. During this period, a logon with the locked out username is not authenticated.
Audit Policies
Audit policies specify what types of events are entered into the Security Log. The most important policies to understand include those in the following list:
Logon Events—Authentication of users logging on or off locally and making connections to the computer from remote systems.
Account Management—Any change to account properties, including password changes and additions, deletions, or modifications to users or groups.
Object Access—Access to objects on which auditing has been specified. Auditing object access, for example, enables auditing of files and folders on an NT File System (NTFS) volume, but you must also configure auditing on those files and folders. Refer to Chapter 2, "Establishing, Configuring, and Managing Resources," for a detailed discussion of auditing.
Privilege Use—Use of any user rights, now called privileges. For example, this policy audits a user who changes the system time, because changing the system time is a privilege.
For each policy, you can specify to audit successes, failures, or both. As events are logged, they appear in the Security Log, which, by default, can be viewed only by administrators. Other logs can be viewed by anyone.
SP2 GPO Changes
Service Pack 2 is known as the "security pack" because of all the security changes it provides. A large amount of those security changes and features can be controlled with GPOs. Microsoft has added more than 600 (no, this is not a typing error) settings to a default GPO. The new settings help control Windows Firewall, Windows Update, Internet communications, and more. The majority of these changes have taken place in the Administrative Templates section of both the User Configuration and Computer Configurations sections.