Microsoft solutions for Seuurity -Part2 --- Configuring the Domain

Configuring the Domain Infrastructure

Overview
This chapter uses the construction of a domain environment to demonstrate how to
secure an infrastructure for Microsoft® Windows Server™ 2003.
The chapter first focuses on security settings and countermeasures at the domain level.
This includes a high level description of the Microsoft Active Directory® design, the
organizational unit (OU) design, Group Policy design, and administrative group design.
This chapter also explains how to secure a Windows Server 2003 domain environment
for the Legacy, Enterprise, and High Security environments outlined in Chapter 1,
"Introduction to Securing Windows Server 2003." This information lays the groundwork
and provides a vision for evolving from a Legacy environment toward a High Security
environment within a domain infrastructure.
Windows Server 2003 ships with default setting values set to a secure state. To improve
the usability of this material, this chapter only discusses those settings that have been
modified from the default values. For information on all default settings, see the
companion guide, "Threats and Countermeasures: Security Settings in Windows Server
2003 and Windows XP.”
Active Directory Design
Detailed information on designing an Active Directory structure could fill an entire book by
itself. Active Directory enables applications to find, use, and manage directory resources
in a distributed computing environment. This section briefly discusses these concepts to
establish a frame of reference for the rest of the chapter.
When creating an Active Directory architecture you must carefully consider the
environment's security boundaries. Adequately planning an organization's security
delegation and implementation schedule will result in a much more secure Active
Directory design for the organization. Then, only major changes to the environment, such
as an acquisition or organizational restructuring will require restructuring.
If your organization already has an Active Directory design, this chapter may provide
insight into some of its benefits or potential issues from a security perspective.
16
Establishing Windows Server 2003 Directory Boundaries
There are several different types of boundaries within Active Directory. These boundaries
define the forest, the domain, the site topology, and permission delegation.
These boundaries are automatically established during Active Directory installation, but
you must ensure that permission boundaries incorporate organizational requirements and
policies. Administrative permissions delegation can be quite flexible depending on an
organization's requirements. For instance, to maintain a proper balance between security
and administrative functionality, you can break the permission delegation boundaries
down further into security boundaries and administrative boundaries.
Security Boundaries
Security boundaries help define the autonomy or isolation of different groups within an
organization. It is difficult to balance the tradeoffs between ensuring adequate security —
based on how the corporation's business boundaries are established — and the need to
continue providing a solid level of base functionality.
To successfully achieve this balance, you must weigh the threats to your organization
against the security implications of delegating administration permissions and other
choices regarding your environment's network architecture.
Forest vs. Domain Security Boundaries
The forest is the true security boundary. This guide recommends creating separate
forests to keep your environment secure from rogue administrators as opposed to
creating separate domains to provide security and isolation from rogue administrators
and other potential threats.
A domain is the management boundary of Active Directory. With an organization of well –
meaning individuals, the domain boundary will provide autonomous management of
services and data within each domain of the organization.
Unfortunately, when discussing security, this is not so simple to achieve. A domain, for
example, will not completely isolate an attack from a rogue domain administrator. This
level of separation can only be achieved at the forest level.
Because of this, your organization may need to consider dividing the administrative
control of services and data within the current Active Directory design. Active Directory
design requires fully understanding your organization's requirements for service
autonomy and service isolation, as well as for data autonomy and data isolation.
Administrative Boundaries
Because of the potential need to segment services and data, you must define the
different administration levels required. In addition to administrators who may perform
unique services for your organization, the following types of administrators are
recommended.
Service Administrators
Active Directory service administrators are responsible for the configuring and delivering
the directory service. For example, service administrators maintain domain controller
servers, control directory – wide configuration settings, and are responsible for ensuring
service availability. The Active Directory administrators in your organization should be
considered your service administrators.
17
In many cases, the Active Directory service configuration is determined by attribute
values. These attribute values correspond to settings for their respective objects stored
in the directory. Consequently, service administrators in Active Directory are also data
administrators. Depending on your organizational needs, here are some other service
administrator groups you may need to include in your Active Directory service design:
? A domain administration group that is primarily responsible for directory services.
The forest administrator is responsible for choosing the group to administer each
domain. Because of the high–level access granted to the administrator for each
domain, these administrators should be highly trusted individuals. The group
performing domain administration controls the domains through the Domain Admins
group and other built–in groups.
? Groups of administrators who are responsible for Domain Name System (DNS)
management.
The DNS administrator group is responsible for completing the DNS design and
managing the DNS infrastructure. The DNS administrator manages the DNS
infrastructure through the DNS Admins group.
? Groups of administrators that are responsible for OU management.
The OU administrator designates a group or individual as a manager for each OU.
Each OU administrator is responsible for managing the data stored within the
assigned Active Directory OU. These groups can control how administration is
delegated, and how policy is applied to objects within their OUs. In addition, OU
administrators can also create new subtrees and delegate administration of the OUs
they are responsible for.
? Groups of administrators that are responsible for infrastructure server
management.
The group responsible for infrastructure server administration is responsible for
managing the Microsoft Windows® Internet Name Service (WINS), Dynamic Host
Configuration Protocol (DHCP), and potentially the DNS infrastructure. In some
cases, the group handling domain management will manage the DNS infrastructure
because Active Directory is integrated with DNS and is stored and managed on the
domain controllers.
Data Administrators
Active Directory data administrators are responsible for managing data stored in Active
Directory or on computers joined to Active Directory. These administrators have no
control over the configuration or delivery of the directory service. Data administrators are
members of a security group created by your organization. Sometimes the default
security groups in Windows do not make sense for all situations in the organization.
Therefore, organizations can develop their own security group naming standards and
meanings to best fit their environment. Some of the data administrators' daily tasks
include:
? Controlling a subset of objects in the directory. Through inheritable attribute – level
access control, data administrators can be granted control of very specific sections
of the directory, but have no control over the configuration of the service itself.
? Managing member computers in the directory and the data that is on those
computers.
Note: In many cases, attribute values for objects stored in the directory determine the
directory's service configuration.
18
To summarize, allowing the owners of Active Directory service and directory structures to
join a forest or domain infrastructure requires that the organization must trust all service
administrators in the forest and all domains. In addition, enterprise security programs
must develop standard policies and procedures which provide proper background
screening for the administrators. In the context of this security guide, to trust service
administrators means to:
? Reasonably believe that service administrators will look out for the organization's
best interests. Organizations should not elect to join a forest or domain if the
owners of the forest or domain might have legitimate reasons to act maliciously
against the organization.
? Reasonably believe that service administrators will follow best practices and
restrict physical access to the domain controllers.
? Understand and accept the risks to the organization that include the possibility for:
? Rogue administrators —Trusted administrators might become rogue
administrators, and thus abuse the power they have with the system. If you
have a rogue administrator within a forest, it would be easy for that
administrator to look up the security identifier (SID) for another administrator
from another domain. The rogue administrator could then use an application
programming interface (API) tool, disk editor, or debugger to add the stolen
SID to the SID History list of an account within his own domain. With the stolen
SID added to the user's SID History, along with his own domain the rogue
administrator would have administrative privileges in the stolen SID's domain.
? Coerced administrators — A trusted administrator might be coerced or
compelled to perform operations that breach the security of the system. A user
or administrator may use social engineering techniques on legitimate
administrators of a computer system in order to gain the usernames and
passwords he needs to gain access to the system.
Some organizations might accept the risk of a security breach by a rogue or a coerced
service administrator from another part of the organization. Such organizations might
determine that the collaborative and cost – saving benefit of participating in a shared
infrastructure outweighs this risk. However, other organizations might not accept the risk
because the potential consequences of a security breach are too severe.
OU Structure to Facilitate Group Policy Management and Delegation
While this guide is not about Active Directory design, some design information is
necessary to provide insight into the using Group Policy to securely administer your
organization's domains, domain controllers, and specific server roles.
While OUs offer an easy way to group users and other security principals, they also
provide an effective mechanism to segment administrative boundaries.
In addition, using OUs to provide different Group Policy objects (GPOs) based on server
role is an integral piece of the overall security architecture for the organization.
Delegating Administration and Applying Group Policy
An OU is simply a container within a domain. You can delegate control over an OU to a
group or individual by setting specific access control lists (ACLs) on each of these
containers.
19
Often, you can use an OU to provide administrative capabilities similar to those in
Microsoft Windows NT® 4.0 resource domains. You can also create an OU to contain a
group of resource servers to be administered by other users. This gives this group of
other users autonomous control over a particular OU, without isolating them from the
remainder of the domain.
Administrators that delegate control over specific OUs are likely to be service
administrators. At a lower level of authority, users that control the OUs are usually data
administrators.

