5.4 Using Group Policy to Enforce Security

Some basic steps are involved in using Group Policy to enforce security.

First, you need to identify exactly what security settings you need to deploy. Do you simply need to ensure that all users are forced to use a password-protected screensaver? If so, a simple GPO will probably provide the necessary functionality. However, if you need to deploy complex security settings, including file permissions and network security settings, you'll need to configure a security template and add that template to a GPO.

The next step requires you to determine the scope for your security deployment. Do you need to deploy all your security settings domainwide or to particular OUs? It's actually quite rare to deploy one all-encompassing set of security settings across an entire domain, because those settings would affect every user and computer in the domain, including domain controllers and servers. Instead, you'll typically deploy security settings to specific OUs. In fact, once you start thinking about where you want to deploy your security settings, you may find that you need to restructure your Active Directory OU hierarchy a bit to accommodate your security deployment needs.

Of course, you'll need to thoroughly test your security settings before deploying them companywide . Create a test OU (or even an entire test network) that you can use to deploy your security settings to a small number of computers for evaluation. It's very easy to create security templates that make client computers essentially unusable or even prevent communications between server and client computers. Careful testing is a must, especially as you start configuring more complex security settings.

A very important component of Group Policy that provides security is not covered in this chapter. Software Restriction Policy (SRP) allows an administrator to determine what programs a user can and cannot run on his computer. This goes beyond not installing software and actively polices a user's computer to ensure that unauthorized software is not run. SRP is so powerful and effective that an entire chapter (Chapter 6) is devoted to it.

5.4.1 Controlling Password Policies with Group Policy

Password and account lockout policies are certainly the most commonly implemented security policies. They provide enforcement of basic security mechanisms across your enterprise. If you do not currently employ these types of safeguards in your environment, you should examine your need for this type of security. Weak passwords are one of the most commonly compromised system vulnerabilities. If users are not forced to use difficult passwords, an intruder can easily guess or determine passwords and gain access to corporate resources.

All accounts in your domains should be protected by these policies. Local user accounts on member servers and client computers should also be protected, because they represent a potential security hole that attackers love to exploit. Keep in mind that an attacker can use any account to gain access into your environment (yes, even an unprivileged local account). Compromise of even the most restricted account in your enterprise will allow an attacker to gain valuable knowledge of your environment, and that knowledge can be used to launch a more sophisticated attack against more powerful accounts. Additionally, consistency is your friend. If all accounts are protected to the same level, you are assured of an enterprisewide minimum level of security. If you allow exceptions and inconsistencies, a user could claim that her account was compromised because she was an exception to the policy. That's no way to maintain corporate security! Service accounts are often a major exception to security policies, because they are more difficult to change on a regular basis. Although service accounts are more difficult to manage to the same level as user accounts in this regard, service accounts are critical resources and should also receive the same level of security.

Windows Server 2003 recognizes only one password and account lockout policy configuration per domain. Setting the desired password policy at the domain level works properly. Although you can make these Group Policy changes at the OU or site level, they will not apply.

5.4.1.1 Example problem: Woodgrove Bank password policy

Don Fink, our security administrator, has noticed a recent anomaly in the security audit logs. He's noticed an increase in failed logon attempts. The failed attempts apparently affect the account of one user, David Loudon, who is on paternity leave for a month. These failed attempts began shortly after David began his leave. No other accounts are showing this type of behavior, only David's. The most disturbing fact is that after four days of consistently failing logon attempts, no more such events are recorded. Unfortunately, Don doesn't audit logon success activity, as it generates too many events.

Don calls David to try to learn what's happening. David says he does not have a computer at home nor has he been in to work. Don is concerned that David's account may be compromised and that an attacker is attempting to use David's account to access the network. Don immediately disables David's account. Don has no idea what resources, if any, David's account may have accessed without a detailed query of his audit logs, which he begins immediately. He also notifies his manager, who convenes a series of meetings to address the implementation of preventive measures to secure against future attacks of this nature.

The meeting results in a new password policy being created. Woodgrove Bank has had no formal password policy, relying on the default Windows Server 2003 policy. This default policy is examined and found to not be strong enough for the bank. The behavior of account lockout is also examined during the meeting and also found to not be strong enough for current security needs. The following new policy is specified and approved:

