Managing Security in Windows 7 : Security Policies (part 1) - Account Policies

Figure 1 shows the Security Settings node of Group Policy for the Default Domain Policy. As you can see, many security settings can be manipulated. Other security settings are found in the Administrative Templates node.

Figure 1. Group Policy Security Settings

The focus in this section is on the following nodes:

• Account Policies

• Local Policies

• System Services

• Removable Storage Access Policy

1. Local Security Policy vs. Group Policy

Group Policy can be configured via Local Computer Policy and via Group Policy objects linked to a site, domain, or OU. Instead of accessing the full Local Computer Policy and browsing to the Security Settings node, you can also access the Local Security Policy via the Administrative Tools menu. Only the Security Settings node is included in the Local Security Policy.

Figure 2 shows the Local Security Policy. It includes most of the same settings that are included in the Security Settings node of the Group Policy object shown earlier. The primary difference is that the Local Security Policy applies only to the local system, just as the Local Computer Policy applies only locally.

Figure 2. Local Security Policy MMC

If you compare Figure 2 with Figure 1 shown earlier, it helps to see that the Security settings are just a small portion of the overall Group Policy.

The primary reason to use the Local Security Policy in a domain is when you're creating a reference computer that will be used as a source image. After creating the reference computer, you can use Windows Deployment Services to capture the image and deploy it to computers in your domain.

You would first install Windows 7 and any desired applications on the system. You could then use Local Security Policy to implement a baseline of security settings. Then each computer would start off with this baseline. Once the computer joins the domain, additional settings will be applied with Group Policy.

2. Account Policies

The Account Policies node includes three nodes that can be used to configure different settings. Figure 3 shows the Account Policies node with the Password Policy node selected.

Figure 3. Account Policies

These are the three Account Policies nodes available in a GPO:

Password Policy

Settings such as the minimum length and maximum age of passwords can be configured here.

Account Lockout Policy

This node includes settings such as the maximum number of times an incorrect password can be entered before an account is locked out.

Kerberos Policy

Kerberos settings include time synchronization for tickets and computers.

The Password Policy and Account Lockout Policy are available in the Local Security Policy and a Group Policy object within a domain. However, the Kerberos Policy is available only in a GPO within a domain.

If you look closely at Figure 3, you'll notice a difference in the icons for all three Account Policies nodes from the icons for other Security Settings policies. The icon includes two servers and a script. However, the Local Policies and Event Log policies are just a single server and a script.

The different icon is a subtle indication that these settings are different than other settings. The difference is that these Account Policies settings apply only at the domain level. In other words, if you created a GPO with these settings and linked it at the site or OU level, these settings would not apply. They are applied only when linked at the domain level. It's common to configure these settings in the Default Domain Policy.

The Password Policy and Account Lockout Policy settings can both be applied in the Local Security Settings. These settings will still apply to the local computer unless the computer is a member of a domain and a domain-level GPO modifies the settings.

2.1. Password Policy

The longer a user continues to use the same password, the more susceptible it becomes to compromise. Similarly, if users don't use complex passwords, they are easier to crack. However, the importance of password security isn't always understood by users.

As an example, a recent study discovered that approximately 70 percent of users commonly use the same password for their banking accounts as they do for other accounts. In other words, a user could be using the same account for Google mail as they do for banking. If an attacker discovers the Google mail password, they can then use it to log in to the banking account and transfer funds to an untraceable overseas account.

Luckily, the Password Policy node can be used to configure requirements for passwords and force users to follow some basic password security practices. The password settings available are as follows:

Enforce Password History

Past passwords are remembered, preventing the user from using the same password over and over. As an example, if 24 passwords are remembered, the user won't be able to reuse a password until they have used 24 other passwords. When using this setting, you should also configure the Minimum Password Age setting to at least 1 day.

Maximum Password Age

This identifies when a password must be changed. When set to 42 days, it prompts the user to change the password as the 42nd day approaches. Once the maximum password age is reached, the user won't be able to log on until the password is changed.

Minimum Password Age