Baseline Sever Role Organizational Units

The previous example for managing an organization's infrastructure servers can be
extended to encompass other servers and services in a corporate infrastructure. The goal
is to create a seamless Group Policy that covers all servers, while ensuring that the
servers residing within Active Directory meet the security standards for your environment.
This type of Group Policy covering all servers in your environment forms a consistent
baseline for standard settings across all of the servers in your enterprise. In addition, the
OU structure and the application of Group Policies must provide a granular design to
provide security settings for specific types of servers in an organization. For example,
Internet Information Server (IIS), File, Print, Internet Authentication Server (IAS), and
Certificate Services, illustrate a few of the server roles in an organization that may require
unique group policies.
Member Server Baseline Policy
The first step in establishing server role OUs is to create a baseline policy. To do this,
create a baseline security template and imported it into the Group Policy. The Enterprise
Client – Member Server Baseline.inf files are included with this security guide to provide
this functionality and guidance. The Enterprise Client is a reference to the different middle
level of security based on the organization's compatibility requirements discussed in
Chapter 1,"Introduction to the Windows Server 2003 Security Guide."
Link this GPO security template to the Member Servers OU. The Enterprise Client –
Member Server Baseline.inf security template will apply the settings of the baseline
Group Policy to any servers in the Member Servers OU, as well as any servers in child
OUs. For simplicity, the remaining examples in this chapter use the Enterprise Client
security level. The Member Server Baseline Policy is discussed in Chapter 3, "Creating a
Member Server Baseline."
The baseline Group Policy should define the desired settings for all servers across an
organization. Make the baseline Group Policy as restrictive as possible, and segment any
servers that need to differ from this policy into separate server – specific OUs.
Server Role Types and Organizational Units
Continuing the example above, create a separate policy for the incremental changes to
the infrastructure server policies. Put the necessary setting into a security template called
Enterprise Client – Infrastructure Server.inf, to ensure that the infrastructure services
function and are accessible over the network.
26
Link this GPO infrastructure template to the Infrastructure OU. Finally, use the Restricted
Groups setting to add the following three groups to the Local Administrators group in the
"Enterprise Client: Infrastructure Server Policy": Domain Administrators, Enterprise
Administrators, and Infrastructure Administrators.
This process is shown in the illustration below.
Figure 2.3
Configuring incremental group policies
As mentioned before, this is only one of many possible ways to create an OU structure
for deploying GPOs. For more information on creating OUs for Group Policy
implementation, see the Microsoft TechNet article, "How to Deploy Active Directory" at:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/AD/
windows2000/deploy/depovg/add.asp.
This security guide defines several server roles. The following table contains templates
created to increase security for these roles when following the above process.
27
Table 2.1: Windows Server 2003 Roles
Server Role Description Security Template
Windows Server 2003
Domain Controllers
A group containing Active
Directory domain controllers.
Enterprise Client – Domain
Controller.inf
Windows Server 2003
Member servers
All servers that are members of
the domain and reside in or below
the member server OU.
Enterprise Client – Member
Server Baseline.inf
Windows Server 2003 File
servers
A group containing locked down
file servers.
Enterprise Client – File
Server.inf
Windows Server 2003 Print
servers
A group containing locked down
print servers.
Enterprise Client – Print
Server.inf
Windows Server 2003
Infrastructure servers
A group containing locked down
DNS, WINS, and DHCP servers.
Enterprise Client –
Infrastructure Server.inf
Windows Server 2003 IAS
servers
A group containing locked down
IAS Servers.
Enterprise Client – IAS
Server.inf
Windows Server 2003
Certificate Services servers
A group containing locked down
Certificate Authority (CA) Servers.
Enterprise Client – CA
Server.inf
Windows Server 2003
Bastion Hosts
A group containing Internet facing
servers.
High Security– Bastion
Host.inf
Windows Server 2003 IIS
servers
A group containing locked down
IIS Servers.
Enterprise Client – IIS
Server.inf
All incremental template files are expected to be applied to OUs below the member
servers OU. For this reason, each of these lower level OUs require that you apply both
the Enterprise Client – Member Server Baseline.inf file and the specific incremental file to
them to define the role each will fulfill in the organization.
The security requirements for each of these server roles are different. Appropriate
security settings for each role are discussed in detail in later chapters.
Important: This guide assumes that computers running Windows Server 2003 will
perform specifically defined roles. If the servers in your organization do not match
these roles, or you have multipurpose servers, use the settings defined here as
guidelines for creating your own security templates. However, bear in mind that the
more functions each of your servers perform, the more vulnerable they are to attack.
28
The final OU design to support these defined server roles is shown in the illustration
below.
Figure 2.4
Example of OU design
29
OU, GPO, and Administrative Group Design
The recommended OUs and group policies discussed above create a baseline or new
environment to restructure a company's existing OU structure for computers running
Windows Server 2003. In addition, the administrators use their predefined administration
boundaries to create their respective administrative groups. The correlation of these
groups to the OUs they manage is shown in the following table.
Table 2.2: OUs and Administrative Groups
OU Name Administrative Group
Domain Controllers Domain Engineering
Member Servers Domain Engineering
Infrastructure Operations
File Operations
Print Operations
IAS Domain Engineering
CA Enterprise Admins
Web Web Services
Each administrative group has been created within the environment as a Global Group
within the child domain.
Domain Engineering has added each of these administrative groups to the appropriate
restricted group by using the corresponding GPO. The administrative groups created
above will only be members of the Local Administrators group for the computers located
in the OUs that specifically contain computers related to their job functions.
Finally, the domain engineers set permissions on each GPO so that only administrators
in the domain engineering group are able to edit them.
By default, the new OU structure inherits many security settings from its parent container.
For each OU, clear the check box for Allow inheritable permissions from parent to
propagate to this object and all child objects.
? To clear the Allow Inheritable Permissions option
1. Open Active Directory Users and Computers.
2. Select the Advanced view by clicking View, and then clicking Advanced
Features.
3. Right – click the appropriate OU, and then click Properties.
4. Click the Security tab, and then click Advanced.
5. Clear the Allow inheritable permissions from parent to propagate to this
object and all child objects. Include these with entries specifically defined
here checkbox.
Remove any unnecessary groups previously added by administrators, and add the
domain group that corresponds to each server role OU. Retain the Full Control setting
for the Domain Administrators group.
30
You do not have to perform the tasks to establish these OUs in a particular order, but
there are some obvious dependencies. For example, the domain groups must exist
before you can delegate control of different OUs to them. The following list defines a
suggested order for implementing these tasks:
1. Create the OU structure.
2. Move the computers to the appropriate OUs.
3. Create the administrative groups.
4. Add the appropriate domain accounts to the administrative groups.
5. Delegate administration for each OU to the appropriate domain groups.
6. Create the group policies in the OU where they will be applied.
7. Link each Group Policy to any additional OUs as necessary.
8. Import the appropriate security template to each GPO.
9. Set permissions on each GPO so that the appropriate domain groups have control
over them.
10. Add the appropriate domain groups to Restricted Groups for each GPO.
11. Test and refine the group policies.