A user's password can be no shorter than six characters and must contain letters in both upper- and lowercase and either numbers or nonalphanumeric characters.
Each user must reset his password every 28 days.
A user cannot reuse the same password until the password has changed at least 10 times since last use.
A user can change her password no more frequently than once every seven days. This is to ensure users do not manually or programmatically change passwords back to original values through several quick, successive changes.
An account can make only five unsuccessful logon attempts within 30 minutes before that account is disabled. The account must remain disabled until the corporate helpdesk is contacted by both the affected employee and his manager, and the identity of the user is verified . At that time, the helpdesk will reset the account's password to a new value and provide it via voicemail on the manager's phone, then reenable the account.

Most of these settings can be enforced through a well-planned and properly deployed group policy, specifically through the security settings portion of Group Policy. However, no group policy is fully effective unless it is supported by corporate administrative policy. For more information on this interaction, see Chapter 15.

5.4.1.2 Example implementation: controlling password policy

Don must implement the approved security policy for all users in the woodgrovebank.com domain. This example implements the policy discussed in the previous section, but more policies may be required.

Implementing the specified policy is easily accomplished with Windows Server 2003 by taking the following steps:

Open Active Directory Users and Computers.
Right-click on woodgrovebank.com and click Properties.
Click the Group Policy tab, click the Default Domain Policy, and choose Edit to edit the default GPO. The Default Domain Policy applies to all objects in the domain, including domain controllers. Since domain controllers are responsible for storing user passwords, applying the policy to the domain controllers will ensure that all user passwords comply with the policy.
Navigate to Computer Configuration Windows Settings Security Settings Account Policies, then click on Password Policy. All password policies are displayed in the righthand pane as shown in Figure 5-2.
Double-click the Password Must Meet Complexity Requirements setting and choose Enabled, then click OK.
Double-click the Maximum Password Age setting and change the Password Will Expire In value to 28 days, then click OK.
Double-click the Minimum Password Age setting and change the value to 7 days.
Double-click the Enforce Password History setting and change the Keep Password History For value to 10, then click OK. This setting will also meet the requirement to disallow users from reusing a password within 60 days, as 10 password history 7-day minimum password duration = 70 days. This exceeds the minimum required value.
Double-click the Minimum Password Length setting and change the value to 6. This is redundant with the Password Must Meet Complexity Requirements setting but is important for completeness.
In the left pane, click Account Lockout Policy.
Double-click the Account Lockout Duration setting, check the Define This Policy Setting checkbox and change the value to 0. The description will change to "Account is locked out until administrator unlocks it." Click OK. The Suggested Value Changes dialog box will offer to change the other account lockout settings to the values that you were already planning to use. Click OK to accept these values.
Confirm that all three account lockout policy settings are configured correctly as shown in Figure 5-3.
Close all open windows.

Figure 5-2. The default account policies within the Default Domain Policy at woodgrovebank.com

Figure 5-3. The new values for the Account Lockout Policy

Once the Group Policy changes are saved, Active Directory will replicate these changes to all domain controllers within the woodgrovebank.com domain.

