Account Policy Settings
Account Policy Settings
Each of these servers is assigned a unique IP address that identifies it on the local
network where it is connected.
It would be impossible to
remember all of the IP addresses
for all of the servers hosting
services on the Internet.
DNS names are registered and organized on the Internet within specific high level
groups, or domains.
Some of the most common high level domains on the Internet are .com, .edu, and .net.
A DNS server contains a table that associates hostnames in a domain with corresponding
IP addresses.
When a client has the name of server, such as a web server, but needs to find the IP
address, it sends a request to the DNS server on port 53.
The client uses the IP address of the DNS server configured in the DNS settings of the
host's IP configuration.
When the DNS server receives the request, it checks its table to determine the IP address
associated with that web server.
If the local DNS server does not have an entry for the requested name, it queries another
DNS server within the domain.
When the DNS server learns the IP address, that information is sent back to the client.
If the DNS server cannot determine the IP address, the request will time out and the client
will not be able to communicate with the web server.
This request is sent to the server using the Hypertext Transfer Protocol (HTTP).
When the server receives a port 80 request, the server responds to the client request and
sends the web page to the client.
The information content of a web page is encoded using specialized 'mark-up' languages.
HTML (Hypertext Mark-up Language) is the most commonly used but others, such as
XML and XHTML, are gaining popularity.
In order to provide security for the data, HTTP can be used with secure transport
protocols.
Requests for secure HTTP are sent to port 443. These requests require the use of https:
rather than http
The File Transfer Protocol (FTP) provides an easy method to transfer files from one
computer to another.
When the server receives a port 21 request the server respond to the client any file
transmission with a protocol FTP(File transmission Protocol)
A host running FTP client software can access an FTP server to perform various file
management functions including file uploads and downloads.
It also enables clients to manage files remotely by sending file management commands
such as delete or rename.
To accomplish this, the FTP service uses two different ports to communicate between
client and server.
FTP client software is built into computer operating systems and into most web browsers.
Email servers run server software that enables them to interact with clients and with other
email servers over the network.
Each mail server receives and stores mail for users who have mailboxes configured on
the mail server.
Each user with a mailbox must then use an email client to access the mail server and read
these messages.
Mail servers are also used to send mail addressed to local mailboxes or mailboxes located
on other email servers.
Various application protocols used in processing email include SMTP, POP3, and
IMAP4.
• The local server then decides if the message is destined for a local mailbox or if the
message is addressed to a mailbox on another server.
• If the server has to send the message to a different server, SMTP is used between the two
servers as well. SMTP requests are sent to port 25.
When the client connects to the email server, the messages are downloaded to the client.
By default, messages are not kept on the server after they have been accessed by the
client.
However, it keeps the messages in the mailboxes on the server, unless they are deleted
by the user.
The most current version of IMAP is IMAP4 which listens for client requests on port
143.
There are different mail server software for d/t plat forms.
Port Numbers
Ports are broken into three categories and range in number from 1 to 65,535.
Account Policies
Password Policy
Kerberos Policy
The policy settings under Account Policies are implemented at the domain level. A
Windows Server 2003 domain must have a single password policy, account lockout
policy, and Kerberos version 5 authentication protocol policies for the domain.
Configuring these policy settings at any other level in Active Directory will only affect
local accounts on member servers. If there are groups that require separate password
policies, they should be segmented into another domain or forest, based on any additional
requirements.
For domain accounts, there can be only one account policy per domain. The account
policy must be defined in the Default Domain Policy or in a new policy that is linked to
the root of the domain and given precedence over the Default Domain Policy, which is
enforced by the domain
controllers that make up the
domain. A domain controller
always pulls the account
policy from a Group Policy
object (GPO) linked to the
domain, which by default is
the Default Domain Policy
GPO. This behavior occurs even if there is a different account policy applied to the
organizational unit (OU) that contains the domain controller.
By default, workstations and servers joined to a domain — the domain member
computers — also receive the same account policy for their local accounts. However,
local account policies for member computers can be differentiated from the domain
account policy by defining an account policy for the OU that contains the member
computers.
Password Policy.
o These policy settings are used for domain or local user accounts. They determine
settings for passwords, such as enforcement and lifetimes.
Account Lockout Policy.
o These policy settings are used for domain or local user accounts. They determine
the circumstances and length of time that an account will be locked out of the
system.
Kerberos Policy.
o These policy settings are used for domain user accounts.
Password Policy
In Windows and many other operating systems, the most common method for
authenticating a user’s identity is to use a secret passphrase or password. Securing your
network environment requires that strong passwords be used by all users. This helps
avoid the threat of a malicious user guessing a weak password, whether through manual
methods or by using tools, to acquire the credentials of a compromised user account. This
is especially true for administrative accounts. When you change a complex password
regularly, it reduces the likelihood of a successful password attack. Password policy
settings control the complexity and lifetime of passwords. Each specific password policy
account setting is discussed in this section. Password Policy settings can be configured in
the following location in Group Policy Object Editor:
Computer Configuration\Windows Settings\Security Settings\Account Policies\Password
Policy\
The Enforce password history policy setting determines the number of unique new
passwords that must be associated with a user account before an old password can be
reused.
The possible values for this Group Policy setting are:
A user-defined number from 0 through 24.
Not defined.
Discussion
Password reuse is an important concern in any organization. Many users want to reuse
the same password for their account over a long period of time. The longer the same
password is used for a particular account, the greater the chance that an attacker will be
able to determine the password through brute force attacks. If users are required to
change their password, but nothing prevents them from using the old password or
continually reusing a small number of passwords, the effectiveness of a good password
policy is greatly reduced.
Specifying a low number for Enforce password history allows users to continually use
the same small number of passwords repeatedly. If you do not also set Minimum
password age, users can change their password as many times in a row as necessary in
order to reuse their original password.
If you set Enforce password history to a number greater than zero, users must come up
with a new password every time they are required to change their old one. This improves
security, but it can increase the risk that users will write down their passwords so they do
not forget them.
If you set the value to the maximum of 24, it helps to ensure that vulnerabilities caused
by password reuse are kept to a minimum.
For this policy setting to be effective in your organization, configure Minimum
password age so that you do not allow passwords to be changed immediately. Enforce
password history should be set at the level that combines a reasonable maximum
password age with a reasonable password change interval requirement for users.
Location
Default Values
The Maximum password age policy setting determines the number of days that a
password can be used before the system requires the user to change it.
The possible values for this Group Policy setting are:
o A user-defined number of days from 0 through 999.
o Not defined.
Discussion
If your users change their passwords frequently, it helps to reduce the risk that a valid
password might be cracked, and it mitigates the risk that someone may use a password
that has been wrongfully acquired. Maximum password age can be configured so that
users are never required to change their passwords, but this result in a major security risk.
Many cautious administrators choose to set Maximum password age to a value between
30 and 60 days. You can set Maximum password age to never expire by setting the
number of days to 0.
Setting Maximum password age very low requires users to change their passwords too
often. This might actually reduce security in the organization; because it can increase the
possibility of that users will write their passwords down to avoid forgetting them. If you
set the value very high, it reduces the level of security within an organization, because it
gives a potential attacker more time to guess a user’s password.
Location
Default Values
The Minimum password age policy setting determines the number of days that a
password must be used before the user is allowed to change it. Minimum password age
must be less than Maximum password age.
Configure this to be greater than 0 if you want the Enforce password history policy
setting to be effective. If Enforce password history is set to 0, the user does not have to
choose a new password. If Enforce password history is set to a number greater than
zero, users must enter a new unique password when they change their password.
The possible values for this Group Policy setting are
A user-defined number of days from 0 through 999.
Not defined.
Discussion
Forcing users to change passwords regularly is ineffective if they can cycle through
passwords until they get to an old favorite. Use Minimum password age with Enforce
password history to prevent this. For example, if Enforce password history is set to 12
(which ensure that users cannot reuse any of their last 12 passwords) and Minimum
password age is 0, users could change their password 13 times in a row to return to the
password they were originally using. Therefore, Minimum password age must be set to
a value greater than 0 for Enforce password history to be effective.
It is advisable to set Minimum password age to a value of 2 days. Setting the number of
days to 0 allows immediate password changes, which is not recommended.
There is one minor issue associated with setting Minimum password age to a number
greater than 0. If an administrator sets a password for a user, and then would like for that
user to change the administrator-defined password, the administrator must select the User
must change password at next logon check box. Otherwise, the user will not be able to
change the password until the number of days specified by Minimum password age.
Location
Default Values
The Minimum password length policy setting determines the least number of characters
that can make up a password for a user account. There are many different theories about
determining the best password length for an organization. One possibility is to use pass
phrases rather than passwords. In Microsoft Windows 2000, Windows XP, and Windows
Server 2003, pass phrases can be quite long and they can include spaces. A valid pass
phrase such as “I want to drink a $5 milkshake” is considerably stronger than a ten-
character string of random numbers and letters, yet is easier to remember.
The possible values for this Group Policy setting are:
o A user-defined number of characters from 0 through 14.
o Not defined.
Discussion
There are several types of password attacks that can be performed to obtain the password
for a particular user account. These include dictionary attacks — which attempt to use
common words and phrases — and brute-force attacks, which try every possible
combination of characters. In addition, an attack can be performed by obtaining the
account database and using tools to crack the accounts and passwords.
Set Minimum password length to at least a value of 8. If the number of characters is set
to 0, no password is required. In most environments, an eight-character password is
recommended because it is long enough to provide adequate security and still short
enough for users to easily remember. This value will help to provide adequate defense
against a brute-force attack. Adding complexity requirements will help reduce the
possibility of a dictionary attack. Complexity requirements are discussed in the
description of the Passwords must meet complexity requirements policy setting.
Permitting short passwords reduces security, because short passwords can be easily
broken with tools that perform either dictionary or brute-force attacks against the
passwords. Requiring very long passwords can result in mistyped passwords that might
cause an account lockout and subsequently increase the volume of Help desk calls.
In addition, requiring extremely long passwords can actually decrease the security of an
organization because users might be more likely to write their passwords down to avoid
forgetting them. However, if users are taught they can use pass phrases as described
above, they should be much more likely to remember.
Location
Default Values
The Passwords must meet complexity requirements policy setting determines whether
passwords must meet a series of guidelines that are considered important for a strong
password. Enabling this policy setting requires passwords to meet the following
requirements:
The password is at least six characters long.
The password contains characters from three of the following four categories:
English uppercase characters (from A through Z)
English lowercase characters (from a through z)
Base 10 digits (from 0 through 9)
Non-alphanumeric characters (for example: $, #, or %)
The password does not contain three or more characters from the user’s account name. If
the account name is less than three characters long, this check is not performed because
the rate at which passwords would be rejected would be too high. When checking against
the user’s full name, several characters are treated as delimiters that separate the name
into individual tokens: commas, periods, dashes, hyphens, underscores, spaces, number
signs (#), and tab characters. Each token that is three or more characters long is searched
for in the password, and if it is present, the password change is rejected. For example, the
name “Erin M. Hagens” would be split into three tokens: “Erin,” “M,” and “Hagens.”
Because the second token is only one character long, it would be ignored. Therefore this
user could not have a password that included either “erin” or “hagens” as a substring
anywhere in the password. None of these checks are case-sensitive.
These complexity requirements are enforced when passwords are changed or new
passwords created.
The rules that are included in the Windows Server 2003 password complexity
requirements are part of Passfilt.dll and cannot be directly modified. The possible values
for this Group Policy setting are:
o Enabled.
o Disabled.
o Not defined.
Discussion
Passwords that contain only alphanumeric characters are easy to crack by using publicly
available tools. To prevent this, passwords should contain additional characters and meet
complexity requirements.
Set Passwords must meet complexity requirements to Enabled. This policy setting,
combined with a minimum password length of 8, ensures that there are at least
218,340,105,584,896 different possibilities for a single password. This makes the use of a
brute-force attack difficult, but still not impossible. An attacker who had enough
processing power to test 1 million passwords per second could determine such a
password in about seven-and-a-half days or less.
Enabling the default Passfilt.dll may cause some additional Help desk calls for locked-out
accounts because users might not be used to having passwords that contain characters
other than those found in the alphabet. However, this policy setting is liberal enough that
all users should be able to abide by the requirements with a minor learning curve.
Additional settings that can be included in a custom Passfilt.dll are the use of non–upper-
row characters. Upper-row characters are those that are typed by holding down the
SHIFT key and typing any of the digits from 1 through 10.
Also, the use of ALT key character combinations can greatly enhance the complexity of a
password. However, requiring all users in an organization to adhere to such stringent
password requirements can result in unhappy users and an extremely busy Help desk.
Consider implementing a requirement in your organization to use ALT characters in the
range from 0128 through 0159 as part of all administrator passwords. (ALT characters
outside of this range can represent standard alphanumeric characters that do not add
additional complexity to the password.)
Location
Default Values
Store password using reversible encryption for all users in the domain
The Store password using reversible encryption for all users in the domain policy
setting determines whether Windows Server 2003, Windows 2000, and Windows XP
Professional store passwords by using reversible encryption.
This policy setting provides support for applications that use protocols that require
knowledge of the user’s password for authentication purposes.
By definition, storing encrypted passwords in a way that is reversible means that the
encrypted passwords can be decrypted. A knowledgeable attacker who is able to break
this encryption can then log on to network resources by using the compromised account.
For this reason, never enable Store password using reversible encryption for all users
in the domain unless application requirements outweigh the need to protect password
information.
If you use Challenge Handshake Authentication Protocol (CHAP) authentication through
remote access or Internet Authentication Service (IAS) services, you must enable this
policy setting. CHAP is an authentication protocol used by Microsoft remote access and
Network Connections. Digest Authentication in Internet Information Services (IIS) also
requires that you enable this policy setting.
The possible values for this Group Policy setting are:
Enabled.
Disabled.
Not defined.
Discussion
This policy setting determines whether Windows Server 2003 will store passwords in a
weaker format that is much more susceptible to brute force attacks.
It is advisable to set the value for Store password using reversible encryption for all
users in the domain to Disabled. If you use either Digest Authentication in IIS or the
CHAP authentication protocol through remote access or IAS, you must set this value to
Enabled. This is an extremely dangerous policy setting to apply by using Group Policy
on a user-by-user basis, because it requires opening the appropriate user account object in
Active Directory Users and Computers.
Note
Never enable this policy setting unless business requirements outweigh the need to
protect password information.
Location
Default Values
The Account lockout duration policy setting determines the number of minutes a
locked-out account remains locked out before automatically becoming unlocked. The
available range is from 1 through 99,999 minutes. A value of 0 specifies that the account
will be locked out until an administrator explicitly unlocks it. If Account lockout
threshold is set to a number greater than zero, Account lockout duration must be
greater than or equal to the value of Reset account lockout counter after.
The possible values for this Group Policy setting are:
o A user-defined number of minutes from 0 through 99,999.
o Not defined.
Discussion
A denial-of-service attack can occur if an attacker abuses the Account lockout threshold
and repeatedly attempts to log on to an account. If the Account lockout threshold is
configured, after the specified number of failed attempts the account will be locked out. If
the Account lockout duration is set to 0, the account will remain locked out until an
administrator unlocks it manually.
Location
Default Values
The Account lockout threshold policy setting determines the number of failed logon
attempts that will cause a user account to be locked out. A locked-out account cannot be
used until it is reset by an administrator or until the number of minutes specified by
Account lockout duration expires. You can set a value from 1 through 999 failed logon
attempts, or you can specify that the account will never be locked out by setting the value
to 0. If Account lockout threshold is set to a number greater than zero, Account lockout
duration must be greater than or equal to the value of Reset account lockout counter
after.
Failed password attempts on workstations or member servers that have been locked by
using either CTRL+ALT+DELETE or password-protected screen savers do not count as
failed logon attempts unless Interactive logon: Require Domain Controller
authentication to unlock workstation is set to Enabled. If Interactive logon: Require
Domain Controller authentication to unlock workstation is enabled, repeated failed
password attempts to unlock the workstation will count against the account lockout
threshold.
The possible values for this Group Policy setting are:
A user-defined number from 0 through 999.
Not defined.
Discussion
Brute force password attacks can be automated to try thousands or even millions of
password combinations for any or all user accounts. Limiting the number of failed logons
that can be performed nearly eliminates the effectiveness of such attacks.
Because it will not prevent a brute force attack, a value of 0 should only be chosen if both
of the following criteria are explicitly met:
Password Policy settings force all users to have complex passwords made up of eight or
more characters.
A robust auditing mechanism is in place to alert administrators when a series of failed
logons are occurring in the environment.
If these criteria cannot be met, set Account lockout threshold to a high enough value
that users can accidentally mistype their password several times before they are locked
out of their account, but ensure that a brute-force password attack would still lock out the
account. It is advisable to specify a value of 50 invalid logon attempts. Keep in mind,
however, that although this setting can reduce the number of Help desk calls by reducing
the number of user lockouts, it cannot prevent a denial-of-service attack.
Setting Account lockout threshold to a number greater than zero locks out user accounts until
they are reset by an administrator, or until the number of minutes specified in Account
lockout duration expires. This setting will likely generate a number of additional Help
desk calls. In fact, in many organizations, locked accounts generate the most calls to the
Help desk.
By setting Account lockout threshold to 0, you leave your organization open to the
possibility that you will not detect a brute force attack.
Location
Default Values
The Reset account lockout counter after policy setting determines the number of
minutes that must elapse from the time a user fails to log on before the failed logon
attempt counter is reset to 0 bad logon attempts. If Account lockout threshold is set to a
number greater than zero, this reset time must be less than or equal to the value of
Account lockout duration.
The possible values for this Group Policy setting are:
A user-defined number of minutes from 1 through 99,999.
Not defined.
Discussion
A disadvantage to setting this too high is that users lock themselves out for an
inconveniently long period, if they exceed the account lockout threshold through login
errors. Users may make excessive help desk calls.
Location
Default Values
Kerberos Policy
In Windows Server 2003, the Kerberos version 5 authentication protocols provides the
default mechanism for authentication services and the authorization data necessary for a
user to access a resource and perform a task on that resource. By reducing the lifetime of
Kerberos tickets, you reduce the risk of a legitimate user’s credentials’ being stolen and
successfully used by an attacker; however, you increase authorization overhead. In most
environments, these settings should not need to be changed. In a default installation of a
Windows 2000 or Windows Server 2003 Active Directory domain, the default values of
these policy settings, which are applied at the domain level, are configured in the Default
Domain Policy Group Policy object (GPO).
The Kerberos Policy settings can be configured in the following location in Group Policy
Object Editor:
Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos
Policy\
The Enforce user logon restrictions policy setting determines whether the Kerberos V5
Key Distribution Center (KDC) validates every request for a session ticket against the
user rights policy of the user account. Validating each request for a session ticket is
optional because the extra step takes time, and that can slow network access to services.
The possible values for this Group Policy setting are:
Enabled.
Disabled.
Not defined.
Discussion
If this policy setting is disabled, users might be granted session tickets for services they
do not have the right to use.
It is advisable to set Enforce user logon restrictions to Enabled.
Location
Default Values
The Maximum lifetime for service ticket policy setting determines the maximum
number of minutes that a granted session ticket can be used to access a particular service.
The value must be 10 minutes or greater, and it must be less than or equal to the value of
the Maximum lifetime for user ticket policy setting.
The possible values for this Group Policy setting are:
A user-defined number of minutes from 10 through 99,999, or 0, in which case
service tickets do not expire.
Not defined.
Discussion
If a client presents an expired session ticket when it requests a connection to a server, the
server returns an error message. The client must request a new session ticket from the
Kerberos V5 KDC. After a connection is authenticated, however, it no longer matters
whether the session ticket remains valid. Session tickets are used only to authenticate new
connections with servers. Ongoing operations are not interrupted if the session ticket that
authenticated the connection expires during the connection.
If the value for this policy setting is too high, users might be able to access network
resources outside of their logon hours, or users whose accounts have been disabled might
be able to continue accessing network services by using valid service tickets that were
issued before their account was disabled. If the value is set to 0, service tickets never
expire.
It is advisable to set Maximum lifetime for service ticket to 600 minutes.
Location
Default Values
The Maximum lifetime for user ticket policy setting determines the maximum amount
of time (in hours) that a user’s ticket-granting ticket can be used. When a user’s ticket-
granting ticket expires, a new one must be requested or the existing one must be renewed.
The possible values for this Group Policy setting are:
A user-defined number of hours from 0 through 99,999.
Not defined.
Discussion
If the value for this policy setting is too high, users might be able to access network
resources outside of their logon hours, or users whose accounts have been disabled might
be able to continue to access network services by using valid service tickets that were
issued before their account was disabled. If the value is set to 0, ticket-granting tickets
never expire.
Location
Default Values
The Maximum lifetime for user ticket renewal policy setting determines the period of
time (in days) during which a user’s ticket-granting ticket can be renewed.
The possible values for this Group Policy setting are:
A user-defined number of days from 0 through 99,999.
Not defined.
Discussion
If the value for this policy setting is too high, users may be able to renew very old user
ticket-granting tickets. If the value is 0, ticket-granting tickets never expire.
It is advisable to set Maximum lifetime for user ticket renewal to 7 days.
Location
Default Values
Discussion
To prevent replay attacks, Kerberos V5 uses time stamps as part of its protocol definition.
For time stamps to work properly, the clocks of the client and the domain controller need
to be synchronized as closely as possible. Because the clocks of two computers are often
out of sync, administrators can use this policy setting to establish the maximum
acceptable difference to Kerberos V5 between a client clock and domain controller clock.
If the difference between a client clock and the domain controller clock is less than
Maximum tolerance for computer clock synchronization, any time stamp that is used
in a session between the two computers is considered authentic.
It is advisable to set Maximum tolerance for computer clock synchronization to a
value of 5minutes.
Location
Default Values