Password must meet complexity requirements

Table 2.7: Settings
Domain Member Default Legacy Client Enterprise Client High Security

Enabled Enabled Enabled Enabled
The Password must meet complexity requirements policy option checks all new
passwords to ensure that they meet basic requirements for strong passwords.
Complexity requirements are enforced when passwords are created. The Windows
Server 2003 policy rules cannot be directly modified. However, you can create a new
version of passfilt.dll to apply a different set of rules. For the source code for passfilt.dll,
see the Microsoft Knowledge Base article 151082: "HOW TO: Password Change Filtering
& Notification in Windows NT."
A password of 20 or more characters can actually be set so that it is easier for a user to
remember — and more secure — than an eight-character password. The following 27 –
character password: I love cheap tacos for $.99, for example. This type of password,
really a pass-phrase, might be simpler for a user to remember than a shorter password
such as P@55w0rd.
37
This recommended value, combined with a Minimum password length set to 8,
includes upper and lowercase letters and numbers in the keyspace, which increases it
from 26 to 62 characters. An eight – character password then has 2.18 x 1014 possible
combinations. At 1,000,000 attempts per second, it would take 6.9 years to cycle through
all possible permutations. Using these settings in conjunction makes it very difficult to
mount a brute force attack. For these reasons, this is the recommendation the three
environments defined in this guide.
Store password using reversible encryption
Table 2.8: Settings
Domain Member Default Legacy Client Enterprise Client High Security
Disabled Disabled Disabled Disabled
The security setting for Store password using reversible encryption determines
whether the operating system stores passwords using reversible encryption or not.
This policy supports applications using protocols requiring the user's password for
authentication purposes. Passwords stored using reversible encryption can be retrieved
more easily than passwords stored without this option, increasing vulnerability. For this
reason, never enable this policy unless application requirements outweigh the need to
protect password information.
Challenge-Handshake Authentication Protocol (CHAP) through remote access or IAS
and Digest Authentication in IIS both require this policy.
How to Prevent Users from Changing a Password Except
When Required
In addition to the password policies above, some organizations require centralized control
over all users. This section describes how to prevent users from changing their
passwords except when they are required to do so.
Centralized control of user passwords is a cornerstone of a well – crafted Windows Server
2003 security scheme. You can use Group Policy to set minimum and maximum
password ages as discussed previously. But bear in mind that requiring frequent
password changes can enable users to circumvent the password – history setting for your
environment. Requirements for passwords that are too long may also lead to more calls
to the help desk due to users forgetting passwords.
Users can change their passwords during the period between the minimum and
maximum password age settings. However, the High Security environment design
requires that users change their passwords only when the operating system prompts
them to after the 42 days, as configured in the Maximum password age setting. To
prevent users from changing their passwords (except when required), you can disable
the Change Password option in the Windows Security dialog box that appears when
you press CTRL+ALT+DELETE.
You can implement this configuration for an entire domain by using a Group Policy, or
implement it for one or more specific users by editing the registry. For more detailed
instructions on this configuration, see the Microsoft Knowledge Base article 324744,
"How To: Prevent Users from Changing a Password Except When Required in Windows
Server 2003," at http://support.microsoft.com/default.aspx?scid=324744.
38
Account Lockout Policy
The Account lockout policy is a Windows Server 2003 security feature that locks a user
account after a number of failed logon attempts occur within a specified time period. The
number of attempts allowed and the time period are based on the values configured for
the security policy lockout settings. A user cannot log on to a locked account. Windows
Server 2003 tracks logon attempts, and the server software can be configured to respond
to this type of potential attack by disabling the account for a preset number of failed
logins.
When configuring the Account lockout policy in Windows Server 2003, an administrator
can set any value for the attempt and time period variables. However, if the value for
Reset account lockout counter after setting is greater than the value for Account
lockout duration setting, Windows Server 2003 automatically adjusts the value of the
Account lockout duration to the same value as Reset account lockout counter after
setting. In addition, if the value of Account lockout duration is lower than the value set
for Reset account lockout counter after, Windows Server 2003 automatically adjusts
the value of the Reset account lockout counter after to the same value of the Account
lockout duration setting. Therefore, if the Account lockout duration is defined, the
Reset account lockout counter after must be less than or equal to the Account
lockout duration.
Windows Server 2003 does this to avoid conflicting setting values in the security policy. If
an administrator configures the Reset account lockout counter after setting to a value
that is greater than the value for the Account lockout duration setting, then
enforcement of the Account lockout duration setting will expire first, thus making it
possible for the user to log back on to the network. However, the Reset account lockout
counter setting would continue to count down. Because of this, the account lockout
threshold would remain at the maximum of three invalid attempts, and the user would not
be able to log on.
To avoid this situation, Windows Server 2003 automatically resets the value for the Reset
account lockout counter after setting to be equal to the value for the Account lockout
duration setting.
These security policy settings help prevent attackers from guessing user passwords, and
they decrease the likelihood of successful attacks on your network environment. The
values in the following sections can be configured in the Domain Group Policy at the
following location:
Computer Configuration\Windows Settings\Security Settings\Account
Policies\Account Lockout Policy
Account Lockout Duration
Table 2.9: Settings
Domain Member Default Legacy Client Enterprise Client High Security
Not Defined 30 minutes 30 minutes 15 minutes
The Account lockout duration setting determines the length of time before an account
is unlocked and a user can try to log on again. The setting does this by specifying the
number of minutes a locked out account will remain unavailable. Setting the value for the
Account lockout duration setting to 0, keeps the accounts locked out until an
administrator unlocks them. The Windows Server 2003 default value for this setting is
Not Defined.
39
While configuring the value for this setting to never automatically unlock may seem like a
good idea, doing so may increase the number of calls the help desk in your organization
receives to unlock accounts that were locked by mistake. Setting the value for this setting
to 30 minutes for the Legacy and Enterprise Client environments and 15 minutes for High
Security level decreases the amount of operation overhead during a denial of service
(DoS) attack. In a DoS attack, the attacker maliciously performs a number of failed logon
attempts on all users in the organization, locking out their accounts. This setting value
also gives locked out users the chance to log on again in 30 minutes, a period of time
they are more likely to accept without resorting to the help desk.
This guide recommends setting the value to 15 minutes in the High Security environment.
Account lockout threshold
Table 2.10: Settings
Domain Member Default Legacy Client Enterprise Client High Security
0 invalid login attempts 50 invalid login
attempts
50 invalid login
attempts
10 invalid login
attempts
The Account lockout threshold setting determines the number of attempts that a user
can make to log on to an account before it is locked.
Authorized users can lock themselves out of an account by incorrectly entering their
password, or by changing their password on one computer while logged on to another
computer. The computer with the incorrect password may continuously try to authenticate
the user, and because the password it is using to authenticate is incorrect, the user
account is eventually locked out. To avoid locking out authorized users, set the account
lockout threshold to a high number.
Because vulnerabilities can exist both for when the value for this setting is configured and
when and it is not, distinct countermeasures for each of these possibilities are defined.
Your organization should weigh the choice between the two based on the identified
threats and the risks you are trying to mitigate.
40
? To prevent account lock outs, set the value for Account lockout threshold setting
to 0. Setting the Account Lockout Threshold setting to 0 helps reduce help desk
calls because users can not accidentally lock themselves out of their accounts and
it will prevent a DoS attack aimed at intentionally locking out accounts in your
organization. Because it will not prevent a brute force attack, choose this setting
only if both of the following criteria are explicitly met:
? The password policy forces 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 account lockouts are occurring in the environment. For example, the
auditing solution should monitor for security event 539 which is, "Logon failure.
The account was locked out at the time the logon attempt was made". This
event means that the account was locked out at the time the logon attempt
threshold was made. However, event 539 only shows an account lockout, not
a failed password attempt. Therefore, your administrators should also monitor
for a series of bad password attempts.
? If these criteria are not met, the second option is to configure the Account lockout
threshold setting to a high enough value to provide users with the ability to
accidentally mistype their password several times without locking themselves out
of their accounts, while ensuring that a brute force password attack will still lock out
the account. In this case, setting the invalid logon attempts to a high number such
as 50 ensures adequate security and acceptable usability. This setting value will
prevent accidental account lockouts and reduce help desk calls, but will not
prevent a DoS attack as mentioned above.
This guide recommends setting the value to 10 invalid login attempts in the High Security
environment.
Reset account lockout counter after
Table 2.11: Settings
Domain Member Default Legacy Client Enterprise Client High Security
Not defined 30 minutes 30 minutes 15 minutes
The Reset account lockout counter after setting determines the length of time before
the Account lockout threshold resets to 0 and the account is unlocked. If you define an
Account lockout threshold, then this reset time must be less than or equal to the value
for the Account lockout duration setting.
In coordination with the other values configured as part of this guide, leaving this setting
at its default value, or configuring the value at an interval that is too long, could make
your environment vulnerable to an account lockout DoS attack. Without a policy to reset
the account lockout, administrators would have to manually unlock all accounts.
Conversely, if there is a reasonable time value for this setting, users would be locked out
for a set period until all of the accounts are unlocked automatically. The recommended
setting value of 30 minutes defines a time period users are more likely to accept without
resorting to the help desk. Leaving this setting at its default only opens you up to an
account lockout DoS if you leave it at defaults but change the other ones in the way we
recommend. Lowering the level decreases the amount of operation overhead during a
denial of service (DoS) attack. In a DoS attack, the attacker maliciously performs a
number of failed logon attempts on all users in the organization, locking out their
accounts.
This guide recommends setting the value to 15 minutes in the High Security environment.
41
Kerberos Policy
Kerberos policies are used for domain user accounts. These policies determine Kerberos
version 5 protocol – related settings, such as ticket lifetimes and enforcement. Kerberos
policies do not exist in the local computer policy. Reducing the lifetime of Kerberos tickets
decreases the risk of an attacker stealing passwords and then impersonating legitimate
user accounts. However, maintaining these policies increases the authorization
overhead. In most environments the default values for these policies should not be
changed. The Kerberos settings are include in the Default Domain Policy and enforced
there, therefore, this guide does not include them in the security templates that
accompany this guide.
This guide does not provide any changes for the default Kerberos policy. For more detail
on these settings, please refer to the companion guide, "Threats and Countermeasures:
Security Settings in Windows Server 2003 and Windows XP.”
42
Security Options
The account policy must be defined in the Default Domain Policy and is enforced by the
domain controllers that make up the domain. A domain controller always obtains the
account policy from the Default Domain Policy GPO, even if there is a different account
policy applied to the OU that contains the domain controller.
There are two policies in Security Options that also behave like account policies and
should be considered at the domain level. You can configure the Domain Group Policy
values in the following table at the following location:
Computer Configuration\Windows Settings\Security Settings\Local
Policies\Security Options
Microsoft network server: Disconnect clients when logon
hours expire
Table 2.12: Settings
Domain Member Default Legacy Client Enterprise Client High Security
Not Defined Enabled Enabled Enabled
The Microsoft network server: Disconnect clients when logon hours expire security
setting determines whether to disconnect users who are connected to the local computer
outside their user account's valid logon hours. This setting affects the server message
block (SMB) component. When this policy is enabled, it causes client sessions with the
SMB service to be forcibly disconnected when the client's logon hours expire. If this
policy is disabled, an established client session is allowed to be maintained after the
client's logon hours have expired. When enabling this setting, you should also enable
Network security: Force logoff when logon hours expire.
If your organization has configured logon hours for users, then it makes sense to enable
this policy, otherwise, users who are assumed to be unable to access network resources
outside of their logon hours may actually be able to continue to use those resources with
sessions that were established during allowed hours.
If logon hours are not used in your organization, enabling this setting will have no impact.
If logon hours are used, then existing user sessions will be forcibly terminated when their
logon hours expire.
Network Access: Allow anonymous SID/NAME translation
Table 2.13: Settings
Domain Member Default Legacy Client Enterprise Client High Security
Not Defined Disabled Disabled Disabled
The Network Access: Allow anonymous SID/NAME translation setting determines if
an anonymous user can request the SID for another user.
43
If this policy is enabled on a domain controller, a user who knows an administrator's SID
attributes could contact a computer that also has this policy enabled and use the SID to
obtain the administrator's name. That person could then use the account name to initiate
a password guessing attack. Disabled is the default setting on member computers;
therefore it will have no impact on them. However, the default setting for domain
controllers is Enabled. Disabling this setting may cause legacy systems to be unable to
communicate with Windows Server 2003 based domains such as:
? Windows NT 4.0 – based Remote Access Service servers.
? When a Web application on IIS is configured to allow Basic authentication and at
the same time has Anonymous access disabled, the built-in Guest user account
cannot access the Web application. Also, if you rename the built-in Guest user
account to another name, the new name cannot be used to access the Web
application.
? Remote Access Service servers running on Windows 2000 – based computers that
are located in Windows NT 3.x domains or Windows NT 4.0 domains.
Network Security: Force Logoff when Logon Hours expire
Table 2.14: Settings
Domain Member Default Legacy Client Enterprise Client High Security
Disabled Enabled Enabled Enabled
The Network Security: Force Logoff when Logon Hours expire setting determines
whether to disconnect users who are connected to a local computer outside their user
account's valid logon hours. This setting affects the SMB component.
Enabling this policy forcibly disconnects client sessions with the SMB server when the
client's logon hours expire and the user will be unable to log on to the system until his or
her next scheduled access time. Disabling this policy maintains an established client
session after the client's logon hours expire. To affect domain accounts, this setting must
be defined in the Default Domain Policy.
44
Summary
There are several design considerations to make when reviewing a forest, domain, and
an Organizational Unit (OU) design to secure an environment.
It is important to research and document any specific autonomy and isolation
requirements for the organization. Political autonomy, operational isolation, and legal or
regulatory isolation are all valid reasons to consider complex forest designs.
Understanding how to control service administrators is important. Malicious service
administrators can present a great risk to an organization. At a lower level, malicious
domain administrators can access data in any domain in the forest.
While it may not be easy to change the forest or domain design in an organization, it may
be necessary to remediate some security risks for the enterprise. Planning the OU
deployment in the organization according to the needs of the service administrators and
the data administrators is also important. This chapter went into detail on creating an OU
model that will support using GPOs for the ongoing management of different server roles
in the enterprise.
Finally, the chapter points out the importance of reviewing all domain – wide settings in
the organization. Only one set of password, account lockout, and Kerberos version 5
authentication protocol policies can be configured for each domain. Other password and
account lockout settings will only affect the local accounts on member servers. Plan to
configure settings that will apply to all member servers of the domain, and ensure that
these provide an adequate level of security across your organization.