Users with weak passwords will not be challenged to change to a stronger password until their current passwords expire, since Windows Server 2003 checks for password complexity and length only when a password is changed. Also, users who infrequently log on or are on extended leave may not be forced to change their passwords for quite some time, leaving these accounts open to an interval of potential attack You can mitigate this temporary weak password threat by forcing all users to change their passwords at next logon. This can be done through the Active Directory Users and Computers console or by running a script. One such script is provided in Chapter 6 of Active Directory Cookbook (O'Reilly).

5.4.2 Configuring the Desktop with Group Policy

Group Policy can be used to great effect to control users' capabilities on their own computers. This can limit users' opportunities to get themselves into trouble or limit their access to potentially sensitive features, such as mapping network drives or modifying their computers' networking configuration.

5.4.2.1 Example problem: Woodgrove tellers

Tellers at Woodgrove Bank get little computer training before they are sent to the branches to do their job. This has always been somewhat of a problem, so Don has provided as much ongoing assistance as possible. Don has created short and straightforward procedural checklists for performing all the common teller tasks. He has also provided new tellers with a list of common questions and answers to both procedural and troubleshooting questions. The IT group has also staffed a special technical support queue to specifically help tellers with their computer tasks .

Recently, there has been a very high turnover of tellers. Because of the rapid personnel turnover , most new tellers are given virtually no computer training. These new tellers are mostly unfamiliar with computers. This has resulted in a surge in IT workload from two factors: the new tellers are calling technical support for help, and they are experimenting with ways to complete their tasks. Unfortunately, the experimentation has caused numerous computer problems requiring the dispatch of technicians to various branches to repair damage to the operating system. This is causing loss of productivity for all parties involved and is getting worse by the day.

Don's boss wants him to help find a solution. Don believes that applying Group Policy correctly can help. He can restrict the actions these tellers can take and ensure that they can perform only the tasks required by their job. He also wants to make the computers more intruder-resistant, as he is concerned that employees , even trusted tellers, may attempt to attack computer systems over the course of the years . Finally, he wants to remove temptation from these tellers by reducing the number of Start menu items available to them.

When locking down the user's environment, Windows Server 2003 offers an extensive selection of policies that enable the administrator to have very specific control of a user's environment. There are so many options that using the editor without an advance plan is overwhelming and may result in an incomplete or undesired policy being deployed. To determine what options are available and would be appropriate to meet his needs, Don should consult Windows Server 2003's Help and Support Center. There is a complete list of all Group Policy settings and their results available within Help in the Security and Administration topic. This will make planning more effective and allow Don to model various solutions as well as implement the right policy the first time. Also, as stated earlier, these Group Policy deployments must be tested in a lab environment before being rolled out to users. Deploying untested Group Policy is a recipe for disaster ”stopping the tellers from doing their job could stop Woodgrove Bank from doing business entirely, effectively shutting down the company.

Microsoft provides a complete list of available Group Policy settings and defaults that covers several operating systems, including Windows XP and Windows Server 2003. This list is updated frequently and can be found at http://www.microsoft.com/downloads/details.aspx?FamilyID=7821c32f-da15-438d-8e48-45915cd2bc14.

5.4.2.2 Example implementation: controlling desktop resources

Don starts by ensuring that all teller user and computer accounts are in an OU called Tellers. This will allow him to create group policies that will apply only to the tellers' environments, as these new group policies will be more restrictive than the policies for users in other roles within the bank. Although separate Group Policy is often deployed to user and computer OU containers, in this case we can simplify by deploying one set of group policies to the tellers' computer and user accounts.

Before Don makes any changes, he should carefully plan out the policies he is going to change. This can be done through a variety of processes. For most security planning, a risk analysis process is normally used. In this process, the administrator examines the risks that are presented, and the solution provides appropriate mitigations for those risks. This type of process is discussed further in Chapter 15. For the purpose of this example, I'll assume Don has developed a list of desired settings based on a risk analysis.

Don can configure Group Policy with the following steps:

Open Active Directory Users and Computers.
Double-click on woodgrovebank.com, right-click on the Tellers OU, and click Properties.
Click the Group Policy tab and click New to create a new GPO called Teller Restrictions.
Click Edit to edit this GPO.
Navigate to User Configuration Administrative Templates. This section of the Group Policy Object Editor lists numerous Group Policy settings, some of which are shown in Figure 5-4.
Make the policy changes that were determined to be appropriate for the Tellers group. The bulk of user environment restriction policies are in this section. If the changes have not been planned, you can browse through this portion of the editor to learn what options are available. However, you should not change any options until you have a complete list of desired changes and have tested those changes in an isolated test environment.
If restriction of the user's access to Internet Explorer is desired, locate those settings under Windows Settings Internet Explorer Maintenance.
Close all open windows and wait for Active Directory to replicate the new Group Policy information to all domain controllers.

Figure 5-4. The Administrative Templates section of the Group Policy Object Editor contains more options for restricting the user's environment than you might expect

To ensure that the changes were properly made, Don could install a computer and place its account in the Tellers OU and then create a user account in the Tellers OU. Logging in using this test account on the computer would simulate the environment the tellers will receive with the same policies. If the environment allows Don to complete the tasks the tellers must accomplish while still restricting their other activities, the Group Policy is effective. If any undesired results are obtained (e.g., Don forgot to lock down a specific component), the policy can be modified before the tellers receive it.

In addition to the steps provided, Don should consider deploying software restriction policies to limit the programs that the tellers can run. This is discussed in detail in Chapter 6.

5.4.3 Configuring Auditing with Group Policy

The previous section demonstrated a relatively simple application of Group Policy, locking down the desktop options of a group of users. But you can do much more with Group Policy. Virtually any configuration you want to make on a computer can be done with Group Policy.

The example in this section details configuring security auditing. Auditing records events as they happen and stores them in logs. Administrators and automated systems can then access these records to determine the cause of an intrusion that has already happened , search them for suspicious patterns that may indicate an intruder trying to break in, or best of all, review them to determine potential vulnerabilities and fix them before an attacker finds them. Security and system logs may also provide forensic evidence in the case of legal proceedings against attackers. More information on auditing is provided in Chapter 15.

5.4.3.1 Example problem: security auditing for servers

Assume for this scenario (and it's a big assumption!) that Woodgrove Bank has a history of carefully protecting its servers from attack. However, they realize that protection is not enough. If a successful attack occurs, it may not have obvious and immediate symptoms such as a service outage or data loss. Instead, an attacker may copy information and disconnect without disrupting service. An intruder might also plant some malicious software that continuously monitors the server and forwards desired information to the attacker. This is obviously something that needs to be prevented, but if prevention fails, the bank will need evidence that the events took place. Auditing can help provide that evidence.

Don is required by company policy to implement security auditing on all human resources computers within woodgrovebank.com. Important security events must be logged by Windows Server 2003 and stored until Don reviews and saves the log to a file for archival. The log must not clear itself automatically, as that could result in a loss of evidentiary data. He also wants to audit logon activity for domain accounts to determine if any users are displaying unusual account behavior that might indicate a potential account compromise ”multiple logons within a short period of time, logons at odd hours, and so on. Finally, Don must ensure that any attempt to add users to groups is logged for later auditing to verify that the user is authorized to be a member of that group. This will help unveil any attempts by rogue administrators to place innocent-looking user accounts in highly privileged groups for later unauthorized use.

5.4.3.2 Example implementation: controlling auditing

Don begins this implementation by ensuring that all the desired human resources computers are in an OU called HR Servers. User accounts do not matter, as the auditing is configured for the computer and not for the user. All domain controllers are automatically placed in their own OU called Domain Controllers, so Don does not need to move them.

Don can configure Group Policy with the following steps:

Open Active Directory Users and Computers.
Double-click on woodgrovebank.com, right-click on the Domain Controllers OU, and click Properties. This OU is selected because domain controllers are the desired computers for auditing in this scenario.
Click the Group Policy tab, click Default Domain Controllers Policy, then click Edit to edit the GPO.
Navigate to Computer Configuration Windows Settings Security Settings Local Policies Audit Policy. This section of the Group Policy Object Editor controls what events are audited on the target computers. The default settings of Windows Server 2003 are shown in Figure 5-5. Don verifies that the current settings already meet his planned requirements for auditing account management and logon events.
Navigate to the Security Options node. Double-click the "Audit: shut down system immediately if unable to log security audits " setting, check the Define This Policy Setting checkbox and set the value to Enabled.
Navigate to the Event Log node.
Double-click the Maximum Security Log Size setting, check the Define This Policy Setting checkbox and set the value to a sufficiently large number such as 32768. This will vary depending on the number of audit events created and the frequency of the logs being archived and cleared.
Double-click the Retention Method for Security Log setting, check the Define This Policy Setting checkbox and select the "Do not overwrite events (clear log manually)" value.

Figure 5-5. The default domain controller audit policies

The changes to the way security audit events are stored and retained are shown in Figure 5-6. These settings directly control how many audit events are stored and what the operating system will do if the log becomes full. In the configuration shown, 32 megabytes of security log entries will be stored before the security log is full. When the security log is full, the system will automatically shut down and be unavailable until the log is manually cleared.

How do you clear a security log on a computer that will not boot because of a full security log? This is a complex issue that must be addressed by following the instructions provided at http://support.microsoft.com/default.aspx?scid=kb;en-us;829082.

Figure 5-6. This properly configured Group Policy will retain 32 megabytes of security audit events and never overwrite a previous audit event to store a new one

Because the audit events will eventually fill the system, Don must simultaneously (or previously) implement a system for archiving and clearing the event logs for all domain controllers. This has to be done before the event logs fill up. Many software products are available to automate this process and roll all events up into one single database that can be queried and analyzed . Don could also do this manually or delegate the task to a worker within the organization. Because so many selections are available, Don should carefully weigh all factors when determining how to handle the audit logs. As long as they are regularly cleared, the domain controllers will remain available. And as long as they are reviewed for nefarious activity on a regular basis, the security information that the logs provide will prove useful.

More information on configuring event logs properly is provided in Chapter 15.

Verifying Group Policy Application with RSoP

Deploying Group Policy is great, but as a security administrator, how do you verify that the configured policies are being applied and enforced on computers in your enterprise? One way is to conduct periodic audits and tests to verify these settings.

Microsoft provides a very useful tool called Group Policy Resultant Set of Policy (RSoP) to help you perform these audits. RSoP is an immensely useful tool when it comes to verifying Group Policy. Some of its features include:

Verifying Group Policy application against a user, a computer, or both
Verifying Group Policy application against a site, a domain, or an organizational unit
Simulating policy application without actually implementing the policy through planning mode
Verifying Group Policy application against the local or a remote computer

There is a great deal of documentation on RSoP available from Microsoft. It is also discussed in Chapter 15 of this book.