Securing Windows 2000 Server
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Chapter 5: Securing the Domain Infrastructure
Note: Welcome to the TechNet Archive. We've created this Archive area so that we can continue to make available older content that is still of interest to some of our users. This allows us to streamline the content offerings on the site and keep it focused on the newest, most relevant content.
In Chapter 4, "Applying the Security Risk Management Discipline," the security risks specific to the scenario at Contoso, Ltd, were identified using the Security Risk Management Discipline (SRMD). The risks identified will be either mitigated or addressed through remedial action in the remaining chapters of this guide.
This chapter focuses on domain level vulnerabilities. Included is a high-level description of the Active Directory® directory service design, the organizational unit (OU) design, and domain policy. In addition, the specific domain policies implemented at Contoso, Ltd., are discussed in detail.
On This Page
Active Directory Design
Detailed information on designing an Active Directory structure could fill an entire book by itself. Active Directory is a Microsoft technology that is part of the Active Platform. It is designed to enable applications to find, use, and manage directory resources in a distributed computing environment. The information provided in this section will touch on a few of these concepts to ensure that a common level of understanding is established for the other related information in this chapter.
One of the most important aspects to consider when creating an Active Directory architecture is the security boundaries that will be imposed on your organization. By taking the time to adequately plan how security will be delegated and implemented in your organization, the final Active Directory design will be much more secure. If properly designed, the Active Directory architecture should not require restructuring unless there are major changes to the business, such as an acquisition or organizational restructuring.
If an Active Directory design has already been implemented in your organization, this chapter may help provide insight into some of the benefits or potential issues with the particular design in your environment from a security perspective.
Establishing Active Directory Boundaries
There are several different types of boundaries within Active Directory. These boundaries can include the forest, the domain, the site topology, and permission delegation.
Many of these boundaries are established when Active Directory is installed. Designing the delegation of permissions in the environment must incorporate organizational requirements and policies to ensure the proper balance of security and administrative functionality. Delegation of administrative permissions can be quite flexible depending on your organization's requirements. Also, the delegation boundaries can be subdivided into security boundaries and administrative boundaries.
Security boundaries help define the autonomy of different groups within an organization. It is difficult to balance the tradeoffs between ensuring adequate security, based on how these boundaries are established, and the need to continue providing a solid level of base functionality.
This balance between security boundaries and functionality can be achieved successfully by fully understanding the threats that create risks to your organization, and then comparing this assessment with the security implications of delegating administration or creating other particular choices in the network architecture of your environment.
Forest as a Security Boundary
When Microsoft Windows® 2000 Server was introduced, a large amount of supporting documentation defined a domain as a security boundary. However, a more recent definition defines the forest as the true security boundary. The truth lies somewhere in between.
A domain is definitely a 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 autonomous management is not so simple to achieve. A domain, for example, will not provide complete isolation of a possible attack by a rogue domain administrator. This level of separation can only be achieved at the forest level.
Therefore, your organization may need to consider dividing the administrative control of services and data within the current design. By fully understanding the needs of your organization for service autonomy and service isolation, as well as data autonomy and data isolation, the Active Directory design for your environment will begin to solidify.
Because of the potential need to segment services and data, the different levels of administration must be defined.
Active Directory service administrators are responsible for the configuration and delivery of the directory service. For example, service administrators maintain domain controller servers, control directory-wide configuration settings, and are responsible for ensuring service availability.
In many cases, the service configuration of Active Directory is determined by attribute values that correspond to settings for their respective objects, which are stored in the directory. Consequently, service administrators in Active Directory are also data administrators. Service administrators may include:
Groups of administrators responsible for forest management
Groups of administrators responsible for domain management
Groups of administrators responsible for DNS management
Groups of administrators responsible for OU management
Groups of administrators responsible for infrastructure server management
Groups that are in charge of forest administration are responsible for the delivery of the directory service to the network. The group providing forest management should always be very highly trusted. The forest administration team controls the forest through the forest root Domain Admins group, the Enterprise Admins group, and the Schema Admins group.
A group providing domain administration 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 assigned to the domain administrator, this person should be a highly trusted individual. The group performing domain administration controls the domain through the Domain Admins group and other built-in groups.
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 DNSAdmins group.
The OU administrator designates a group or individual as a manager for each OU. Each OU administrator is responsible for the management of 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 for which they are responsible.
The group responsible for infrastructure server administration is responsible for managing WINS, 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.
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 include:
Administrators who control a subset of objects in the directory. Through inheritable, attribute-level access control, data administrators can be assigned control of very specific sections of the directory, but they have no control over the configuration of the service itself.
Administrators who manage member computers that are joined to the directory and data that is stored on those computers.
Note In many cases, the service configuration of the directory is determined by the attribute values for objects stored in the directory.
To summarize, the potential consequences of Active Directory service structures, and directory structure owners, for an organization to join a forest or domain infrastructure create a situation in which the organization must choose to trust all service administrators in both the forest and all domains. In this context, 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 associated with rogue administrators and coerced administrators.
Rogue administrators. It is always possible for a trusted administrator to become a rogue administrator and abuse the rights they have on the computer system.
Coerced administrators. A trusted administrator might be coerced or compelled to perform operations that breach the security of the computer 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 Design to Support Security
Although this guide is not focused on Active Directory design, there is some design information that is required to provide insight into the use of Group Policy for secure administration of the domain, domain controllers, and specific server roles.
OUs offer an easy way to group users and other security principals, and they also provide an effective mechanism to segment administrative boundaries.
Additionally, 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.
Delegation of Administration
An OU is simply a container within a domain. Control over an OU can be delegated to a group or individual by setting specific access control lists (ACLs) on each container.
Often, an OU can be used to provide similar administrative capabilities found in Microsoft Windows NT® 4.0 resource domains. An OU also can be created to contain a group of resource servers to be administered by other users. Although this group of other users may have autonomous control over this particular OU, they are not isolated from the remainder of the domain.
Administrators who delegate control over specific OUs are likely to be service administrators. At a lower level of authority, users who control the OUs are usually data administrators.
The creation of administration groups provides administrators a way to segment groups of users, groups, or servers into containers for autonomous administration.
For example, consider the infrastructure servers that reside in a domain. Infrastructure servers include all of the nondomain controllers that are running basic network services, including servers running DNS, WINS, or DHCP services.
Often, these servers are maintained by an operations group or an infrastructure administration group. An OU can be used to easily provide administrative capabilities to these servers.
The first step is to create an OU called Infrastructure Servers. All DNS, WINS, or DHCP servers can be moved into this OU. A global security group called Infrastructure Admins can be created with the appropriate domain accounts added to it. Finally, the Delegation of Control Wizard should be run to give the Infrastructure Admins group the setting Full Control of the OU. The following figure provides a high-level view of such an OU.
This configuration is only one of many ways that OUs can be used to provide administrative segmentation. If your organization is more complex, refer to additional guidance referenced at the end of this chapter.
After following this procedure, the Infrastructure Admin group should have full control over the Infrastructure Servers OU and all servers and objects within this OU. After they have this control they are prepared for the next phase: securing the server roles with Group Policy.
Group Policy Application
Group Policy can be used in conjunction with the delegation of administration to ensure that specific settings, rights, and behavior are applied to all servers within an OU. By using Group Policy rather than manual steps, it is simple to update a number of servers with any additional changes required in the future.
Group Policy is accumulated and applied in the order shown in the following figure.
As shown in this figure, policies are applied first from the local policy of the computer. After that, any GPOs are applied at the site level, and then at the domain level. If the server is nested in several OUs, any GPOs that exist at the highest-level OU are applied first. The process of applying GPOs continues down the OU hierarchy. The final GPO to be applied will be the one at the local OU where the server object is located.
A few considerations need to be kept in mind with this model.
If multiple GPOs are defined at any of the Group Policy levels, an administrator will configure the order in which they are applied. If the same option is specified in multiple policies, the last one applied will have precedence.
A Group Policy can be configured with the No Override option. By selecting this option, other GPOs cannot override settings configured as part of this policy.
Group Policy templates are text-based files. Changes to these files can be made using the Security Templates snap-in to the Microsoft Management Console (MMC) or by using a text editor such as Notepad. Some sections of the template files contain specific ACLs that are defined by the Security Descriptor Definition Language (SDDL). More information on editing security templates and SDDL can be found on MSDN, at http://msdn2.microsoft.com.
It is very important that the security templates used for production are stored in a secure location in your environment that can be accessed only by the administrators responsible for implementing Group Policy. By default, security templates are stored in the %SystemRoot%\security\templates folder on all Windows 2000 computers.
This folder is not replicated across multiple domain controllers. Therefore, you will need to select a domain controller to hold the master copy of the security templates so that you do not encounter version control problems with the templates. This approach ensures that you always are modifying the same copy of the templates.
It is very important that system time is accurate and that all servers are using the same time source. The Windows 2000 W32Time service provides time synchronization for Windows 2000 and Windows XP–based computers running in an Active Directory domain.
The W32Time service ensures that the client clocks of Windows 2000–based computers are synchronized with the domain controllers in a domain. This synchronization is necessary for the Kerberos version 5 authentication protocol to work properly. Time synchronization also assists in event log analysis.
Kerberos is a network authentication protocol developed by MIT. Kerberos authenticates the identity of users attempting to log on to a network and encrypts their communications through secret-key cryptography.
The W32Time service synchronizes clocks using the Simple Network Time Protocol (SNTP) as described in RFC 1769 at http://rfc.net/rfc1769.html. In a Windows 2000 Server forest, time is synchronized in the following manner:
The primary domain controller (PDC) emulator operations master in the forest root domain is the authoritative time source for the organization.
All PDC operation masters in other domains in the forest follow the hierarchy of domains when selecting a PDC emulator with which to synchronize their time.
All domain controllers in a domain synchronize their time with the PDC emulator operations master in their domain as their in-bound time partner.
All member servers and client desktop computers use the authenticating domain controller as their in-bound time partner.
To ensure that the time is accurate, the PDC emulator in the forest root domain can be synchronized to an external SNTP time server. However, doing so may result in a requirement to open ports on the firewall. Before opening firewall ports, the benefits should be weighed against the potential security risk of making these configuration changes.
In many cases, it may not be a necessity to have all servers synchronized with an outside time source, as long as they are synchronized with the same time source inside the organizations network.
If your network runs Microsoft Windows 95 or Windows 98 operating systems on its computers, the clocks on those computers should be synchronized using the following command in a logon script, where <timecomputer> is a domain controller on the network:
net time \\<timecomputer> /set /yes
By running this command, you can prevent these computers from having any time difference in their clocks from others in the rest of the domain.
Note Network computers running operating systems other than Windows should also synchronize their clocks to the PDC emulator of the Windows 2000 domain to allow logging events to be analyzed, based on the same time.
Server Role Organizational Units
The example used previously for the management of the infrastructure servers in your organization can be extended to the scenario for Contoso as well. 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.
The first step in this process is to create a new domain level policy, because the Windows 2000 default domain policy should be additionally secured. The administrator should create a new policy and link it to the domain GPO. To ensure that this new policy has precedence over the default policy, it should be moved to provide it with the highest priority of the GPO links.
The default policy could be modified directly to create a new security configuration, but the advantage of creating a new policy is that if there are problems with it, the new policy can be easily disabled, leaving the default domain policy in place to resume control.
The second step is to create a baseline policy. To create such a policy, a baseline security template should be created and imported into the policy. The MSS Baseline.inf is included with this solution to provide this functionality. This GPO security template should be linked to the Member Servers OU. The MSS Baseline.inf security template will apply the settings of the baseline policy to any servers in the Member Servers OU, as well as any servers in child OUs.
The baseline policy should configure the desired settings for all servers across your organization. The baseline policy also should be as restrictive as possible, and any servers that need to differ from this policy should be segmented into separate server-specific OUs, such as the Infrastructure Servers OU.
Server Role Organizational Units
Continuing with the example, a separate policy for the incremental changes to the infrastructure server policies should be created. A security template called MSS Infrastructure Role.inf could contain the settings necessary to ensure that the infrastructure services function and are accessible over the network.
This GPO infrastructure template should be linked to the Infrastructure OU. Finally, the Restricted Groups setting should be used to add the following three groups to the Local Administrators group in the Infrastructure Policy GPO: Domain Administrators, Enterprise Administrators, and Infrastructure Administrators.
This process is shown in the following figure.
As mentioned earlier, this figure displays only one of many possible ways to create an OU structure for the deployment of GPOs. For more information on the creation of OUs for the implementation of Group Policy, see the Microsoft TechNet article "Best Practice Active Directory Deployment for Managing Windows Networks," at: www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/
In this guide, several server roles are defined. The security templates in the following table have been created in accordance with the described process to increase security for these roles.
Table 5.1 Windows 2000 Server Roles
Windows 2000 Domain Controllers
A group containing Active Directory domain controllers
Windows 2000 Member Servers
All servers that are members of the domain and reside in or below the Member Server OU
Windows 2000 File and Print Servers
A group containing locked-down file and print servers
MSS FilePrint Role.inf
Windows 2000 Infrastructure Servers
A group containing locked-down DNS, WINS, and DHCP servers
MSS Infrastructure Role.inf
Windows 2000 IIS Servers
A group containing locked down IIS Servers
MSS IIS Role.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 both the MSS Baseline.inf and the specific incremental file to be applied to them to define the role each will fulfill in the organization.
The security requirements for each of these roles are different. Appropriate security settings for each role are discussed in detail in Chapter 7, "Hardening Specific Server Roles."
Important This guide assumes that Windows 2000 servers will perform specifically defined roles. If the servers in your organization do not match these roles, or if 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 performs, the more vulnerable it is to attack.
The final OU design to support these defined server roles is shown in the following figure.
Contoso OU, GPO, and Administrative Group Design
The preceding recommendations are applied to Contoso to restructure the company's existing OU structure for Windows 2000 servers. Additionally, the Contoso administrators use their predefined administration boundaries to create their administrative groups. The correlation of these groups to the OUs they manage is shown in the following table.
Table 5.2 Contoso OUs and Administrative Groups
File and Print
Each administrative group has been created at Contoso as a Global Group within the child domain of Northamerica.
Contoso has added each of these administrative groups to the appropriate restricted group by using the corresponding GPO for each restricted group. The administrative groups that were created 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, Contoso configured 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. The check box for Allow inheritable permissions from parent to propagate to this object should be cleared for each OU. Any unnecessary groups that may have been previously added by administrators should be removed, and the domain group that corresponds to each server role OU should be added. The Domain Administrators group should retain the setting Full Control.
The tasks required to establish these OUs do not have to be performed 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:
Create the OU structure.
Move the computers to the appropriate OUs.
Create the administrative groups.
Add the appropriate domain accounts to the administrative groups.
Delegate administration for each OU to the appropriate domain groups.
Create the Group Policies in the OU where they will be applied.
Link each Group Policy to any additional OUs as necessary.
Import the appropriate security template to each GPO.
Configure permissions on each GPO so that the appropriate domain groups have control over them.
Add the appropriate domain groups to Restricted Groups for each GPO.
Test and refine the Group Policies.
Group Policy security settings may be applied at several different levels in your organization. Contoso decided to use Group Policy to apply settings at the following three levels:
Domain Level. To address common security requirements, such as account policies that must be enforced for all servers.
Baseline Level. To address specific server security requirements that are common to all servers in the network.
Role Specific. To address role-specific security requirements. For example, the security requirements for infrastructure servers differ from those for servers running Microsoft Internet Information Services (IIS).
In terms of security auditing, IIS creates log files that track connection attempts to Web, File Transfer Protocol (FTP), Network News Time Protocol (NNTP), and Simple Mail Transfer Protocol (SMTP) services.
Domain Policy Overview
Group Policy is extremely powerful because it allows computers throughout the network to undergo standard configuration. By providing administrators with the means to make security changes at the same time on all computers in the domain, or subsets of the domain, GPOs provide a significant portion of a configuration management solution for any enterprise.
The types of security changes that can be simultaneously applied through Group Policy include:
Modifying permissions on the file system
Modifying permissions on registry objects
Changing settings in the registry
Changing user rights assignments
Configuring system services
Configuring auditing and event logs
Setting account and password policies
The policy settings that affect these security changes are divided into multiple sections of the Windows 2000 Server computer policy.
Table 5.3 Windows 2000 Server Computer Policy Sections
Policy section name in UI
Account Policy\Password Policy
Configures password age, length, and complexity
Account Policy\Account Lockout Policy
Configures lockout duration, threshold, and reset counter
Account Policy\Kerberos Policy
Configures ticket lifetimes
Local Policies\Audit Policy
Enables or disables recording specific events
Local Policies\User Rights Assignment
Defines rights such as log on locally and network access
Local Policies\Security Options
Modifies specific security-related registry values
Enables success and failure monitoring
Administrators control who belongs to specific groups
Controls Startup Mode for each service
Configures permissions and auditing on registry keys
Configures permissions and auditing on folders, subfolders, and files
All computers have a predefined local policy. When an Active Directory domain is initially created, default domain and domain controller policies are also created. Instead of modifying the default policies, you should create a new policy and link it to the domain. This approach will enable a quick rollback of any settings that may cause unidentified problems in your environment. If the default policies are ever modified, it is important to document the settings they contain, so that you can easily return to the previous state in the event of a problem.
The following section discusses the settings that should be considered and documented at the domain level.
Account policies are implemented at the domain level. A Windows 2000 Server domain must have a single password policy, an account lockout policy, and Kerberos version 5 policy for the domain. Setting these policies at any other level in Active Directory will affect only 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.
In Windows 2000 Server, the most common method to authenticate a user’s identity is to use a secret user password. After a user has been identified and authenticated, the user may perform any tasks or access any resource that he or she is authorized to perform.
Securing Active Directory in your environment requires that strong passwords be used by all users. Strong passwords help avoid the threat of an unauthorized user guessing a weak password through either manual methods or tools to acquire the credentials of a compromised user account, especially for administrative accounts.
A complex password that changes regularly reduces the likelihood of a successful password attack. Password policy settings control the complexity and lifetime for passwords. Each specific password policy account setting is discussed in this section.
The following values can be configured in the Domain Group Policy settings at the following location:
Computer Configuration\Windows Settings\Security Settings\Account Policies\
Enforce Password HistoryVulnerability
Password reuse is a large concern in any organization. There are at least three kinds of password reuse issues that underscore this vulnerability:
Reuse of passwords for multiple accounts within an organization. This issue is commonly seen when users or administrators have multiple accounts in different domains, or for different functions within one domain, and the accounts share the same password.
Use or reuse of the same password for any account over a long period of time. If users are required to change their password, but nothing prevents them from using the old password or allows them to continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced.
Reuse of the same password for multiple service accounts. If an organization must use service accounts, each one should have a unique password that exceeds the basic password requirements to ensure that each password is extremely difficult to crack.
The Enforce Password History setting determines the number of unique new passwords that must be associated with a user account before an old password can be reused.
Specifying a low number for this policy setting will provide users the ability to continually use the same small number of passwords repeatedly. If the Minimum Password Age setting is not configured as well, users can change their password as many times as necessary in a row to reuse their original password.
For the Enforce Password History setting to be effective in your organization, do not allow passwords to be changed immediately when configuring the Minimum Password Age setting.Countermeasure
Configure Enforce Password History to a value of 24. The value for the Enforce Password History setting can be set between 0 and 24 passwords. This setting is defined with a value of 1 in the Default Domain GPO and in the local security policy of workstations and servers. Configuring this value to the maximum setting helps ensure that vulnerabilities caused by password reuse are kept to a minimum.Potential Impact
The major impact of this setting is that users will have to come up with a new password every time they are required to change their old one. By requiring users to change their passwords to new unique values, there is an increased risk of encountering users who write down their passwords so that they do not forget them.
This value should be set at a level to combine a reasonable maximum password age with a reasonable password change interval requirement for all users in your organization.Contoso Scenario
In the Contoso scenario, Enforce Password History was configured to 24.
Maximum Password AgeVulnerability
Any password can be cracked. With current computing power, breaking even the most complex password is only a matter of time and effort. Some of the following settings can increase the level of difficulty to break passwords in a reasonable amount of time. However, frequently changing user passwords in your environment may help reduce the risk of a valid password being cracked, as well as potentially mitigate the risk of a password that has been wrongfully acquired from being used.
The Maximum Password Age setting determines the number of days that a password can be used before the computer requires the user to change it. The maximum password age can be configured so that users are never required to change their passwords, but doing so will result in a major security risk.Countermeasure
Configure Maximum Password Age to a value between 30 and 60 days. The value for the Maximum Password Age setting can be configured to expire after 1 to 999 days, or to never expire by configuring the number of days to 0. This setting is configured with a value of 42 in the Default Domain GPO and in the local security policy of workstations and servers.Potential Impact
Setting the maximum password age value at too low a number of days will require users to change their passwords very often. Such a requirement may actually reduce the security in the organization because it may increase the possibility of users writing their passwords down to avoid forgetting them.
Setting the value too high will reduce the level of security within an organization because it will allow a potential attacker a much larger window in which to crack a user password.Contoso Scenario
In the Contoso scenario, Maximum Password Age was configured to the default value of 42 days. This provides security for Contoso by requiring users to frequently change their passwords, but minimizes the inconvenience for users by not requiring them to change their passwords too often.
Minimum Password AgeVulnerability
Users who want to reuse a password may be forced to change their password on a regular basis. If a policy is configured to ensure that they do not reuse any of their last 12 passwords, they could change their password 13 times in a row to return to the password they were originally using.
The Minimum Password Age setting determines the number of days that a password must be used before the user is allowed to change it. The minimum password age value must be less than the maximum password age value.
As mentioned before, the Minimum Password Age setting must be configured to more than 0 for the Enforce Password History setting to be effective. Without a minimum password age, users can repeatedly change passwords, cycling through them until they get to an old favorite.Countermeasure
Configure Minimum Password Age to a value of 2 days. The value can be set between 1 day and 998 days, or password changes can be allowed immediately by configuring the number of days to 0, which is not recommended. This setting is undefined in the Default Domain GPO and in the local security policy of workstations and servers, which allows passwords to be changed immediately.Potential Impact
There is one minor issue with setting Minimum Password Age to a number greater than 0. If an administrator sets a password for a user and then would like 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 next day.Contoso Scenario
In the Contoso scenario, Minimum Password Age was configured to 2 days to discourage users from cycling through passwords to reuse old ones.
Minimum Password LengthVulnerability
There are several types of password attacks that can be performed to obtain the password for a particular user account. Types of attacks include dictionary attacks, which attempt to use common words and phrases, and brute-force attacks, which try every possible combination of numbers and letters. In addition, an attack could be performed by obtaining the LM password hash and using utilities to crash the hashes and obtain passwords.
The Minimum Password Length setting determines the least number of characters that may make up a password for a user account. There are many different theories on determining the best password length for an organization.Countermeasure
Configure Minimum Password Length to a value of at least 8 characters. Values between 1 and 14 characters can be specified for this setting. No password will be required if the number of characters is set to 0. This setting is defined with a value of 0 in the Default Domain GPO and in the local security policy of workstations and servers.
In most environments, an eight-character password is recommended, as it is long enough to provide adequate security and still short enough for users to remember more easily. This setting will provide adequate defense against a brute-force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. Complexity requirements will be discussed in the next section.
The attack against the password hash is discussed in detail in Chapter 6, "Hardening the Base Windows 2000 Server."Potential Impact
Requiring too short a password will reduce security because short passwords may easily be broken with tools that perform either dictionary or brute-force attacks against the passwords. Requiring too long a password may result in mistyped passwords that could result in an account lockout and subsequently additional help desk call volume.
Requiring extremely long passwords can actually decrease the security of an organization because users may be more likely to write their passwords down in fear of forgetting them.Contoso Scenario
In the Contoso scenario, the value for Minimum Password Length was configured to 8 characters.
Passwords Must Meet Complexity RequirementsVulnerability
Passwords that contain only alphanumeric characters are extremely easy to crack using several publicly available utilities. To prevent passwords from being easily cracked, they should be required to contain additional characters.
The Passwords Must Meet Complexity Requirements setting determines whether passwords must meet a series of guidelines that are considered important for a strong password.
If this policy setting is enabled, then passwords must meet the following requirements:
The password does not contain all or part of the user's account name
The password is at least six characters long
The password contains characters from three of the following four categories:
English uppercase letters (A–Z)
English lowercase letters (a–z)
Base 10 digits (0–9)
Nonalphanumeric characters (for example, !, $, #, or %)
These complexity requirements are enforced upon password change or creation of new passwords.
The rules that are included in the Windows 2000 Server policy cannot be directly modified. However, a new version of Passfilt.dll can be created to apply a different set of rules.Countermeasure
Configure Passwords must meet complexity requirements to the value Enabled. This setting is disabled in the Default Domain GPO and in the local security policy of workstations and servers.
This setting, combined with the eight-character minimum password length, ensures that there are at least 218,340,105,584,896 different possibilities for a single password. This configuration makes the use of a brute-force attack very difficult if not impossible.Potential Impact
Enabling the default Passfilt.dll may cause some additional help desk calls for locked-out accounts because users may not be used to having passwords that contain characters other than ones found in the alphabet. However, this setting is liberal enough that all users should be able to abide by the requirements with a minor learning curve.
Additional settings that could be included in a custom passfilt.dll could include 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 1–10.
Also, the use of ALT key character combinations may 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 0128–0159 range as part of all administrator passwords. ALT characters outside of this range may represent standard alphanumeric characters that would not add additional complexity to the password.Contoso Scenario
In the Contoso scenario, Password must meet complexity requirements was configured to Enabled.
Store Password Using Reversible Encryption for All Users in the DomainVulnerability
Some applications may require access to user passwords to provide additional functionality. This need is often served by allowing the password to be stored in a "reversibly encrypted format," which is not secure.
The setting for Store password using reversible encryption for all users in the domain determines whether Windows 2000 Server will store passwords in a much weaker format that is comparable to using plaintext. Using this setting weakens passwords in your environment. A message in plaintext is not encrypted. Plaintext messages were formerly referred to as cleartext messages.Potential Impact
This policy setting is required when using the CHAP authentication protocol through remote access or Internet Authentication Service (IAS) services. It is also required when using Digest Authentication in IIS. This policy setting is extremely dangerous to apply using Group Policy on a user-by-user basis, because it requires opening the appropriate user account object in the Active Directory Users and Computers management console.
WARNING This policy setting should never be enabled unless application requirements outweigh the need to protect password information.Countermeasure
Ensure that the value for Store password using reversible encryption for all users in the domain is configured to Disabled. This policy setting is disabled in the Default Domain GPO and in the local security policy of workstations and servers.Contoso Scenario
In the Contoso scenario, Store password using reversible encryption for all users in the domain was left configured to Disabled.
Password Policy Summary
Regardless of which domain policies are set, the settings for User must change password at next logon, User cannot change password, Password never expires, and Store password using reversible encryption policies can be configured for any individual user. This configuration can be done by accessing the Account tab of the user's Properties dialog box. These individual user password policy settings override domain policies.
The password policy settings for Contoso are summarized in the following table.
Table 5.4 Contoso Password Policies
Password policy name in UI
Enforce Password History
24 passwords remembered
Maximum Password Age
Minimum Password Age
Minimum Password Length
Password must meet complexity requirements
Store password using reversible encryption for all users in domain
Account Lockout Policy
More than a few unsuccessful password tries during an attempt to log on might represent an attacker trying to determine an account password by trial and error. Windows 2000 Server keeps track of logon attempts, and the operating system can be configured to respond to this type of potential attack by disabling the account for a preset period of time.
Account lockout policy settings control the threshold for this response and the actions to be taken after the threshold is reached.
Account Lockout DurationVulnerability
A denial of service (DoS) may be created if an attacker abuses the account lockout threshold and repeatedly attempts to log in to an account. If the account lockout threshold is set, after a specified number of failed attempts, the account will be locked out.
The Account Lockout Duration setting determines the number of minutes a locked out account remains unavailable.Countermeasure
Configure Account Lockout Duration to a value of 30 minutes. The Account Lockout Duration can be set to a value between 1 and 99,999 minutes. To specify that the account will never be locked out, the value may be set to 0. This setting is not defined in the Default Domain GPO and in the local security policy of workstations and servers.Potential Impact
Although 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.Contoso Scenario
In the Contoso scenario, Account Lockout Duration was configured to 30 minutes to help reduce the number of support calls resulting from users locked out of their accounts.
Account Lockout ThresholdVulnerability
Password attacks may use automated methods to try thousands of password combinations for any or all user accounts. By limiting the number of failed logons that can be performed, the effectiveness of such attacks is nearly eliminated.
However, it is important to note that a DoS attack could be performed on a domain that has an account lockout threshold configured. A malicious attacker could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker will have the potential of locking out every account.
The Account Lockout Threshold setting determines the number of failed logon attempts that will cause a user account to be locked out. If an Account Lockout Threshold is defined, then the Account Lockout Duration must be greater than or equal to the reset time.Countermeasure
By default, this policy setting is configured to 0 in the Default Domain GPO and the local security policy of workstations and servers. The maximum value for Account Lockout Threshold is 999.
Because vulnerabilities can exist both when this value is configured and when it is not, two distinct countermeasures are defined. Any organization should weigh the choice between the two on the basis of their identified threats and the risks that they are trying to mitigate. There are two options that should be considered for this setting.
Configure Account Lockout Threshold to 0, which ensures that accounts will not be locked out. This configuration will prevent a DoS attack that intentionally locks out all (or some specific) accounts. In addition, this configuration helps reduce help desk calls because users can not accidentally lock themselves out of their accounts. Because it will not prevent a brute-force attack, this configuration should be chosen 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 is occurring in the environment.
If these criteria are not met, configure Account Lockout Threshold to a high enough value to provide users the ability to accidentally mistype their password several times without locking their account, but to ensure that a brute-force password attack would still lock out the account. In this case, configuring the value to a very large number such as 50 invalid logon attempts is a good recommendation. This configuration will prevent accidental account lockouts, reducing the number of help desk calls, but will not prevent a DoS attack as mentioned earlier.
If the account lockout threshold is set, a locked-out account cannot be used until it is reset by an administrator or the account lockout duration has expired. This configuration will likely generate a number of additional help desk calls.
If the account lockout threshold is configured to 0, there is a possibility that an attacker's attempt to crack passwords using a brute-force password attack may go undetected.Contoso Scenario
In the Contoso scenario, Account Lockout Threshold was configured to 50 invalid logon attempts. This number ensures that users cannot accidentally lock themselves out and that automated vulnerability scanning tools will not lock users out, but continues to prevent a brute-force password attack.
Reset Account Lockout Counter AfterVulnerability
Users can accidentally lock themselves out of their account if they mistype their password multiple times. To reduce the impact of such lockouts, the Reset Account Lockout Counter After setting determines the number of minutes that must elapse after a failed logon attempt before the invalid logon attempt counter is reset to 0.
If an Account Lockout Threshold is defined, then this reset time must be less than or equal to the Account Lockout Duration.Countermeasure
Configure Reset Account Lockout Counter After to a value of 30 minutes. The range for this setting is 1 to 99,999 minutes. This policy setting is not defined in the Default Domain GPO or the local security policy of workstations and servers.Potential Impact
Not setting this value or setting the value to too long of an interval could result in a DoS attack. An attacker could maliciously perform a number of failed logon attempts on all users in the organization, locking out their accounts as mentioned earlier. With no policy configured to reset the account lockout, administrators would have to manually unlock all accounts. With a reasonable value set, the users would be locked out for some period, but at the end of that time period the accounts will be unlocked automatically.Contoso Scenario
In the Contoso scenario, Reset Account Lockout Counter After was configured to 30 minutes to increase the level of security against brute-force password attacks.
Account Lockout Policy Summary
In general, to increase security within your organization, the Account Lockout Duration setting should be increased while the Account Lockout Threshold is decreased. The Account Lockout Policy settings for Contoso are summarized in the following table.
Table 5.5 Contoso Account Lockout Policy Settings
Account lockout policy name in UI
Account Lockout Duration
Account Lockout Threshold
50 invalid logon attempts
Reset Account Lockout Counter After
Contoso's settings create a situation in which a user who makes 50 invalid logons in 30 minutes will be locked out of their account. The account will be automatically reset after 30 minutes. If the account needs to be reset during this 30-minute period, the action must be performed manually by an account administrator.
In Windows 2000 Server, the Kerberos version 5 authentication protocol provides the default mechanism for authentication services, as well as 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, the risk of a legitimate user’s credentials being stolen and successfully used by an attacker decreases. However, authorization overhead increases.
In most environments, these settings need not be changed.
Kerberos Policy Summary
Contoso has decided to maintain the default settings for the company's Kerberos version 5 policy. These settings are summarized in the following table.
Table 5.6 Kerberos Policy Settings
Kerberos policy name in UI
Enforce user logon restrictions
Maximum lifetime for service ticket
Maximum lifetime for user ticket
Maximum lifetime for user ticket renewal
Maximum tolerance for computer clock synchronization
The Kerberos policy settings are left at their default values. They are not specifically defined in Contoso's environment or the MSS Domain.inf file included in the security templates associated with this solution.
There are a number of additional policies that will be configured as the baseline policy for all member servers in Contoso, as well as additional settings for many of the specific server roles. These settings will be discussed in Chapter 6, "Hardening the Base Windows 2000 Server," and Chapter 7, "Hardening Specific Server Roles."
Importing the Security Templates
The following procedure imports the security templates included with this guide into the OU structure suggested in this chapter. Before implementing the following procedure on a domain controller, the specific policy (.inf) files must be located on a Windows 2000 Server in your environment.
WARNING The security templates in this guide are designed to increase security in your environment. It is quite possible that by installing the templates included with this guide, some functionality in the environment of your organization may be lost. Such lost functionality could include the failure of mission-critical applications.
It is therefore essential to thoroughly test these templates before deploying them in a production environment. Back up each domain controller and server in your environment prior to applying any new security settings. Ensure that the system state is included in the backup to enable registry settings or Active Directory objects to be restored
Before continuing with the procedure to import the security templates, if the servers in your environment are not running at least Windows 2000 SP3 as recommended in this guide, apply the hotfix discussed in Microsoft Knowledge Base article 295444, " SCE Cannot Alter a Service's SACL Entry in the Service's Registry Key," at http://support.microsoft.com/default.aspx?scid=295444.
If this hotfix is not applied, the Group Policy templates will not be able to disable any services. A hotfix is a single cumulative package composed of one or more files used to address a defect in a product. Hotfixes address a specific customer situation and may not be distributed outside the customer organization without written legal consent from Microsoft. The terms QFE, patch, and update have also been used as synonyms for hotfix.
Importing the Domain Policy
In Active Directory Users and Computers right-click the Domain and then click Properties.
On the Group Policy tab, click New to add a new GPO.
Type Domain Security Policy and press ENTER.
Right-click Domain Security Policy and click No Override.
Select Domain Security Policy and click Edit.
In the Group Policy window, click Computer Configuration\Windows Settings. Right-click Security Settings and click Import Policy.
In the Import Policy From dialog box, navigate to \SCI\Security Templates and then double-click MSS Domain.inf.
Close the Group Policy that has been modified.
Close the Domain Properties window.
To force replication between your domain controllers so that all domain controllers have the policy:
Open a command prompt and type
Verify in the Event Log that the policy downloaded successfully and that the server can communicate with the other domain controllers in the domain.
Secedit.exe is a command-line tool that, when called from a batch file or automatic task scheduler, can be used to automatically create and apply templates and analyze system security. It can also be run dynamically from a command line.
It is important to note that this policy should be imported into any additional domains in the organization. However, it is not uncommon to find environments where the root domain password policy is much stricter than that of any of the other domains. Additionally, care should be taken to ensure that any other domains that will use this same policy have the same business requirements. Because the password policy can be set only at the domain level, there may be business or legal requirements that segment some users into a separate domain simply to enforce the use of a stricter password policy on that group.
Contoso chose to use the same policy for their root and child domains, and utilized the same MSS Domain.inf to implement each.
Procedures that are similar to the one in this section should be used to apply any of the subsequent templates for the baseline policy and the incremental policies.
Successful GPO Application Events
Aside from manually checking all of the settings to ensure that they have been appropriately applied to a server in your organization, an event also should appear in the Event Log to inform the administrator that the domain policy has downloaded successfully. The following event information should appear in the Application Log with its own unique Event ID number:
Source ID: SceCli
Event ID: 1704
Description: Security policy in the Group Policy objects are applied successfully
If this message does not appear within a few minutes after applying the policy, rerun the Secedit.exe command-line tool to apply the domain policy, and then restart the server to force the domain policy download.
By default, the security settings are refreshed every 90 minutes on a workstation or server and every 5 minutes on a domain controller. You will see this event if any changes have occurred during that time. Additionally, the settings are also refreshed every 16 hours, regardless of whether there are any changes.
There are several design considerations that should be made when reviewing a forest, a domain, and an organizational unit (OU) design for security.
Research and document any specific autonomy and isolation requirements for your organization. Political autonomy, operational isolation, and legal or regulatory isolation are all valid reasons to consider complex forest designs.
Understand the ability to control service administrators. 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.
It may not be easy to change the forest or domain design in your organization, but it may be necessary to remediate some security risks for your enterprise.
Plan the OU deployment in your organization according to the needs of the service administrators and the data administrators. Create an OU model that will support using Group Policy objects (GPOs) for the ongoing management of the different server roles in your enterprise.
Finally, review all domain-wide settings in your organization. Only one set of password, account lockout, and Kerberos version 5 authentication protocol policies can be configured for the domain. Other password and account lockout settings will affect only the local accounts on member servers. Plan to configure settings that will apply to all member servers of the domain, and ensure that these settings provide an adequate level of security across your organization.
For information about security and privacy at Microsoft, see the Trustworthy Computing: Security Web site at www.microsoft.com/mscorp/twc/security/default.mspx.
For information about security problems that do not result from product flaws, see the article "10 Immutable Laws of Security" at www.microsoft.com/technet/archive/
For information about using Active Directory to delegate administration, see the "Design Considerations for Delegation of Administration in Active Directory" article at www.microsoft.com/technet/prodtechnol/windows2000serv
For information about configuring a time server, see the "How to configure an authoritative time server in Windows 2000" article at http://support.microsoft.com/default.aspx?scid=216734.
Solution Accelerator Notifications