Understanding Account Policies
Possible values:
There are three
folders in the Account Policies folder:
·
Password Policy
·
Account Lockout Policy
·
Kerberos Policy
A single Windows
Server 2008 domain can have one of each of these policies. If these
policies are set at any other level below the domain level in the Active
Directory® directory service, they affect only local accounts on member
servers.
The Account Policies
settings in Group Policy are all applied at the domain level. Default values
are present in the built-in Default Domain Controllers Policy GPO for Password
Policy settings, Account Lockout Policy settings, and Kerberos Policy settings.
The domain Account Policies settings become the default local Account Policies
settings of any Windows®-based computer that is a member of the domain.
The only exception to
this rule is when another Account Policies setting is defined for an
organizational unit (OU). The Account Policies settings for the OU affect the
local policy on any computers that are contained in the OU. For example, if an
OU policy defines a maximum password age that differs from the domain-level
Account Policies settings, the OU policy is applied and enforced only when
users log on to the local computer. The default local computer policies apply
only to computers that are in a workgroup or in a domain where neither an OU
Account Policies setting nor a domain policy applies.
The following sections
discuss the settings for each of the policies that is in the Account Policies
folder.
In Windows and many
other operating systems, the most common method to authenticate a user's
identity is to use a secret passphrase or password. A secure network
environment requires all users to use strong passwords (ones that have at least
10 characters and include a combination of letters, numbers, and symbols).
These passwords help prevent the compromise of user accounts and administrative
accounts by unauthorized people who use either manual methods or automated tools
to guess weak passwords. Strong passwords that are changed regularly reduce the
likelihood of a successful password attack.
You can enforce the
use of strong passwords through an appropriate password policy. There are
password policy settings that control the complexity and lifetime of passwords,
such as the Passwords must meet complexity requirements setting.
You can configure the
password policy settings in the following location by using the Group Policy
Management Console on your domain controller:
Computer
Configuration\Windows Settings\Security Settings\Account Policies\Password
Policy
If individual groups
require distinct password policies, these groups should be separated into
another domain or forest based on any additional requirements.
This policy setting
determines the number of unique new passwords that must be associated with a
user account before an old password can be reused.
Possible
values:
·
User-specified value
between 0 and 24
·
Not Defined
On domain controllers
the default value for this setting is 24. On stand-alone servers the default
value for this setting is 0.
This policy setting
determines the maximum number of days a password can be used before the user
must change it. Its value must be more than the Minimum
password age value.
Possible
values:
·
User-specified number
of days between 0 and 999
·
Not Defined
The default value for
this setting is 42.
This policy setting
determines the minimum number of days that a password must be used before the
user is allowed to change it. Its value must be less than the Maximum
password age value.
Configure this policy
setting to a number that is greater than 0 and set the Enforce
password history setting
to make this setting effective. If you configure the Enforce
password history setting
to 0, users are not required to choose a new unique password when prompted to
change their password. If password history is used, users must enter a new
unique password when they change their password.
Possible
values:
·
User-specified number
of days between 0 and 998
·
Not Defined
The default value for
this setting is 1 on domain controllers and 0 on stand-alone servers.\
This policy setting
determines the fewest number of characters that can make up a password for a
user account. Some prefer using a passphrase rather than a password. Starting
with Microsoft Windows 2000, passphrases can be quite long and they can
include spaces, punctuation marks, and Unicode characters. Therefore, a phrase
such as "I want to drink a $5 beverage!" is a valid passphrase. Such
a phrase is considerably stronger than an 8 or 10 character string, and is
easier to remember.
The longer a password
is, the better security it provides, especially if it includes a character
combination of uppercase and lowercase letters, digits, symbols, and punctuation.
Assuming a computer performing a brute force attack that can attempt 10,000,000
character combinations a second, the amount of time that it would take to
discover a password for a user account is as follows:
Password length
|
Alphanumeric case-sensitive (62 characters)
|
Alphanumeric case-sensitive including
symbols (96 characters)
|
2
|
Instant
|
Instant
|
3
|
Instant
|
Instant
|
4
|
Less than 2 seconds
|
8.5 seconds
|
5
|
1.5 minutes
|
13.5 minutes
|
6
|
1.5 hours
|
22 hours
|
7
|
4 days
|
87 days
|
8
|
253 days
|
23 years
|
Possible values:
·
User-specified number
between 0 and 14
·
Not Defined
The default value for
this setting is 7 on domain controllers and 0 on stand-alone servers.
This policy setting
determines whether passwords must meet a series of guidelines that are
considered important for a strong password.
If this policy is
enabled, passwords must meet the following minimum requirements when they are
changed or created:
·
Passwords must not
contain the user's entire samAccountName (Account Name) value or entire
displayName (Full Name) value. Both checks are not case sensitive:
o
The samAccountName is
checked in its entirety only to determine whether it is part of the password.
If the samAccountName is less than three characters long, this check is
skipped.
o
The displayName is
parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces,
pound signs, and tabs. If any of these delimiters are found, the displayName is
split and all parsed sections (tokens) are confirmed not to be included in the
password. Tokens that are less than three characters in length are ignored, and
substrings of the tokens are not checked. For example, the name "Erin M.
Hagens" is split into three tokens: "Erin," "M," and
"Hagens." Because the second token is only one character long, it is
ignored. Therefore, this user could not have a password that included either
"erin" or "hagens" as a substring anywhere in the password.
·
Passwords must contain
characters from three of the following five categories:
o
Uppercase characters
of European languages (A through Z, with diacritic marks, Greek and Cyrillic
characters)
o
Lowercase characters
of European languages (a through z, sharp-s, with diacritic marks, Greek and
Cyrillic characters)
o
Base 10 digits (0
through 9)
o
Nonalphanumeric
characters: ~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/
o
Any Unicode character
that is categorized as an alphabetic character but is not uppercase or
lowercase. This includes Unicode characters from Asian languages.
This policy setting
determines whether Windows Server 2008, Windows Vista, Windows
Server 2003, Windows 2000 Server, Windows 2000 Professional, and
Windows XP Professional use reversible encryption when they store
passwords.
The Store
password using reversible encryption for all users in the domain setting provides support for application
protocols that require knowledge of the user's password for authentication
purposes. However, encrypted passwords that are stored in a way that is
reversible can potentially be decrypted by an attacker that gets hold of the
encrypted version and is able to find the encryption key. Also, a successful
brute force attack could obtain not only a usable password (one that is able to
perform authentications to the domain) but one that is identical to the actual
user's password (which could give insight into the user's password selection
criteria, or be usable in other systems sharing the same password). A
knowledgeable attacker who was able to break this encryption could then log on
to network resources with the compromised account.
More than a few
unsuccessful password submissions during an attempt to log on to a computer
might represent an attacker's attempts to determine an account password by
trial and error. The Windows operating system can track logon attempts, and you
can configure the operating system to disable the account for a preset period
of time after a specified number of failed attempts. Account lockout policy
settings control the threshold for this response and what action to take after
the threshold is reached.
You can configure the
account lockout policy settings in the following location within the Group
Policy Management Console:
Computer
Configuration\Windows Settings\Account Policies\Account Lockout Policy
This policy setting
determines the number of minutes that a locked-out account remains locked out
before it is automatically unlocked. The available range is from 1 to 99,999
minutes. To specify that the account will be locked out until an administrator
manually unlocks it, configure the value to 0. If the Account
lockout threshold setting
is defined, the Account lockout duration must be greater than or equal to the value for
the Reset
account lockout counter after setting.
Possible
values:
·
User-defined value in
minutes between 0 and 99,999
·
Not Defined
This policy setting is
dependent upon the Account lockout threshold setting being defined and must be greater than
or equal to the value specified for the Reset lockout counter after setting.
This policy setting
determines the number of failed logon attempts that causes a user account to
become locked. A locked account cannot be used until it is reset by an
administrator or until the lockout duration for the account expires. You can
specify up to 999 failed logon attempts, or you can set the value to 0 to
specify that the account is never locked out. When you define an Account
lockout threshold, you must also define
the Reset
lockout counter after and
the Account
lockout duration settings.
Failed password
attempts against workstations or member servers that have been locked by either
pressing CTRL+ALT+DELETE or password-protected screen savers do not count as
failed logon attempts unless theInteractive logon: Require Domain Controller
authentication to unlock workstation policy setting is enabled in the Security Options section of
Group Policy. If it is, repeated failed password attempts to unlock the
workstation count against the account lockout threshold.
Possible
values:
·
User-defined value
between 0 and 999
·
Not Defined
The default value for
this setting is 0.
This policy setting
determines the number of minutes that must elapse before the counter that
tracks failed logon attempts and triggers account lockouts is reset to 0. This
reset time must be less than or equal to theAccount lockout
duration setting configuration.
Possible
values:
·
User-defined number of
minutes between 1 and 99,999
·
Not Defined
In Windows
Server 2003 with Service Pack 1 (SP1) and later, the Kerberos
authentication protocol provides the default mechanism for domain
authentication services and the authorization data that is necessary for a user
to access a resource and perform a task on that resource. If the lifetime of
Kerberos tickets is reduced, the risk of a legitimate user's credentials being
stolen and successfully used by an attacker decreases. However, authorization
overhead increases.
In most environments,
the Kerberos policy settings do not need to be changed. These policy settings
are applied at the domain level, and the default values are configured in the
Default Domain Policy GPO in a default installation of a Windows
Server 2008 or Windows Server 2003 Active Directory domain.
You can configure the
Kerberos policy settings in the following location within the Group Policy
Management Console:
Computer
Configuration\Windows Settings\Security Settings\Account Policies\Kerberos
Policy
This policy setting
determines whether the Key Distribution Center (KDC) validates every request
for a session ticket against the user rights policy of the user account.
Validation of each request for a session ticket is optional because the extra
step takes time and can slow down network access to services.
Possible
values:
·
Enabled
·
Disabled
·
Not Defined
The default value for
this setting is Enabled.
This policy setting
determines the maximum amount of time (in minutes) that a granted session
ticket can be used to access a particular service. The setting must be 10
minutes or greater, and less than or equal to the value of the Maximum
lifetime for user ticket setting.
If a client presents
an expired session ticket when it requests a connection to a server, the server
returns an error message and the client must request a new session ticket from
the KDC. After a connection is authenticated, however, it does not matter
whether the session ticket remains valid. Session tickets are used only to
authenticate new connections with servers. Operations are not interrupted if
the session ticket that authenticated the connection expires during the
connection.
Possible
values:
·
User-defined value in
minutes between 10 and 99,999. If you configure this policy setting to 0,
service tickets do not expire.
·
Not Defined.
The default value for
this setting is 600.
This policy setting
determines the maximum amount of time (in hours) of a user's TGT. When a user's
TGT expires, a new one must be requested or the existing one must be renewed.
Possible
values:
·
User-defined value in
hours between 0 and 99,999.
·
Not Defined.
The default value for
this setting is 10.
This policy setting
determines the period of time (in days) during which a user's TGT can be
renewed.
Possible
values:
·
User-defined value in
minutes between 0 and 99,999.
·
Not Defined.
The default value for
this setting is 7.
This policy setting
determines the maximum time difference (in minutes) that the Kerberos protocol
allows between the time on the client computer's clock and the time on the
domain controller that provides Kerberos authentication.
Possible
values:
·
User-defined value in
minutes between 1 and 99,999
·
Not Defined
The default value for
this setting is 5.
No comments:
Post a Comment