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.
NOTE
Similar settings can be found in the Local Computer Policy in the Computer Configuration => Windows Settings =>
Security Settings node. You can also access many of these settings for a
single computer using Local Security Policy via the Administrative
Tools menu.
The focus in this section is on the following nodes:
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.
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.
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.
|
Windows Server 2008 introduced a
new feature that allows administrators to create Password Settings
objects (PSOs) that can be used to configure Account Policies settings
for specific groups. The GPO settings will be applied only at the domain
level, but a PSO can be applied to a group.
|
|
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.
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.
|
The Administrator account
cannot be locked out even if an Account Lockout Policy is configured.
This gives an attacker an unlimited number of guesses. This is one of
the reasons why the Administrator account is often renamed on a system.
When it's renamed and the new Administrator account name is unknown, an
attacker can't try to guess the password.
|
|
Exercise 1 shows you how to modify settings in the Account Policies node in the Default Domain Policy.
Launch
Group Policy Management console via the Administrative Tools menu. You
can launch the GPMC from a Windows 7 computer with Remote Server
Administration Tools installed or on a domain controller. Expand the domain and access the Default Domain Policy. Right-click
Default Domain Policy and select Edit. The Default Domain Policy will
open in the Group Policy Management Editor window. Expand Computer Configuration => Policies => Windows Settings => Security Settings => Account Policies => Password Policy. You can view the current settings of the Password Policy in the main window. Double-click
each of the settings to view its current settings. Notice that each
setting also has an Explain tab. If any of the settings are unclear, you
can read more information on the Explain tab. You can modify any of
these settings as needed. Select
the Account Lockout Policy. These settings are not configured by
default. If they aren't configured, you can follow these steps to
configure them. Double-click
the Account Lockout Duration setting. Select the Define This Policy
Setting check box. Change the minutes from 30 to 0. Notice that this
changes the description to indicate that the account will be locked out
until an administrator unlocks it. Click
OK. A dialog box will appear indicating the recommended settings for
the other Account Lockout Policy settings. Review the changes and then
click OK. Click OK again. You can return these settings to Not Defined or leave them as they are.
Select
the Kerberos Policy. Double-click each of the settings to view its
status. It's best to leave these settings as they are unless you have a
specific reason to change them.
|
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.