This identifies the minimum period of time in days that a password must be used before it can be changed again. It prevents a user from changing their password right back to what it was previously. If Password History is set to 24 and this setting is set to 1, it would take the user 25 days to get their original password back. This essentially makes it too difficult for a user to circumvent security.

Minimum Password Length

This identifies the minimum number of characters required. The fewer characters used, the easier it is to crack a password. While the default is set at 7, it's generally recommended to have a password of at least 8 characters.

Password Must Meet Complexity Requirements

A complex password must be at least six characters and include characters from three of the following four categories: uppercase letters, lowercase letters, numbers, and special characters. It also cannot contain any portion of the user's full name that exceeds two consecutive characters.

Store Passwords Using Reversible Encryption

This setting is normally disabled. When enabled, the password is stored using reversible encryption, which is similar to storing the password in clear text. An attacker can easily discover it. It's needed in some older applications but should be avoided. For example, this is required when using Challenge Handshake Authentication Protocol (CHAP) for remote access or when using Digest Authentication with Internet Information Services (IIS). More secure authentications are available that don't need reversible encryption.

When you change the Password Policy, many of the settings don't take effect immediately. For example, if you change Minimum Password Length from 7 to 8, users won't be required to change their passwords until the next time they log on. Instead, the policy will be enforced for any new passwords or passwords that are changed.

2.2. Account Lockout Policy

Attackers sometimes try to guess the password of accounts. If they are given an unlimited number of tries, they have a better chance of success. The Account Lockout Policy can be used to limit the number of bad password attempts and lock out an account if the limit is exceeded.

Figure 4 shows the Account Lockout Policy configured to lock out an account indefinitely after five failed attempts.

Figure 4. Account Lockout Policy

The settings that can be configured are as follows:

Account Lockout Duration

This identifies how many minutes an account will be locked out if the lockout threshold is set. For example, if the number was 45, the account would be locked out for 45 minutes and then be automatically unlocked. A setting of 0 indicates that it will be locked out until an administrator unlocks it.

Account Lockout Threshold

The threshold indicates how many failed attempts are allowed before the account is locked out. For example, if it's set to 5, a user can enter the wrong password four times and the account won't be locked out. However, on the fifth bad password, the account is locked for the duration specified in the Account Lockout Duration setting.

Reset Account Lockout Counter After

This setting resets the bad password count after a period of time. Imagine that this setting is set to 30 and the Account Lockout Threshold is set to 5. A user can enter the wrong password four times and the account won't be locked out. If the user waits 30 minutes, the count will be reset to zero. The user will have five more attempts before being locked out.

Exercise 1 shows you how to modify settings in the Account Policies node in the Default Domain Policy.

2.3. Kerberos Policy

Kerberos is the authentication protocol used in Active Directory. A domain controller acts as a Key Distribution Center (KDC) and issues tickets. These tickets are then used to access resources.

Tickets will expire after a period of time, which helps prevent replay attacks within an Active Directory domain. The five settings in this node are as follows:

Enforce User Logon Restrictions

This is enabled by default. It ensures that the KDC validates every request for a session ticket against the user rights policy of the user account. If the network is slow, this setting can be disabled to improve performance.

Maximum Lifetime For User Ticket

Users are granted a ticket-granting ticket (TGT) when they log on. This TGT is used to request service tickets when a resource is accessed. You can specify the lifetime of the TGT with this setting. It is defined in hours, and the default is 10 hours.

Maximum Lifetime For Service Ticket

This setting identifies the lifetime for a ticket used to access a resource. This setting is defined in minutes, and the default is 600 minutes (10 hours).

Maximum Lifetime For User Ticket Renewal

TGTs can be renewed when they expire. This setting identifies the maximum lifetime of ticket. The default is 7 days, meaning that a TGT can be renewed multiple times, but once 7 days have passed a new TGT must be requested.

Maximum Tolerance For Computer Clock Synchronization

This identifies the maximum amount of time that a computer can be out of sync with other computers on the network. The default is 5 minutes. If a computer is out of synchronization, it will no longer have access to network resources. When a computer reboots, it will receive the time from a domain controller and be synchronized again.