Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part I
By Kathleen Cole, Dave Kreitler, Doug Steen, Markus Vilcinskas
On This Page
Introduction Chapter 1: Planning Active Directory Security Chapter 2: Establishing Secure Active Directory Boundaries Chapter 3: Deploying Secure Domain Controllers Chapter 4: Establishing Secure Domain and Domain Controller Policy Settings Chapter 5: Establishing Secure Administrative Practices Chapter 6: Securing DNS Appendix: Procedures
Introduction
Organizations require a network operating system (NOS) that provides secure network access to network data by authorized users and that rejects access by unauthorized users. For a Microsoft® Windows® 2000 NOS, the Active Directory® directory service provides many key components that are needed for authenticating users and for generating authorization data for controlling access to network resources.
A breach in Active Directory security can result in the loss of network resource access by legitimate clients or in the disclosure of potentially sensitive information. Such information disclosure can occur for data that is stored on network resources or from the Active Directory database itself. To avoid these situations, organizations need more extensive information and support to ensure enhanced security for their NOS environments. This guide addresses this need for organizations that have new, as well as existing, Active Directory deployments.
A comprehensive plan for Active Directory security requires action in five areas:
Protection of domain controllers against known threats
Administrative policies and practices to maintain security
Detection of attacks that have not been identified or mitigated previously
Defense against Active Directory attacks
Recovery from Active Directory attacks
The Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations comprises two parts. Part I of the guide, which is presented here, contains recommendations for protecting domain controllers from potential attacks of known origin and recommendations for establishing secure administrative policies and practices. Part I addresses Active Directory security issues by providing guidelines for maintaining Active Directory security boundaries, enhancing domain controller security, and securing Active Directory administration.
This guide also includes scripts, procedures and templates needed to enact these recommendations.
Note: Recommendations and procedures in this guide have been tested in a lab to demonstrate that domain controllers that are built, configured, and administered in accordance with these recommendations can be deployed and operated in an efficient manner that enhances security.
Part II of the guide, which will be issued shortly after Part I, contains recommendations for detecting attacks, defending against known and unknown threats, and recovering from attacks.
Scope of This Guide
Although NOS security relies on secure design principles and operating practices for all components in the operating system, the scope of this guide is limited to recommendations and explanations for deploying and operating Active Directory domain controllers. Other security topics, such as secure network connectivity and secure clients, are not addressed in this guide.
Part I of this guide provides guidelines for Active Directory deployment and administrative practices that are designed to maintain a secure operating environment. These guidelines, which can be applied to both new and existing Active Directory infrastructures, are organized into the following chapters:
Planning Active Directory Security
Establishing Secure Active Directory Boundaries
Deploying Secure Domain Controllers
Establishing Secure Domain and Domain Controller Policy Settings
Establishing Secure Administrative Practices
Securing DNS
The recommendations in this guide take into consideration how an organization's domain controllers are deployed. Domain controllers can be deployed in datacenters for enterprise intranets, in branch offices, and in datacenters for extranets. In some cases, the guidelines vary in accordance with special circumstances that are encountered in each environment.
Audience
This guide is intended primarily for IT planners, architects, and managers who are responsible for establishing Active Directory deployment and operations practices. As a result, this guide emphasizes the decision-making process, rather than procedures.
How to Use This Guide
The information in this guide is presented as if the reader's organization is planning its Active Directory deployment and operations. However, this information can be equally beneficial to an organization that is reviewing its current Active Directory security practices.
You can proceed through the Active Directory security planning process in the order presented in this guide. Each phase of the Active Directory security planning process, such as deploying secure domain controllers, is contained in its own chapter. Each chapter begins with a discussion of how the security recommendations enhance security, and it also discusses their cost in terms of complexity and performance. If a recommendation is impractical for a specific deployment strategy, that is indicated, and specific alternatives are recommended, if they exist. Finally, the recommendations in each chapter are summarized in a checklist at the end of the chapter.
You can proceed to the next chapter after completing the checklist of recommendations at the end of the previous chapter. Before proceeding with security planning, make sure that you:
Set your business goals and practices and understand how they affect Active Directory security.
Gain executive-level sponsorship to implement a secure, Active Directory-managed Windows network.
Active Directory infrastructure and practices can span both technology and business areas. Therefore, to make progress in security planning, you must articulate the value of security to IT and business decision makers.
The Role of Active Directory in Secure Access
Windows requires verification of every user's identity before it allows access to network resources. The process of verifying the identity of users, also known as authentication, is part of the logon process. The process of granting or denying access to a resource is called authorization. During authentication, all entities identify themselves to the security system by means of a unique user ID. Active Directory stores security-related identity information for users, as well as their credentials (such as passwords), in the form of a user account object. The system generates a unique security identifier (SID) for every account object that can be authenticated or authorized for access to resources. Every SID contains the identifier of the domain in which the object resides.
Objects with a SID are also known as security principals. The following types of objects act as security principals:
User: a person or a service that requires user credentials
Computer: a workstation or server running Windows
Group: a set of users, computers, or other groups
After Active Directory confirms the identity of the user, the security system on the authenticating domain controller generates partial authorization data in the form of the user's primary SID, plus SIDs for groups to which the user belongs that are recognized by all the resources on the Windows network. The remainder of the authorization data is generated at the time that the user requests access to a specific network resource, such as a server, file share, or directory object. The authorization data is used by the computer that houses the network resource to generate an access token that consists of the list of SIDs representing the user, all groups (including nested groups) that the user is member of, and the user's privileges (also called user rights) on the local computer. The access token is used to determine the level of access that the user has on the network resource.
All objects or resources that are secured have a discretionary access control list (DACL) assigned to them that specifies the access rights of users and groups on that resource. Access to one of these objects or resources is gated by an access check, in which the security system evaluates the content of the access token of the requestor against the DACL on the resource to determine if the requested access should be granted or not. This process is also known as access control or authorization.
Planning for Active Directory Security in Depth
A security strategy for an enterprise is most effective when data is protected by more than one layer of security. With this type of strategy, the potential losses that might be caused by a security failure in any single layer are minimized by the remaining security layers. For example, when a home is protected by both door locks and a security system, the homeowner is implementing a security-in-depth strategy that is more effective than either of these security features alone.
A security-in-depth approach first divides all security elements into discrete security layers. This way, the security effectiveness of each layer can be independently determined, and a security plan can be implemented. Figure 1 shows one way of visualizing the relationships among these security layers for Active Directory.
Figure 1 Security in Depth for Active Directory
Active Directory security policies and practices can be divided into the following layers:
Physical security for domain controllers and the network (physical access to domain controllers, backup data, and network components)
Administrative authority (security management and secure administrative practices)
End system (domain controller settings, policy settings, and deployment practices)
This guide provides recommendations for security best practices that are based on security in depth. This guide is organized along the lines of the security layers for secure deployment of domain controllers, including physical security, domain and domain controller policies, and administrative practices.
Process for Securing Active Directory Installations and Operations
This guide focuses solely on the deployment and operation recommendations for creating a secure Active Directory system. Figure 2 depicts the process flow for these recommendations.
Figure 2 Process Flow for Securing Windows 2000 Active Directory
Part I and II in the flowchart correspond to Parts I and II of this guide.
Part I of the process is designed to create a secure domain controller environment. In addition, because Domain Name System (DNS) is an integral component of Active Directory, this guide also includes policies and practices for DNS on a domain controller.
Part II of the process is designed to help maintain a secure Active Directory infrastructure. This includes a list of day-to-day security operations to perform, specific events and resources to monitor, administrative activities to audit, and how to detect and respond to an attack. Finally, in the case of a security attack damaging some portion of the Active Directory infrastructure, Part II provides recommendations for system recovery.
Chapter 1: Planning Active Directory Security
The goal of this guide is to assist organizations in enhancing the security of their Active Directory systems. However, any guide that addresses a general audience can provide a security foundation only in the form of guidelines. In some instances, these guidelines may conflict with the needs of an organization to lower costs, provide services and line-of-business (LOB) applications, or maintain an IT infrastructure. In such cases, an organization's security planning team can evaluate these other needs against the need for security, to arrive at suitable tradeoffs.
Evaluating the need for Active Directory security against other business needs of an organization depends on the type of operating environment in which the domain controllers are deployed. The three most common operating environments in which domain controllers are deployed (that is, the three most common deployment scenarios for domain controllers) are described in the following section.
Deployment Scenarios for Domain Controllers in a Secure NOS
The three most common deployment scenarios for domain controllers deployed in a secure network operating system (NOS) are as follows:
Datacenter for an intranet
Branch office
Datacenter for an extranet
The way in which domain controllers are deployed in an organization can, in some cases, affect the feasibility of implementing the Active Directory security guidelines that are presented in this guide. Each set of guidelines includes a discussion, where appropriate, of how the deployment model affects the cost and logistical difficulty of implementing the recommendations.
Domain Controllers in Intranet Datacenters
The datacenter for an enterprise intranet is possibly the most common domain controller deployment scenario, and it is the easiest scenario in which to deploy and administer domain controllers. Intranet datacenters normally possess most, if not all, of the following characteristics:
Fast, high-bandwidth network connectivity among all domain controllers
Centralized, secure facilities for housing and managing domain controllers
Facilities for building and configuring domain controllers
Facilities for testing hardware, operating systems, and policies
Centralized, dedicated IT and security staff with defined administrative roles
Facilities for monitoring and auditing domain controllers
Larger organizations may contain more than one datacenter to support regional business operations. Each datacenter is likely to have its own IT and security staff.
Figure 3 represents one possible datacenter design for a medium-sized organization with facilities in two regions. Each datacenter services intranet and remote clients in its region. Connectivity requirements among datacenters vary in accordance with an organization's business needs and its Active Directory infrastructure design.
Figure 3 Domain Controllers in Intranet Datacenters
Of the three domain controller deployment scenarios, the intranet datacenter most readily supports the requirements of a managed environment. IT staff members are generally on-site; therefore, access to the datacenter and to administrative tasks can easily be restricted to them. In addition, monitoring and troubleshooting of domain controller problems is simplified, and attacks can be quickly detected and handled.
Intranet datacenters also possess a high degree of manageability. Intranet datacenter deployments generally include the following management characteristics:
Centrally designed and managed domain controller and administrative policies
Written administrative practices for building, deploying, and managing domains and domain controllers
Domain Controllers in Branch Offices
An organization with a large number of locations, each with limited number of users and servers, may still require local network access to a domain controller for authentication and authorization at each location. Branch office deployments normally possess most, if not all, of the following characteristics:
Slow, intermittent connectivity to other domain controllers outside the branch office
Domain controllers sharing a subnet with users and computers
Domain controllers hosting other applications or infrastructure services, such as Windows Internet Name Service (WINS) and Print Services
Lack of dedicated, secure facilities for housing and managing domain controllers
Lack of local, dedicated IT staff
Figure 4 shows a design for domain controllers in branch offices.
Figure 4 Domain Controllers in Branch Offices
Of the three domain controller deployment models, the branch office presents the greatest challenges in supporting the requirements of a secure, managed environment. IT staff members are generally off-site; therefore, all administrative tasks cannot easily be restricted to them. In addition, restricting physical access to the domain controllers can be difficult. Detecting and responding to domain controller problems and attacks can be slow and costly.
Another challenge that the branch office model presents is manageability. Branch office deployments generally include the following management characteristics:
Decentralized domain controller management or remote management of these domain controllers by administrators in the datacenter
Lack of uniformity in the application of domain controller management and administrative practices
Domain Controllers in Extranet Datacenters
The extranet datacenter scenario is a variation of the intranet datacenter. Like intranet datacenters, extranet datacenters normally possess most of the following characteristics:
Fast, high-bandwidth network connectivity among all domain controllers
Centralized, secure facilities for housing and managing domain controllers
Facilities for building and configuring domain controllers
Facilities for testing hardware, operating systems, and policies
Centralized, dedicated IT and security staff with defined administrative roles
Facilities for monitoring and auditing domain controllers
Domain controllers in extranet datacenters fulfill two primary functions. First, they can be used to manage servers and resources within the extranet. Second, they can be used to authenticate customers and partners (outward-facing) and to provide them with access to resources within the extranet. Additional characteristics that most extranet datacenters possess include the following:
Firewalls that restrict Internet traffic into the datacenter
Firewalls that prevent users in the datacenter from accessing the corporate network
Customers and partners tunneling into the extranet from outside the network
Figure 5 illustrates domain controllers in extranet datacenters.
Figure 5 Domain Controllers in Extranet Datacenters
In addition to the management characteristics of intranet datacenters, extranet datacenters may have administrators managing accounts within the extranet itself, or they may have accounts in the enterprise intranet that are used to manage the extranet.
Security Planning
This guide concentrates primarily on recommendations for minimizing known security threats to Active Directory. However, the following sections provide a short summary of how threat analysis can be used to create a security plan, based on the security features in Windows 2000.
Figure 6 illustrates how a threat analysis fits into an overall security plan.
Figure 6 Process for Planning Active Directory Security
Making Active Directory deployment and administration secure encompasses planning for both mitigation (proactive security) and contingency (reactive security). The proactive portion of the plan protects assets by alleviating any threats to the system that might be caused by user mistakes and by attacks based on known threats. The reactive portion of the plan provides contingency plans to implement under the following conditions:
Threat analysis fails to anticipate a threat.
It is not possible to completely mitigate a threat.
Security recommendations cannot be implemented.
Identifying Types of Threats
In their attempts to breach a system's security, all threats exploit weaknesses in the operating system, applications, network design, security policies, or administrative practices. In addition, social engineering phenomena pose a threat to Active Directory. Threats are commonly categorized according to the goal of the attack. This type of threat analysis is referred to by the acronym STRIDE, which is derived from the first letter of each category of threat. These threats are explained in the following sections.
Spoofing
The goal of a spoofing attack is illicit access to network resources by unauthorized users. Spoofing involves forging the identity of a valid system user or resource to get access to the system, thereby compromising system security. Spoofing attacks include the following:
Changing the identity that is associated with an Active Directory object
Subverting a secure logon mechanism
Using false credentials
Tampering with Data
The goal of a data-tampering attack is to cause unauthorized modification of data, resulting in a loss of data integrity. This type of attack modifies system or user data, with or without detection, resulting in unauthorized changes to network information, network packets in a communication, sensitive files, or the formatting of a hard disk. Data-tampering attacks include the following:
Modifying data that should not be accessible
Causing a trusted entity to modify data improperly
Creating an elevation-of-privilege attack that allows a user to tamper with data
Repudiation
The goal of a repudiation attack is to perform an authorized or unauthorized action and to eliminate any evidence that could prove the identity of the attacker. Repudiation attacks are associated with users who can deny wrongdoing, without any way to prove otherwise. Repudiation attacks include the following:
Circumventing the logging of security events
Tampering with the security log to conceal the identity of an attacker
Information Disclosure
An information-disclosure risk exists if a user can gain access to data, intentionally or otherwise, that the user is not authorized to see, resulting in the loss of data privacy and confidentiality. Information disclosure attacks include the following:
Accessing data that is considered private and protected
Sniffing data on a network while in transit
Using social engineering to improperly reveal user identity or passwords
Denial of Service
The goal of a denial-of-service attack is the loss of access by legitimate users to a server or service. Generally speaking, denial-of-service attacks occur when a malicious user either disables critical services on a computer or consumes so many resources on a system that no resources are available for legitimate users. The resources that can be exhausted include CPU cycles, disk space, memory, server connections, or network bandwidth, among others. Denial-of-service attacks include the following:
Consuming CPU cycles by infinite or very long programmatic looping
Consuming excessive memory or file quotas to block legitimate use
Causing a crash, restart, or error mechanism to interfere with normal use
Elevation of Privilege
The goal of an elevation-of-privilege attack is illicit access to network resources or services by unauthorized users. The most severe form of an elevation-of-privilege attack is a situation in which an attacker effectively penetrates all system defenses. The attacker then becomes part of the trusted system itself and can completely compromise or destroy the system. Elevation-of-privilege attacks include the following:
Improperly gaining unrestricted rights
Running untrusted data as native code in a trusted process
Spoofing a more privileged identity to gain elevated privileges
Social Engineering
Social engineering represents any type of behavior that can inadvertently aid an attacker in gaining access to a user's password. Examples include someone in the organization doing the following:
Writing his or her password and placing it in a location where a coworker could find it
Coaxing a fellow worker into revealing his or her password
Befriending a janitor with physical access to domain controllers
Identifying Sources of Threats
Identification of the various sources of threats to Active Directory provides a basis for understanding and creating an effective security plan. Active Directory defines groups of users, and by default it installs policies that limit access of the user groups to network resources and services. Therefore, each user group represents a different source of threat, as indicated in Table 1.
Table 1 Sources of Potential Threat to Active Directory
Source |
Description of Source and Threat |
---|---|
Anonymous users |
Represents unauthenticated access to the network that is enabled when Group Policy settings allow anonymous access and when permissions on resources are set to allow Everyone access. Supports earlier versions of clients, such as servers running Microsoft® Windows NT®, when they require information from Active Directory to perform their functions. Allowing access for anonymous users results in a reduced level of security for Active Directory, because unauthorized access to Active Directory information can result in information disclosure. See "Selecting Policy Settings for Mixed Operating System Environments." |
Authenticated users |
Represents any user who has successfully completed the authentication process. This implies that the user has an identity in the domain or in a trusted domain and has provided valid credentials. Authenticated users can, by default, access information in the directory and on domain controllers, and they can view system logs. To enhance Active Directory security against information disclosure, unnecessary access should be eliminated. See "Establishing Secure Domain Controller Policy Settings." |
Service administrator |
Represents administrative accounts that are used legitimately to control directory service configuration and policies and to have physical access to domain controllers to manage server administration. Also used to control the forest infrastructure by creating or removing domains and domain controllers, managing domain and domain controller configuration, and monitoring domain controller health. Service administrators are in a position to launch attacks throughout the forest, and therefore they must be highly trusted. See "Trusting Service Administrators." |
Data administrator |
Similar to Windows NT administrators in their functions and privileges, this group supports managing data in Active Directory that does not control the directory service or its configuration. Supports users and computers in the forest by adding and removing organizational units (OUs), computers, users, and groups and by modifying Group Policy settings. Data administrators have delegated rights to manage objects in domain organizational units (OUs) but not to manage domain controllers or forest configuration. See "Specifying Security and Administrative Boundaries." |
Users with physical access to domain controllers |
Applies to any situation in which an individual accesses the area where domain controllers and administrator workstations reside or to a situation in which an individual steals one of these computers. If an unauthorized individual gains access to these computers, which contain sensitive data, information disclosure or data tampering is possible. See "Maintaining Physical Security." |
Chapter 2: Establishing Secure Active Directory Boundaries
Active Directory provides an infrastructure that can support an organization's need for isolation and autonomy, while enabling collaboration among people and organizations. IT planners must determine precisely their need for isolation, autonomy, and collaboration; understand the security implications of delegating administration; and be aware of the tradeoffs in a directory infrastructure.
Specifying Security and Administrative Boundaries
The Active Directory forest represents the outermost boundary within which users, computers, groups, and other objects exist. Active Directory domains, unlike Windows NT domains, are always part of a forest. They are the boundaries for administration and security policies. This means that policies, such as password complexity and password reuse rules, cannot be inherited from one domain to another. Each Active Directory domain is authoritative for the identity and credentials of the users, computers, and groups that reside in that domain.
Important: Previously published Active Directory documentation states that a domain is a security boundary, but this documentation does not provide specific details about the level of autonomy and isolation that is possible among domains in a forest. Although a domain is, in fact, a security boundary with regard to the management of security policies for Active Directory, it does not provide complete isolation in the face of possible attacks by service administrators.
Delegating Administration
Organizations typically delegate the administration of all or part of the Active Directory service or the data that is stored in their domains. Table 2 lists the reasons for delegating administration.
Table 2 Reasons to Delegate Administration
Reasons |
Explanation |
---|---|
Organizational |
One part of an organization may want to share an infrastructure to reduce costs but require operational independence from the rest of the organization. |
Operational |
One part of an organization or a single application may place unique constraints on the directory service configuration, availability, or security. Examples include:
|
Legal |
Some organizations have legal requirements that compel them to operate in a specific manner, such as restricting information access. Examples include:
|
For these reasons, an organization may need to delegate control over service management, data management, or both. The goal of delegation is to achieve either autonomy or isolation. Autonomy is the ability of administrators to independently manage part or all of the Active Directory service or the data in the directory or on member computers. Isolation is the ability of administrators to prevent other administrators from interfering in or accessing part or all of the Active Directory service or the data in the directory or on member computers.
For a complete discussion of service and data administrator roles, see "Comparing Service and Data Ownership" in "Part I: Determining the Number of Forests in Your Organization" of Best Practice Active Directory Design for Managing Windows Networks on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=18583.
An organization's requirements for service autonomy, data autonomy, service isolation, and data isolation determine the Active Directory infrastructure that is best suited to its needs. The first step is to define precisely the needs of your organization.
Active Directory boundaries can assist an organization in achieving the level of autonomy and isolation that its business units require. Table 3 provides a comparison of the characteristics of administrative autonomy and isolation.
Table 3 Comparison of the Characteristics of Autonomy and Isolation in Administration
Administrative Role |
Autonomy Means to... |
Isolation Means to... |
---|---|---|
Service administrator |
Manage independently all or part of service administration (service autonomy). |
Prevent other service administrators from controlling or interfering with service administration (service isolation). |
Data administrator |
Manage independently all or part of the data that is stored in the directory or on member computers (data autonomy) |
Prevent other data administrators from controlling or viewing data in the directory or on member computers that are joined to the directory (data isolation). |
Autonomy is less constrained than isolation. Administrators who require only autonomy accept the fact that other administrators of equal or higher privilege in the system have equivalent or overriding control in the forest. Because autonomy is less constrained than isolation, it is generally less costly and more efficient to delegate administrative autonomy.
Autonomy can be achieved by delegating service or data administration. Isolation requires that a business unit deploy a separate forest to contain its administrators, users, and resources. Multiple forests in an organization require external trusts to support collaboration. These trusts are discussed further in "Establishing Secure Collaboration with Other Directories" later in this guide.
Trusting Service Administrators
Before choosing an Active Directory delegation model, consider the following facts about Active Directory administrative roles:
Forest owners maintain the right to control domain-level services and to access data that is stored on any domain in the forest.
Domain owners maintain the right to access data that is stored on the domain or on its member computers.
Domain owners, although operating autonomously from forest owners and other domain owners, cannot prevent a malicious domain owner from controlling their services and accessing their data.
This high degree of collaboration and trust that is required among the authorities that are responsible for the management of domains in a forest necessitates that all administrators who manage domains be highly trusted. Therefore, Active Directory domains in a forest should never be deployed with the objective of isolating business units that do not trust each other.
To summarize the facts concerning directory structures and directory structure owners, for an organization to join a forest or domain infrastructure, it must choose to trust all service administrators in the forest and in all domains. Trusting service administrators means to:
Believe that service administrators look out for the organization's best interest. Organizations should not elect to join a forest or domain if the organization fears that the owner of the forest or domain might behave maliciously.
Believe that service administrators follow best practices for service administrators and for restriction of physical access to domain controllers.
Understand and accept the risks to the organization that are associated with rogue administrators and coerced administrators.
Selecting an Active Directory Structure Based on Delegation Requirements
The following steps can assist you in determining if your organization's specific delegation requirements justify delegating control of a separate forest, domain, or organizational unit (OU):
Begin by placing all organizations in a single-domain forest.
For each business unit with unique administrative requirements, determine the appropriate level of autonomy, based on the autonomy and isolation characteristics in Table 3.
When recording the justification for each decision, note whether:
Delegation is driven by an organizational, operational, legal, or other requirement, as defined in Table 2.
The requirement pertains to delegation of service management, data management, or both.
The requirement indicates the need for autonomy, isolation, or both.
For additional assistance in planning Active Directory delegation of administration, see "Design Considerations for Delegation of Administration in Active Directory" on the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=10516.
Implications for Active Directory in Extranet Deployment
Outward-facing domain controllers in an extranet are in a portion of the network where customers and partners can access network resources through the Internet. As a result of the Internet exposure, any information about the corporate forest that is placed in the extranet is subject to the risks of information disclosure or data tampering by external users. Further, a breach of service administration security in the extranet can be used to breach the corporate intranet, if there is no service isolation boundary.
To mitigate the risks previously discussed, Active Directory implementations in an extranet should maintain complete service isolation from the rest of the organization. Therefore, a separate Active Directory forest should be implemented for the extranet. Any service administrator with responsibilities that span the corporate forest and the extranet forest should have a separate administrative account in each forest.
Establishing Secure Collaboration with Other Directories
External trusts between domains are created to support collaboration between domains in different forests for a variety of reasons, including:
Organizational mergers and acquisitions
Limited collaboration between isolated forests within an organization
Shared applications that are accessed from an application forest
Collaboration between domains in different forests can range from simply sharing e-mail to providing access to data and resources. External trusts in Active Directory extend the use of security principals that are created in one domain of a forest to domains in other forests. However, external trusts introduce a potential security risk, because they cross security boundaries. External trusts, therefore, have security implications that require careful consideration.
Establishing External Trusts
Although domains that do not mutually trust one another cannot reside in a single forest, domains in different forests can selectively choose to trust one another. A number of scenarios, including the need for service isolation, can result in an organization or partnership spanning multiple forests. A domain administrator in one forest can manually create external trust relationships with domains in other forests. In some cases, plans may call for maintaining separate forests with trust relationships to facilitate collaboration. In other cases, plans may exist to merge forests eventually. In the case of either migration or collaboration, trust relationships linking domains in different forests may be necessary.
Because every security principal has a unique security identifier (SID) that is relative to the domain in which the security principal is created, it is not possible to move the security principal between domains when an account migration is required. Such a move requires that the security principal be recreated in the new domain, and therefore it must be assigned a new SID. To preserve access to all the applications, services, and resources that are in place for the migrated user, Active Directory provides an attribute for user objects and group objects called SIDHistory.
SIDHistory is a multivalued attribute that contains the list of SIDs previously assigned to a user or group. These SIDs become part of the authorization data that is forwarded to a trusting domain through an external trust.
When a user logs on to a domain, the user's primary SID and the SIDs of groups of which the user is a member are determined by a domain controller in the user's account domain. If the authenticating domain controller is running Windows 2000 in native mode, it also determines if the user has any values present in the SIDHistory attribute, and it includes those SIDs in the authorization data. From the access control perspective, these SIDs are no different from other group SIDs, which gives the user access to resources to which those groups have access.
Blocking SIDs from Untrusted Sources
By design, a Windows 2000 domain controller expects any domain controller in a trusted domain to provide the correct authorization data for a user from that trusted domain. In the process, the domain controller in the trusting domain accepts all the SIDs that are returned during authentication, based on the trust relationship.
Accepting all SIDs exposes the trusting domain to potential security threats, because:
Although the authenticating domain may be trusted, a user's SIDHistory might contain SIDs based on other domains that are not trusted.
If a properly chosen SID can be added to a user's SIDHistory, that user can gain unauthorized access to resources in the trusting domain, including administrative privileges, which constitutes an elevation-of-privilege threat.
Note: Exploiting this vulnerability would be a challenge. At a minimum, an attacker needs administrative credentials on the trusted domain and the technical ability to modify low-level operating system functions and data structures. Microsoft is not currently aware of any programming interface that allows an attacker - even one with administrative credentials - to introduce a SID into SIDHistory.
To mitigate the threat posed by SIDHistory, the domain controllers in the trusting domain should filter authorization data to remove any SIDs that are not relative to the user's account domain. The trusted domain in this case is said to be quarantined. Quarantining is performed from the trusting domain on a per domain (and, therefore, per external trust) basis. The trusting domain should only quarantine domains residing in a different forest.
Important: You should not attempt to use the SID filtering feature to create a "restricted-access" domain within a forest. Enabling SID filtering between domains in the same forest disrupts the default trust and authentication behavior of a forest, and it is likely to lead to problems with programs and the Active Directory service itself that are difficult to troubleshoot.
Unfortunately, SID filtering may cause users in a trusted domain that were migrated to the trusted domain to lose access to resources, because SID filtering prevents users from accessing resources if the access is based on a previous domain account SID. To eliminate this issue, the access control lists (ACLs) on resources should be updated as soon as possible to preserve resource access for migrated users.
The procedure for "Enabling SID Filtering" is included in "Appendix: Procedures" later in this guide.
For more information about applying SID filtering, see the following articles in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=16462:
Q289243, "Forged SID Could Result in Elevated Privileges in Windows 2000"
Q289246, "Forged SID Could Result in Elevated Privileges in Windows NT"
Recommendations: Establishing Secure Active Directory Boundaries
To help maintain secure Active Directory boundaries, consider implementing the security recommendations that are described earlier in this section. The following tables contain checklists that summarize the security recommendations for establishing and maintaining secure Active Directory boundaries in Windows 2000.
Recommendations for Specifying Security and Administrative Boundaries
The following table provides a checklist of recommendations that are related to security and administrative boundaries.
Check |
Determining Your Organization's Need for Delegation of Administration |
---|---|
|
Delegate Active Directory administration in accordance with your organization's need for autonomy and isolation. |
|
Place outward-facing domain controllers that are deployed in an extranet in a separate forest. |
Recommendations for Establishing Secure Collaboration with Other Directories
The following table provides a checklist of recommendations for creating secure trusts with domains in other forests.
Check |
Establishing External Trusts and Blocking SIDs from Untrusted Sources |
---|---|
|
Enable SID filtering when you create an external trust between domains in isolated forests. |
Chapter 3: Deploying Secure Domain Controllers
The Active Directory executables and database are stored on the domain controllers in your Active Directory infrastructure. The domain controllers are the servers in your network infrastructure that you must secure to protect Active Directory. If the security of any domain controller in your Active Directory infrastructure is compromised, the entire Active Directory security is at risk.
An essential part of deploying your domain controllers is ensuring that they are deployed securely. If you are in the process of deploying your domain controllers, the steps in this section include recommendations for deploying your domain controllers in a manner that enhances their security. If you have already deployed your domain controllers, consider whether to configure your existing domain controllers to reflect the security recommendations in this section.
To deploy secure domain controllers, perform the following tasks:
Establish secure domain controller build practices.
Ensure predictable, repeatable, and secure domain controller deployments.
Enable only essential services.
Secure domain controller files and executables.
Run virus scans on domain controllers.
Maintain physical security.
Establishing Secure Domain Controller Build Practices
One of the essential practices in deploying secure domain controllers is building the domain controllers in as secure an environment as possible. Building the domain controllers is the process of installing the Windows 2000 Server operating system and then promoting the server to a domain controller. The physical environment and the method that you use for building domain controllers influence the security of the domain controllers.
Secure domain controller build practices include the following:
Securing the domain controller build environment
Selecting secure domain controller build methods
Securing the Domain Controller Build Environment
The domain controller build environment is the network environment (routers, network segments, switches, and so forth) and physical room (datacenter, secured room, wiring closet, utility closet, and so forth) in which you build your domain controllers. Depending on your IT organizational infrastructure, you may have a centralized datacenter that is secure, both from a network perspective and physically. On the other hand, your IT organization infrastructure may have locations that are not secure from either perspective, such as branch offices.
Building Domain Controllers in Datacenter Environments
Whenever possible, build your domain controllers in a secure environment, such as a datacenter. Building your domain controllers in a secure datacenter environment reduces the security risks by restricting domain controller access to trusted personnel during the critical build process. This helps to prevent rogue applications, drivers, services, or configurations from being introduced by unauthorized personnel.
If possible, build domain controllers in the datacenter environment, and then ship them to the final location for deployment. This deployment approach is referred to as a staged domain controller deployment.
To help ensure that the domain controller stays secure until deployment, ship the domain controller to the final location using a trusted shipping method, for example, one that requires signatures for the domain controller at the origination and destination locations. Building and shipping the domain controller in this way enhances the integrity of the domain controller.
For more information about building (staging) domain controllers, see the "Active Directory Branch Office Planning Guide"* *on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkID=3459.
Building Domain Controllers in Branch Office Environments
If your organization supports branch offices, in some instances you may need to build a domain controller in this relatively insecure environment. For example, you may need to replace a failed domain controller on-site. Table 4 lists recommendations and the corresponding rationales for building domain controllers in branch offices.
Table 4 Recommendations for Building Domain Controllers in Branch Offices
Recommendation |
Rationale |
---|---|
Limit physical access to domain controllers to trusted personnel only. |
To avoid the theft of directory data or the possibility of an altered, less secure domain controller configuration through human intervention, domain controllers should not be left unattended. |
Use an automated method for operating system installation and Active Directory promotion. |
Domain controllers should be promoted using an automated script to reduce the possibility of human intervention, which could result in a vulnerable domain controller configuration. |
Promote and operate new domain controllers in a restricted access area. |
To prevent unauthorized users from compromising the domain controller's security, the domain controller should be physically located in a room with restricted access. |
Selecting Secure Domain Controller Build Methods
Automating the build process for domain controllers minimizes the possible introduction of rogue programs, rogue services, and insecure configuration into the build process through manual intervention. Automating the installation of Windows 2000 Server helps to ensure a secure platform on which to run Active Directory. Automate the promotion of a server to a domain controller through the use of the Active Directory Installation Wizard (Dcpromo.exe) to ensure that Active Directory is configured in a secure and consistent manner.
Automating the Windows 2000 Installation Process
Automated installation processes for Windows 2000 Server can be categorized as image-based and non-image-based. Because non-image-based methods can affect the integrity and predictability of the installation process as a result of the need for manual intervention, we recommend using only image-based methods for installing Windows 2000 Server.
When using an image-based process to install Windows 2000 Server, perform the following tasks:
Create a clean installation of Windows 2000 Server.
Configure server security as specified in the following sections, which appear later in this guide:
"Ensuring Predictable, Repeatable, and Secure Domain Controller Deployments"
"Enabling Only Essential Services"
"Securing Domain Controller Files and Executables."
Configure the computer to run Dcpromo.exe when it starts for the first time. For more information, see "Automating the Promotion of Servers to Domain Controllers" later in this guide.
Create an image of that computer.
Deploy the image to the target computer using one of the methods listed below.
Configure computer-specific settings, such as the computer name and IP addresses, on the newly imaged computer.
You can use one of the following image-based methods for the automated installation of Windows 2000 Server:
SYSPREP
Remote Installation Services (RIS)
Third-party tools
If you must use a non-image-based method, unattended setups generally present few security risks and provide consistent server configuration.
SYSPREP, RIS, and unattended setup are Windows 2000 features. Table 5 compares and contrasts SYSPREP, RIS, and unattended setup. Third-party tools have some combination of the features found in each of these technologies. For further information about third-party automated setup software that may be used by your organization, see the documentation that accompanies the software.
Table 5 Comparison of Windows 2000 Automated Installation Methods
Characteristics |
SYSPREP |
RIS |
Unattended Setup |
---|---|---|---|
Provides image-based installations |
• | • | |
Allows a variety of hardware configurations from a single automation script or image |
• | • | |
Requires high-bandwidth, well-connected network infrastructure |
• | ||
Appropriate for datacenter deployments |
• | • | |
Appropriate for branch office deployments |
• | • |
For more information about SYSPREP, RIS, and unattended setup, see "Automating Server Installation and Upgrade" in the Windows 2000 Server Deployment Planning Guide of the Microsoft® Windows® 2000 Server Resource Kit at: https://go.microsoft.com/fwlink/?LinkId=18578.
Automating the Promotion of Servers to Domain Controllers
The Active Directory Installation Wizard (Dcpromo.exe), which is used to promote domain controllers, can be automated through the use of an answer file. Automating the promotion process generally increases its predictability and consistency by eliminating the need for manual intervention. When running Dcpromo.exe, use the following command:
dcpromo.exe /answer:answer_file_name
You can automatically start Dcpromo.exe after you complete the installation of Windows 2000 Server by running this command the first time the server starts. Automatically starting Dcpromo.exe ensures that the promotion to a domain controller occurs immediately after the implementation of Windows 2000 Server. This reduces the potential for the introduction of unauthorized files or executables before the server is promoted. Configure the server to automatically start Dcpromo.exe just before making your image.
Automatically start Dcpromo.exe the first time the server starts, following the installation of Windows 2000, by using one of the following methods:
For third-party tools or RIS-based deployments, add the following entry under the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce:
Entry name: dcprom Data type: REG_SZ Value: dcpromo.exe
Caution: Do .tdnot edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
For SYSPREP, modify the [GuiRunOnce] section of the Sysprep.inf answer file before running SYSPREP.
The following is an example of a Sysprep.inf answer file that is modified to start Dcpromo.exe automatically the first time the server starts:
[GuiRunOnce] Command0 = "dcpromo /answer:ansfile.txt"
If you are creating an image of a server that you plan to use for imaging multiple domain controllers, place the Dcpromo.exe answer file on a floppy disk so that one image can be used to deploy all domain controllers. Also, ensure that the Dcpromo.exe answer file path designates the floppy disk drive.
Important: Because the Dcpromo.exe answer file is stored on the floppy disk in plaintext, do not include an administrative account name or a password in this file. This information must be entered during the automated domain controller promotion process. The answer file automatically provides all other parameters.
For more information about automating the promotion of servers to domain controllers, see "Automating Server Installation and Upgrade" in the Windows 2000 Server Deployment Planning Guide of the Windows 2000 Server Resource Kit on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=18578.
Ensuring Predictable, Repeatable, and Secure Domain Controller Deployments
Throughout the domain controller deployment process, there are security configuration settings that you need to apply to all domain controllers. To ensure that these security settings are applied uniformly to all domain controllers, implement a predictable, repeatable domain controller deployment process by performing the following tasks:
Install Windows 2000 Server with the latest service packs and hotfixes.
Disable NTFS automatic 8.3 name generation.
Run virus-scanning software on the server.
Select secure domain controller promotion settings.
Prohibit the use of cached credentials when unlocking a domain controller console.
Create a reserve file to enable recovery from potential disk-space, denial-of-service attacks.
Installing Windows 2000 Server with Service Packs and Hotfixes
When you create the first master image of a secure Windows 2000 server to be used for installing and promoting multiple domain controllers, apply the configuration settings that are listed in Table 6 to enhance security.
In situations where your domain controllers already exist, check these recommendations and modify domain controller configurations accordingly.
Table 6 Configuration Settings for Windows 2000 Servers
Setting |
Rationale |
---|---|
Format all partitions as NTFS. |
NTFS provides a secure file system. |
Install only TCP/IP as the transport protocol. |
Limiting transport protocols reduces the attack surface on the domain controller. |
Do not install Internet Information Services (IIS); remove its default selection during Windows 2000 Server setup. |
IIS is not required for domain controller operations. Eliminating IIS on dedicated domain controllers reduces the attack surface. |
Do not install Simple Mail Transfer Protocol (SMTP) during Windows 2000 Server setup unless you are using SMTP for Active Directory intersite replication. |
SMTP is not required for normal domain controller operations unless it is used for intersite replication. This recommendation reduces the attack surface on the domain controller. |
Do not install Indexing Service; remove its default selection during Windows 2000 Server setup. |
Indexing Service is not required for domain controller operations. Inadvertently indexing files can make the location and content of the files available through Web query interfaces. This recommendation reduces the attack surface on the domain controller. |
Install Domain Name System (DNS) by selecting it during Windows 2000 Server setup. |
Installing DNS during Windows 2000 Server setup ensures that DNS is available in the master image. |
Use a strong password for the computer local administrator account. |
A strong password reduces the threat of spoofing this administrator account, which becomes the domain "Administrator" account after the server is promoted to a domain controller. |
Creating a Strong Administrator Password
A strong password minimizes the threat of an attacker guessing (cracking) the password and acquiring the credentials of the administrator account (spoofing). A strong password includes all of the following characteristics:
Contains at least nine characters.
Does not contain an account name, real name, or company name.
Does not contain a complete dictionary word.
Is significantly different from previous passwords. Passwords that increment (Password1, Password2, Password3 ...) are not strong.
Contains at least one symbol in the first seven characters.
Contains characters from each of the groups listed in Table 7.
Table 7 Groups of Characters to Include in Strong Passwords
Uppercase letters
A, B, C ...
Lowercase letters
a, b, c ...
Numerals
0, 1, 2, 3, 4, 5, 6, 7, 8, 9
Symbols found on the keyboard (all keyboard characters not defined as letters or numerals)
` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : " ; ' < > ? , . /
Examples of strong passwords are Pa$sw0rD1 and J*p2leO4>F.
After you complete the installation of Windows 2000 Server, obtain any additional security protections that may have been implemented for Windows 2000 Server by applying the most recent service packs and security-related hotfixes from the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=102.
Disabling NTFS Automatic 8.3 Name Generation
Many viruses and utilities that are used by attackers are 16-bit applications that expect 8.3compatible file names. Secure domain controllers do not run 16-bit applications locally. Therefore, disable 8.3 automatic name generation to prevent these viruses and utilities from compromising your domain controller security.
Disable automatic 8.3 name generation by setting the following entry under the registry key HKLM\SYSTEM\CurrentControlSet\Control\FileSystem:
Entry name: NtfsDisable8dot3NameCreation Data type: REG_DWORD Value: 1
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
You can create a script that disables automatic 8.3 name generation on all domain controllers in the domain automatically by performing the following tasks:
Create the ComputerSearch.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Identifying Computers to Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B: Procedures" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.
Create a list of domain controllers in the domain by typing the following command at a command prompt:
Cscript computersearch.vbs /r:DC
This command creates a list of domain controllers in the domain and saves this list as *ComputerSearch-date-time.csv*.
Create the ApplyReg.vbs script and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Applying Registry Settings to a List of Computers with ApplyReg.vbs" in "Appendix B: Procedures" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.
Create a .reg file for the following path, registry entry, and value:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem] "NtfsDisable8dot3NameCreation"=dword:00000001
Save the file as *Registryfile*.reg. For information about how to create the .reg file, see "Creating a .reg File" in "Appendix: Procedures" of this guide:
Apply the registry entry to the domain controllers by typing the following command at the command prompt:
Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-date-time.csv
This task applies the registry changes that are expressed in the file *Registryfile*.reg to all computer that are listed in the file ComputerSearch-*date*-*time*.csv.
Running Virus-Scanning Software on the Server
After you install Windows 2000 Server, but before you promote the server to a domain controller, install and run antivirus software on the domain controller to ensure that no viruses have been introduced during the installation of Windows 2000 Server.
For image-based methods of automating the installation of Windows 2000 Server, make sure that you install the virus-scanning software as part of the image. For other methods, install and run the virus scanning software immediately after installing Windows 2000 Server.
Note: If you are automatically starting Dcpromo.exe by using one of the RunOnce methods discussed later in this section, modify your scripts to run the virus-scanning software first and then automatically start Dcpromo.exe.
Selecting Secure Domain Controller Promotion Settings
During domain controller promotion, a number of configuration settings should be applied to the server to enhance security. These settings are specified in the Dcpromo.exe answer file.
Note: Many of the configuration settings that are required for domain controller promotion depend on whether you are installing the first domain controller or an additional domain controller in the forest or domain. If you are installing the first domain controller in the forest or domain, the configuration settings in the Dcpromo.exe answer file are different from the settings that are required for adding a domain controller to an existing domain.
Specifying Locations for the Active Directory Database, Logs, and SYSVOL
By default, Dcpromo.exe places the database, log files, and SYSVOL folder on the system volume. During the promotion of a server to a domain controller, the Dcpromo.exe answer file can specify an alternative location for the Active Directory database (Ntds.dit), log files, and SYSVOL folder. Table 8 provides recommended alternative locations for these Active Directory components for enhanced security and improved performance.
Table 8 Recommended Drive Locations for Active Directory Components
Recommendation |
Security Rationale |
---|---|
Place the database and SYSVOL folder on the same dedicated physical drive that does not contain the system volume. |
|
Place the log files on a dedicated physical drive that does not contain the system volume. |
|
On existing domain controllers, move the Active Directory database, log files, and SYSVOL folder to a dedicated physical drive, for the reasons described in Table 8.
For information about:
Moving the database and log files, see "Moving the Directory Database Files to a Local Drive" in the Active Directory Operations Guide at https://go.microsoft.com/fwlink/?LinkId=18545.
Moving the SYSVOL folder, see "Moving SYSVOL Manually" in the Active Directory Operations Guide at https://go.microsoft.com/fwlink/?LinkId=18545.
Disabling Pre-Windows 2000 Compatibility
During the promotion of the first domain controller in a domain, one optional configuration setting that significantly affects Active Directory security is "Permissions compatible with pre-Windows 2000 servers." This setting enables Pre-Windows 2000 Compatibility for certain applications that need to query the directory using anonymous access.
Applications or services that may query the directory using anonymous access include those applications or services that run in the security context of Local System:
On a server running Windows NT 4.0 within or outside the forest.
On a server running Windows 2000 in a trusting domain outside the forest.
An example of such an application or service is the Routing and Remote Access Service (RRAS) running on Windows NT 4.0.
In Active Directory, the group Pre-Windows 2000 Compatible Access is assigned Read permissions on the domain root, as well as on all user, computer, and group objects. When you enable Pre-Windows 2000 Compatibility, the special group Everyone is added as a member of the Pre-Windows 2000 Compatible Access group. Because Everyone includes anonymous users, in addition to authenticated users, anyone with network access can read these objects.
When this setting is enabled, any user with network access, even one without an account in the forest, can query and discover information about Active Directory users, groups, and computers. If you do not have applications that require Active Directory access enabled for Pre-Windows 2000 Compatibility, you should not select this setting during domain controller promotion.
Note: By default, the setting Permissions compatible with pre-Windows 2000 servers is selected in the Active Directory Installation Wizard.
Analyzing the Need for Pre-Windows 2000 Compatibility
Disable Pre-Windows 2000 Compatibility, unless your applications require anonymous access to Active Directory. Before deploying a production domain, you need to know whether it will be possible to disable Pre-Windows 2000 Compatibility. During the lab testing phase of your deployment, determine the applications that require anonymous access by performing the following tasks:
When deploying the first domain controller in your test domain, select Permissions compatible with pre-Windows 2000 servers.
Include at least one instance of each application running in your organization.
Enable security auditing on all domain controllers in the test domain to monitor anonymous access to the directory. Collect security logs for 30 days.
For additional information about performing this task, see "Enabling Monitoring for Anonymous Access" in "Appendix: Procedures" later in this guide.
Analyze the security logs for computers that initiate anonymous access to the directory.
For additional information about performing this task, see "Monitoring for Anonymous Access" in "Appendix: Procedures" later in this guide.
Identify the applications or services running on the computers from which anonymous access was initiated.
Note: Access to resources between domains that are connected by an external trust requires Pre-Windows 2000 Compatibility. Because external trusts only support NTLM authentication, queries to a directory in a different forest are always handled as anonymous access.
After you have determined the applications that require anonymous access, determine if the applications can be upgraded to versions that do not require anonymous access. After upgrading the applications to newer versions, verify that the applications no longer require anonymous access in your lab environment.
Typically, a newer version of the software, for example, Routing and Remote Access in Windows 2000, does not require anonymous access. Whenever possible, upgrade to a newer version of the software running on Windows 2000 or later operating systems so that you can disable Pre-Windows 2000 Compatibility.
Prohibiting the Use of Cached Credentials When Unlocking a Domain Controller Console
When the console on a domain controller is locked, either by the action of a user or automatically by a screensaver time-out, the console must be unlocked to regain access to the domain controller. The domain controller maintains cached credentials for any users that have been authenticated locally. When the console is unlocked, by default the domain controller uses these cached credentials, if they exist, for the user who attempts to unlock the console.
When cached credentials are used to unlock the console, any changes to the account, such as user rights assignment, group membership changes, or disabling of the account, are not enforced. For example, if an administrator, who is logged on to a domain controller console, is terminated, he can still unlock the console, even if his account is disabled. To ensure that any changes to the account are enforced immediately, require domain controller authentication of the account to unlock the console, instead of cached credentials.
You can configure the domain controller to require domain controller authentication to unlock the domain controller console by adding or modifying the following entry under the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
Entry name: ForceUnlockLogon Data type: REG_DWORD Value: 1
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
You can create a script that specifies automatically that domain controller authentication is required to unlock any domain controllers in the domain by performing the following tasks:
Create the ComputerSearch.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Identifying Computers to Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B: Procedures" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.
Create a list of domain controllers in the domain by typing the following command at a command prompt:
Cscript computersearch.vbs /r:DC
This command creates a list of domain controllers in the domain and saves this list as ComputerSearch*-date-time.*csv.
Create the ApplyReg.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Applying Registry Settings to a List of Computers with ApplyReg.vbs" in "Appendix B: Procedures" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.
Create a .reg file for the following path, registry entry, and value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "ForceUnlockLogon"=reg_dword:00000001
Save the file as *Registryfile*.reg. For information about how to create the .reg file, see "Creating a .reg File" in "Appendix: Procedures" of this guide.
Apply the registry entry to the domain controllers by typing the following command at the command prompt:
Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-date-time.csv
This set of tasks applies the registry changes that are expressed in the file *Registryfile*.reg to all computers that are listed in the file ComputerSearch-*date*-*time*.csv.
Creating a Reserve File to Enable Recovery from Disk-Space Attacks
Many security attacks attempt to consume the system resources of the targeted system. One of the commonly attacked system resources is available disk space. Available disk space can be exhausted by the addition of a large number of objects to the directory by a malicious user or administrator. Active Directory requires that deleted objects continue to exist in the directory as tombstones for an extended period of time to allow the deletion to replicate. Therefore, the disk space that is consumed by the deleted objects cannot be reclaimed until the tombstone lifetime has expired (by default, 60 days).
One way of mitigating the effects of this type of attack is by implementing preventive measures. You can provide for a fast recovery by creating a reserve file on the same disk volume as the Active Directory database (Ntds.dit file). A reserve file is simply a large file that takes up available disk space. In the event that an attacker exhausts all disk space by adding a large number of objects to the directory, you can delete the reserve file to quickly restore normal operation while the rogue objects inside Active Directory are identified and removed. For a procedure for performing this task, see "Creating a Reserve File" in "Appendix: Procedures" later in this guide.
Enabling Only Essential Services
Every service running on a domain controller provides a potential target for an attack that can compromise domain controller security. Therefore, it is prudent to enable only those services that are essential to normal domain controller function, so that you can reduce the surface area of attack. Table 9 lists the services that are installed during Windows 2000 Server installation if you follow the security recommendations provided in "Installing Windows 2000 Server with Service Packs and Hotfixes" earlier in this guide. Table 9 also provides the recommended startup type for each service to be configured.
Note: For new domain controller deployments, configure these service startup types before creating the master image for image-based deployments, as discussed in "Automating the Windows 2000 Installation Process" earlier in this guide.
Table 9 Recommended Services to Install on Windows 2000 Server
Service Name |
Default Startup Type |
Recommended Startup Type |
Comment |
---|---|---|---|
Alerter |
Automatic |
(No change) |
Notifies selected users and computers of administrative alerts. |
Application Management |
Manual |
(See comment) |
Provides software installation services for applications that are deployed through Add/Remove Programs. On dedicated domain controllers, this service can be disabled to prevent unauthorized installation of software. |
Automatic Updates |
Automatic |
(See comment) |
Provides the download and installation of critical Windows updates, such as security patches or hotfixes. This service can be disabled when automatic updates are not performed on the domain controller. It is included when Service Pack 3 (SP3) is applied. |
Background Intelligent Transfer Service |
Manual |
(See comment) |
Provides a background file transfer mechanism and queue management, and it is used by Automatic Update to automatically download programs, such as security patches. This service can be disabled when automatic updates are not performed on the domain controller. It is included when SP3 is applied. |
ClipBook |
Manual |
(See comment) |
Enables the Clipbook Viewer to create and share "pages" of data to be reviewed by remote users. On dedicated domain controllers, this service can be disabled. |
COM+ Event System |
Manual |
(No change) |
Provides automatic distribution of events to COM components. |
Computer Browser |
Automatic |
(See comment) |
Maintains the list of computers on the network, and supplies the list to clients that request the list. If you do not have earlier versions of clients that use this feature, set to Manual. |
DHCP Client |
Automatic |
(See comment) |
Updates DNS records using Dynamic update. If your organization does not use dynamic IP addresses for domain controllers, set to Manual. |
Distributed File System |
Automatic |
(No change) |
Manages logical volumes that are distributed across a local area network (LAN) or wide area network (WAN), and it is required for the Active Directory SYSVOL share. |
Distributed Link Tracking Client |
Automatic |
Disabled |
Maintains links between NTFS v5 file system files on the domain controllers and other servers in the domain. Disable this service on dedicated domain controllers. |
Distributed Link Tracking Server |
Manual |
Disabled |
Tracks information about files that are moved between NTFS v5 volumes throughout a domain. Disable this service on dedicated domain controllers. |
DNS Client |
Automatic |
(No change) |
Allows resolution of DNS names. |
DNS Server |
Automatic |
(No change) |
Required for Active Directory-integrated DNS zones. |
Event Log |
Automatic |
(No change) |
Writes event log messages that are issued by Windows-based programs and components to the log files. |
Fax Service |
Manual |
Disabled |
Provides the ability to send and receive faxes through fax resources that are available on the domain controller and the network. On dedicated domain controllers, this service can be disabled, because sending and receiving faxes is not a normal function of a domain controller. |
File Replication Service |
Manual |
(No change) |
Enables files to be automatically copied and maintained simultaneously on multiple computers, and it is used to replicate SYSVOL among all domain controllers. |
Indexing Service |
Manual |
(See comment) |
Indexes content and properties of files on the domain controller to provide rapid access to the file through a flexible querying language. On dedicated domain controllers, disable this service to prevent users from searching files and file content if sensitive files and folders are inadvertently indexed. |
Internet Connection Sharing |
Manual |
Disabled |
Provides network address translation (NAT), addressing and name resolution, and intrusion detection when connected through a dial-up or broadband connection. On dedicated domain controllers, disable this service to prevent inadvertent enabling of NAT, which would prevent the domain controller from communicating with the remainder of the network. |
Intersite Messaging |
Disabled |
(No change) |
Required by SMTP replication in Active Directory, Distributed File System (DFS), and Netlogon. |
IPSEC Policy Agent |
Automatic |
(See comment) |
Provides management and coordination of Internet Protocol security (IPSec) policies with the IPSec driver. If your organization does not use IPSec, set the startup type to Manual. |
Kerberos Key Distribution enter |
Disabled |
(No change) |
Provides the ability for users to log on using the Kerberos V5 authentication protocol. |
License Logging Service |
Automatic |
(See comment) |
Monitors and records client access licensing for portions of the operating system, such as IIS, Terminal Services, and file and print sharing, and for products that are not a part of the operating system, such as Microsoft® SQL Server or Microsoft® Exchange Server. On a dedicated domain controller, this service can be disabled. |
Logical Disk Manager |
Automatic |
(No change) |
Required to ensure that dynamic disk information is up to date. |
Logical Disk Manager Administrative Service |
Manual |
(No change) |
Required to perform disk administration. |
Messenger |
Automatic |
(See comment) |
Transmits net sends and Alerter service messages between clients and servers. If your organization does not use this feature, set the startup type to Manual. |
Net Logon |
Manual |
(No change) |
Maintains a secure channel between the domain controller, other domain controllers, member servers, and workstations in the same domain and trusting domains. |
NetMeeting Remote Desktop Sharing |
Manual |
Disabled |
Eliminates a potential security threat by allowing domain controller remote administration through NetMeeting. |
Network Connections |
Manual |
(No change) |
Manages objects in the Network Connections folder. |
Network DDE |
Manual |
(See comment) |
Provides network transport and security for Dynamic Data Exchange (DDE) for programs running on the domain controller. This service can be disabled when no DDE applications are running locally on the domain controller. |
Network DDE DSDM |
Manual |
(See comment) |
Used by Network DDE. This service can be disabled when Network DDE is disabled. |
NTLM Security Support Provider |
Manual |
(No change) |
Provides security to remote procedure call (RPC) programs that use transports other than named pipes, and enables users to log on using the NTLM authentication protocol. |
Performance Logs and Alerts |
Manual |
(See comment) |
Collects performance data for the domain controller, writes the data to a log, or generates alerts. This service can be set to automatic when you want to log performance data or generate alerts without an administrator being logged on. |
Plug and Play |
Automatic |
(No change) |
Automatically recognizes and adapts to changes in the domain controller hardware with little or no user input. If your organization does not change hardware on domain controllers, set the startup type to Manual. |
Print Spooler |
Automatic |
(See comment) |
Manages all local and network print queues, and controls all print jobs. Can be disabled on dedicated domain controllers where no printing is required. |
Protected Storage |
Automatic |
(No change) |
Protects storage of sensitive information, such as private keys, and prevents access by unauthorized services, processes, or users. This service is used on domain controllers for smart card logon. |
QoS RSVP |
Manual |
(See comment) |
Provides support for Quality of Service (QoS) Resource Reservation Protocol (RSVP) routing information. This service can be disabled when QoS is not used to allocate network bandwidth in network infrastructure. |
Remote Access Auto Connection Manager |
Manual |
(See comment) |
Detects unsuccessful attempts to connect to a remote network or computer, and provides alternative methods for connection. This service can be disabled on dedicated domain controllers where no virtual private network (VPN) or dial-up connections are initiated. |
Remote Access Connection Manager |
Manual |
(See comment) |
Manages VPN and dial-up connection from the domain controller to the Internet or other remote networks. This service can be disabled on dedicated domain controllers where no VPN or dial-up connections are initiated. |
Remote Procedure Call (RPC) |
Manual |
(No change) |
Serves as the RPC endpoint mapper for all applications and services that use RPC communications. |
Remote Procedure Call (RPC) Locator |
Automatic |
(No change) |
Enables RPC clients using the RpcNs* family of application programming interfaces (APIs) to locate RPC servers and manage the RPC name service database. |
Remote Registry Service |
Automatic |
(No change) |
Enables remote users to modify registry settings on the domain controller, provided that the remote users have the required permissions. By default, only Administrators and Backup Operators can access the registry remotely. |
Removable Storage |
Automatic |
(See comment) |
Manages and catalogs removable media, and operates automated removable media devices, such as tape auto loaders or CD jukeboxes. This service can be disabled when removable media devices are not directly connected to the domain controller. |
Routing and Remote Access |
Disabled |
(No change) |
Enables LAN-to-LAN, LAN-to-WAN, VPN, and NAT routing services. |
RunAs Service |
Automatic |
(No change) |
Allows you to run specific tools and programs with different privileges than your current logon provides. |
Security Accounts Manager |
Automatic |
(No change) |
A protected subsystem that manages user and group account information. |
Server |
Automatic |
(No change) |
Provides RPC support, file print, and named pipe sharing over the network. |
Smart Card |
Manual |
(No change) |
Manages and controls access to a smart card that is inserted into a smart card reader that is attached to the domain controller. |
Smart Card Helper |
Manual |
(No change) |
Provides support for legacy, non-plug-and-play smart card readers. |
System Event Notification |
Automatic |
(No change) |
Monitors system events and notifies subscribers to the COM+ Event System of these events. |
Task Scheduler |
Automatic |
(No change) |
Provides the ability to schedule automated tasks on the domain controller. |
TCP/IP NetBIOS Helper Service |
Automatic |
(No change) |
Provides support for the NetBIOS over TCP/IP (NetBT) service and network basic input/output system (NetBIOS) name resolution for clients. |
Telephony |
Manual |
(See comment) |
Provides Telephony API (TAPI) support of client programs that control telephony devices and IP-based voice connections. This service can be disabled on dedicated domain controllers where TAPI is not used by applications. |
Telnet |
Manual |
Disabled |
Enables a remote user to log on and run applications from a command line on the domain controller. Enable Telnet only when it is used for remote administration for branch offices or remotely administered domain controllers. Terminal Services is the recommended method for remote administration. |
Terminal Services |
Disabled |
(See comment) |
Allows multiple remote users to be connected interactively to the domain controller, and provides display of desktops and run applications. To reduce the surface area of attack, disable Terminal Services unless it is used for remote administration for branch offices or remotely administered domain controllers. |
Uninterruptible Power Supply |
Automatic |
(No change) |
Manages an uninterruptible power supply (UPS) that is connected to the domain controller by a serial port. |
Utility Manager |
Manual |
Disabled |
Allows faster access to some accessibility tools, such as Magnifier, Narrator, and On-Screen Keyboard, and also displays the status of the tools or devices that it controls. Disable Utility Manager unless you require these special accessibility tools. |
Windows Installer |
Manual |
(No change) |
Adds, modifies, and removes applications that are provided as a Windows Installer (.msi) package. |
Windows Management Instrumentation |
Manual |
(No change) |
Provides a common interface and object model to access management information about the domain controller through the WMI interface. |
Windows Management Instrumentation Drivers |
Manual |
(No change) |
Monitors all drivers and event trace providers that are configured to publish WMI or event trace information. |
Windows Time |
Manual |
(No change) |
Sets the domain controller clock, and maintains date and time synchronization on all computers in the network. |
Workstation |
Automatic |
(No change) |
Creates and maintains client network connections to remote servers. |
Note: The antivirus software installed earlier in the process describe in this section may run as a service in Windows 2000 Server. Do not change the default configuration of your antivirus software.
Table 10 lists the changes to the service startup configuration when a server running Windows 2000 is promoted to a domain controller. This table is provided as a reference, and you can combine it with the list in Table 9 to arrive at the final list of services to have running on a domain controller.
Table 10 Recommended Changes to Service Startup Type After Promotion to Domain Controller
Service Name |
Default Startup Type |
Recommended Startup Type |
Comment |
---|---|---|---|
Distributed Link Tracking Server |
Automatic |
Disabled |
Tracks information about files that are moved between NTFS v5 volumes throughout a domain. Disable this service on dedicated domain controllers. |
File Replication Service |
Automatic |
(No change) |
Enables files to be automatically copied and maintained simultaneously on multiple computers. This service is used to replicate SYSVOL between all domain controllers. |
Intersite Messaging |
Automatic |
(No changes) |
Required by SMTP replication in Active Directory, DFS, and Netlogon. |
Kerberos Key Distribution enter |
Automatic |
(No change) |
Provides the ability for users to log on using the Kerberos V5 authentication protocol. |
Net Logon |
Automatic |
(No change) |
Maintains a secure channel between the domain controller, other domain controllers, member servers, and workstations in the same domain and in trusting domains. |
Remote Procedure Call (RPC) Locator |
Automatic |
(No change) |
Enables RPC clients using the RpcNs* family of APIs to locate RPC servers and manage the RPC name service database. |
Windows Management Instrumentation |
Automatic |
(No change) |
Provides a common interface and object model to access management information about the domain controller through the WMI interface. |
Windows Time |
Automatic |
(No change) |
Sets the domain controller clock, and maintains date and time synchronization on all computers in the network. |
The recommended services as listed in Table 9 and Table 10 are just the services that are required to support a dedicated domain controller. Although it is recommended that you have only dedicated domain controllers, if your domain controller serves other roles, such as a file server or print server, you may need to enable other services for proper operation.
Securing Domain Controller Files and Executables
When Windows 2000 Server is installed with NTFS partitions, the files and executables on the server are assigned baseline NTFS permissions. After successfully promoting a server to a domain controller, Dcpromo.exe sets secure NTFS permissions on the system files and executables, as well as on Active Directory files and folders.
After promotion to domain controller, the default permissions on the root of each logical disk volume grant Full Control access to the special group Everyone. This causes the root of each disk volume, including the volume housing the Active Directory database files, to be susceptible to disk-space attacks.
To guard against this threat, secure each volume with the additional settings listed in Table 11.
Table 11 Additional Files and Folders to Be Secured After Promotion to Domain Controller
File or Folder |
Permissions |
---|---|
Root of each logical disk volume |
|
Running Virus Scans on Domain Controllers
After domain controllers are promoted, continue to run virus scans and to obtain regular virus signature updates from your antivirus software vendor. Before you initiate regular antivirus scanning, be aware that some antivirus software can interfere with the proper operation of domain controllers by:
Interfering with directory database and log file access by the Extensible Storage Engine (ESE).
Interfering with File Replication service (FRS) database and log file access by ESE.
Causing excessive replication by FRS.
Some versions of antivirus software modify the security descriptor of files during scans. Modifying security descriptors triggers FRS, which creates high volumes of replication traffic unnecessarily. These issues with running antivirus software on domain controllers are addressed by the recommendations in the following three sections.
For more information about using antivirus software on your domain controller, see article 284947, "Antivirus Problems May Modify Security Descriptors Causing Excessive Replication of FRS Data in Sysvol and DFS" in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441.
Preventing Interference Between Virus Scans and Active Directory Database and Log File Access
ESE, which underlies Active Directory, opens database and log files in exclusive mode. This means that if the antivirus software opens one of these files, ESE fails when it tries to open the same file. Alternatively, the antivirus software cannot open these files for scanning if they have already been opened by ESE.
Furthermore, these database and log files have internal checksums that, when altered through file changes by the antivirus software, can cause either an access error to occur or the database to fail on restart or restore. In all cases, this results in Active Directory failing on the domain controller.
To run antivirus software on your domain controllers, configure the antivirus software to exclude from scanning the Active Directory database and log files that are specified in Table 12.
Table 12 Files Not Scanned and Registry Entry Values Specifying Their Location
Exclude from Scan |
In HKLM\System\Services\NTDS\Parameters |
---|---|
Ntds.dit |
DSADatabaseFile |
Edb*.log, Edb*.pat, Res.log, and Res2.log |
DatabaseLogFilesPath |
Temp.edb and Edb.chk |
DSAWorkingDirectory |
Ntds.pat |
DSADatabaseFile |
Note: For Windows Server 2003 and later operating systems, the Ntds.pat file is no longer used. Therefore, it is not an issue when you run antivirus software on those operating systems.
Excluding the files in Table 12 from regular virus scanning does not increase a domain controller's vulnerability to a virus attack. Viruses tend to attach to files that are executed, such as binaries or scripts, rather than to data files. Dedicated domain controllers with no user-modifiable content are therefore less vulnerable to common virus attacks.
Preventing Interference Between Virus Scans and FRS Database and Log File Access
As previously explained for Active Directory database access, either the antivirus software can prevent ESE from opening the FRS database and log files or the other way around. Furthermore, a change in the internal checksums of these files can cause an access error to occur or the database to fail on restart or restore. In all cases, this results in Active Directory failing on the domain controller.
To run antivirus software on your domain controllers, configure the antivirus software to exclude from regular virus scanning the FRS database and log files that are specified in Table 13.
Table 13 Files and Folders Not Scanned and Registry Entry Values Specifying Their Location
Exclude Files from Scan |
In HKLM\System\CurrentControlSet\Services\NtFrs\Parameters |
Jet\sys\edb.chk, |
WorkingDirectoryFile |
Log\*log |
DBLogFileDirectory |
Exclude Folders from Scan |
HKLM\ System\CurrentControlSet\Services\NtFrs\Parameters\ ReplicaSets\GUID |
replica_root |
ReplicaSetRoot |
staging_directory |
ReplicaSetStage |
preinstall_directory |
replica_root\DO_NOT_REMOVE_Ntfrs_Preinstall_Directory |
Preventing Virus Scans from Triggering Excessive FRS Replication
Domain controllers running Windows 2000 use FRS to replicate system policy and logon scripts that reside in the SYSVOL folder. Antivirus software can interfere with the normal functioning of FRS by modifying the security descriptor and the time stamp of files in the SYSVOL folder. This causes FRS to replicate the changes to other domain controllers, which create a high volume of file replication traffic.
Because some antivirus software scans every file and directory in an FRS replicated tree, this action is similar to requesting a full synchronization of all files and folders from every domain controller running the antivirus software. Administrators may see the following symptoms of this problem in their environments:
Files in SYSVOL shares replicate excessively.
Network traffic between replication partners consumes excessive bandwidth.
The number of files in the staging directory constantly grows and then empties sometime after the antivirus scan completes or after FRS replication.
Note: The staging directory behavior changes for Windows Server 2003, Windows 2000 Server SP3 and later. These systems contain an updated FRS version that leaves staging files in place for one week before removing them.
For more information about running antivirus software on domain controllers, see article 815263, "Antivirus, Backup, and Disk Optimization Programs That Are Compatible with the File Replication Service" in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441.
You can prevent antivirus software from causing excessive replication, while continuing to maintain a high level of security on domain controllers, by performing the following tasks:
Configure antivirus software to not scan files in the SYSVOL directory tree.
Require script signing on domain controllers and administrative workstations.
Excluding Antivirus Scanning of SYSVOL
Antivirus software can interfere with the normal functioning of FRS by modifying the security descriptor and time stamp of files in the SYSVOL folder. This triggers FRS to replicate the changes in the SYSVOL folder to other domain controllers, creating a high volume of file replication traffic. The result is excessive FRS replication between domain controllers.
Note: The following antivirus applications do not modify SYSVOL files in a way that triggers excessive replication:
eTRUST Antivirus build 96 or later with the NTFS incremental scan feature disabled
McAfee/NAI NetShield 4.50 with the NetShield Hot Fix Rollup
Norton Antivirus 7.6 or later
To run antivirus software on domain controllers, configure the antivirus software to exclude from scanning the SYSVOL folder its subdirectories.
Requiring Script Signing on Domain Controllers and Administrative Workstations
In contrast to the situation for the directory database and log files, excluding the SYSVOL folder from virus scanning does increase the risk of a virus attack on a domain controller. Viruses tend to attach to files that are executed, such as binaries or scripts. If you exclude the SYSVOL folder from virus scans, you increase the risk of virus attacks on logon scripts and startup scripts in the SYSVOL folder on domain controllers. As a countermeasure, implement script signing to protect the integrity of scripts running on domain controllers and administrative workstations.
Windows 2000 supports the enforcement of script signing to validate the integrity of scripts and binaries before executing them. Establish a practice for your organization that requires all scripts in the SYSVOL folder to be signed. Windows Script Host (WSH) scripts (such as .vbs, .js, and .wmf scripts) can be signed or verified using the same tools that are ordinarily used to sign other executables. The script signer, one of the security tools provided by WinTrust, generates a digital signature of the contents of a script. That information is then formatted as a comment and added to the end of the script.
Note: You can obtain the WinTrust tools for signing and verifying scripts (signcode.exe and chktrust.exe, respectively) in the Windows 2000 Platform Software Development Kit (SDK).
Sign scripts, and verify that the scripts are properly signed, by performing the following tasks on every domain controller and administrative workstation:
To require that only signed scripts be run on a computer, add the following entry under the registry key HKEY_LOCAL_SYSTEM\Software\Microsoft\Windows Script Host*:*
Entry name: TrustPolicy Data type: REG_DWord Value: 2
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
Enroll to acquire a certificate from an internal certification authority (CA).
Choose an internal CA so that confirmation of the current validity of the certificate does not require an Internet lookup. To ensure that the certificate has not been revoked, the code checks the CA's certificate revocation list (CRL).
Secure all scripts by signing.
Two alternatives exist for creating signed scripts. If you are interested in developing your own script host, the Windows Product SDK contains a set of tools for signing scripts (signcode.exe and chktrust.exe). Alternatively, WSH version 5.6 ships with a signer object to sign or verify scripts.
Verify that all scripts are signed.
For the code required to verify that the scripts have been signed, see "Securing Scripts with Script Signing" in "Appendix: Procedures" later in this guide.
Note: As a minimum, you should enforce script signing on domain controllers and administrative workstations. However, it is a best practice recommendation that script signing be enforced on all computers on the network running operating systems that support script signing. Operating systems that support script signing include the Windows 2000 family of operating systems, Windows XP, and the Windows Server 2003 family.
For more information about implementing script signing, see:
"Digital Code Signing Step-by-Step Guide" on the Microsoft MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=18548.
"Windows Script Host: New Code-Signing Features Protect Against Malicious Scripts" on the Microsoft MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=18550.
Note: Batch files cannot be signed; therefore, they are inherently less secure. Convert all batch files to Microsoft® Visual Basic® scripts as soon as possible.
Maintaining Physical Security
All of the descriptions of domain controller security measures in the previous sections assume that the domain controller is physically secure. Physical security ensures that unauthorized users cannot turn the domain controller on or off, add or remove hardware, insert or remove removable media, log on by using the domain controller's keyboard and display, or remove backup media.
To maintain physical security for your domain controllers, perform the following tasks:
Secure domain controllers against physical access.
Prevent domain controllers from booting into alternate operating systems.
Protect domain controllers on restart by using SYSKEY.
Secure backup media against physical access.
Enhance the security of the network infrastructure.
Secure the remote restart of domain controllers.
Securing Domain Controllers Against Physical Access
The first line of defense in maintaining physical security is to secure domain controllers against any attacks that can be accomplished with physical access to the domain controller. Note that changes in the domain controller's environmental conditions, such as power failures, can also compromise the security of the domain controller.
Take the following common security precautions for restricting physical access to the domain controller:
Use UPSs to prevent loss of power.
Place domain controllers and UPSs in a locked room.
Require cardkey locks or cipher-locks on the entrances to the locked room.
Require locks on individual domain controllers or on doors to the racks housing the domain controllers.
Require specific processes and procedures for any administration or repair of the domain controllers.
These security precautions are intended to prevent a potential attacker from gaining physical access to your domain controllers. However, in an environment where these recommendations cannot be strictly enforced, such as in branch offices, additional security measures may be required, as described in the following sections.
Preventing Domain Controllers from Booting into Alternate Operating Systems
A domain controller can be booted into an alternate operating system. For example, public domain drivers exist for MS-DOS that an attacker can use to boot the domain controller and directly access files that are stored on NTFS disk volumes, bypassing existing NTFS permissions. Similar utilities exist for Linux and UNIX operating systems. You can take steps to avoid this type of attack.
To minimize the possibility of domain controllers booting into an alternate operating system:
Disable or remove the floppy disk drive, unless it is required by SYSKEY. For more information, see "Protecting Domain Controllers on Restart Using SYSKEY" later in this guide.
Disable or remove the CD-ROM or DVD drive.
Set the [timeout] parameter in the Boot.ini file to 0.
Disable remote network boot and installation, for example, by RIS or Bootstrap Protocol (BOOTP).
When you are unable to use SYSKEY with a password or floppy disk, require a basic input/output system (BIOS) password to boot the computer.
Protecting Domain Controllers on Restart by Using SYSKEY
In secure datacenter environments, generally, only authorized personnel can restart domain controllers. However, in an environment where these recommendations cannot be strictly enforced, such as in branch offices, there is increased potential for an unauthorized person to restart a domain controller.
An unplanned or unexpected restart of a domain controller can indicate that an attacker has booted the domain controller with an alternate operating system and compromised its security. On the other hand, the restart might simply be due to a loss of power or to scheduled maintenance on the domain controller.
Evaluating the Need for SYSKEY
The system key (SYSKEY) in Windows 2000 protects security information, including passwords in the Active Directory database and other Local Security Authority (LSA) secrets, against offline attacks by encrypting their storage on the domain controller. SYSKEY can either be derived from a secret password that you specify, or it can be stored on offline media, such as a floppy disk. On a domain controller reboot, either the password or the floppy disk containing SYSKEY must be supplied to successfully restart the computer.
Implementing SYSKEY provides two security advantages:
Point-in-time control of the domain controller restart, which evaluates the reason for the domain controller restart and determines if security has been compromised
Protection for passwords that are stored in the directory database against offline attacks if the domain controller or a disk are stolen
You can use the system key utility (Syskey.exe), which is installed on the domain controller during the Windows 2000 Server installation, to select one of these two configurations for the SYSKEY source.
There are certain logistic operational issues involved with the use of SYSKEY:
Management of SYSKEY passwords or floppy disks can present challenges.
Requiring a branch manager or local administrative staff to come to the office at 3 A.M. to enter the passwords or insert a floppy disk might be difficult.
Alternatively, allowing centralized IT operations personnel to provide the SYSKEY password remotely requires additional hardware, such as Compaq Remote Insight Lights-out (RILO) or Dell Remote Access Card (DRAC III) boards. For more information about restarting domain controllers remotely, see "Securing the Remote Restart of Domain Controllers" later in this guide.
Loss of the SYSKEY password or floppy disk leaves the domain controller in a state in which it cannot be restarted.
There is no way to recover a domain controller if the SYSKEY password or floppy disk is lost. In this situation, it would be necessary to rebuild the domain controller.
Selecting a Method for Securing Domain Controller Restarts with SYSKEY
Each method noted in the previous section (specifically, manually entered SYSKEY or SYSKEY supplied on a floppy disk) has advantages and difficulties. If you choose to add SYSKEY protection to your domain controllers, you should first evaluate your security environment to determine which method will work best for you.
Providing SYSKEY Passwords to Secure Domain Controller Restarts
SYSKEY passwords do not require physical media that could be lost, as there are no floppy disks. Trusted personnel must enter a password in the event that the domain controller needs to be restarted. The password should be known to only a small group of trusted administrators, preferably only member of the Domain Admins group. The disadvantage of using passwords to secure SYSKEY is that trusted personnel are required to memorize another password and be on-site to enter the password.
To support branch offices, you may need to provide the SYSKEY password remotely through central IT trusted personnel. However, this requires additional hardware, such as Compaq RILO or Dell DRAC III boards. For more information about restarting domain controllers remotely, see "Securing the Remote Restart of Domain Controllers" later in this guide.
Because passwords can be compromised, you may be able to increase the security of passwords that are used for SYSKEY restarts by:
Using strong passwords.
Storing the passwords in a secure environment, such as a bank safety deposit box.
Requiring the periodic changing of the SYSKEY passwords.
Providing SYSKEY Floppy Disks to Secure Domain Controller Restarts
Using SYSKEY with a password that is stored on a floppy disk does not require that a password be memorized by trusted personnel. However, implementing SYSKEY with a floppy disk does introduce the risk of lost or damaged physical media. Furthermore, trusted personnel are required to insert the floppy disk during domain controller restart. Again, only trusted personnel, preferably members of the Domain Admins group, should have access to the SYSKEY floppy disk.
To support branch offices, you may need to install third-party hardware devices, such as Compaq RILO or Dell DRAC III boards, so that images of floppy disks can be remotely transferred to the domain controller. Using these devices, central IT trusted personnel can transfer a copy of the SYSKEY disk image to a remote domain controller. After the domain controller is restarted, IT operations personnel can delete the remote image of the SYSKEY floppy disk.
Because the floppy disk contains the cryptographic key for SYSKEY, you should take measures to ensure that the floppy disk is not stolen, lost, destroyed, or copied by an unauthorized person. Some ways to mitigate these possibilities include:
Copying the floppy disk and storing the copy off-site, such as in a bank safe deposit box.
Storing the working copy of the floppy disk in a secure place on-site.
Removing the floppy disk from the domain controller immediately after it restarts.
Securing Backup Media Against Physical Access
As part of your normal operational practices, you should regularly back up your domain controllers and secure the backup media to minimize the risk of data tampering or theft.
Because the backup contains all the information in the Active Directory database, theft of the backup media presents the same risks as theft of the domain controller or a disk drive from the domain controller. The attacker can restore the information elsewhere and illegally access Active Directory data.
Some methods for helping to prevent unauthorized users from gaining physical access to backup media include:
Storing backup media for on-site use in a secure location where access is audited.
Storing archival backup media securely off-site.
Establishing processes and procedures that require the signatures of authorized administrators when any archival backup media is brought back on-site.
Ensuring that backup media is only in the backup device during backup or recovery.
Enhancing the Security of the Network Infrastructure
The placement of domain controllers in your environment directly affects the security of your domain controllers. The primary focus in network security is to isolate the domain controllers from unauthorized users while providing high-speed, secure access to authorized users. To ensure that domain controllers are properly isolated, secure any cabling rooms, and place domain controllers on secured network segments in your network.
Securing Cabling Rooms
If an attacker can gain access to your cabling rooms, the attacker can potentially use a protocol analyzer to capture network traffic and compromise your network's security, including domain controller security. In intranet and perimeter network datacenters, the possibility of unauthorized personnel gaining access to these cabling rooms is negligible. However, in branch offices the cabling rooms may be shared with telephony wiring and other utilities.
Typically, your cabling rooms are where some of your routers and switches are located. The routers and switches contain a logical diagram of your network because they manage and maintain routing information. This routing information is used by Active Directory to determine IP subnets, and it determines the preferred domain controller for computers in the network.
Attackers can gain access to your switches and routers by using Telnet or Web interfaces that are provided by these devices. If attackers gain access to the configuration information of these devices, they can use this information to mount attacks on your domain controllers.
In most environments, all routers and switches use the same passwords for reading and configuring information. IT administrators may want to have a single password to simplify the management of a large number of switches, or the management software for routers and switches may only support the use of a single name.
Regardless of the environment, you can improve the security of your cabling rooms by:
Requiring cardkey locks or cipher-locks on entrances to the cabling rooms.
Requiring locks on the racks that house wiring panels, switches, or routers.
Including UPSs to prevent loss of power.
Requiring specific processes and procedures for any administration or repair of cabling, switches, or routers.
Using strong passwords to secure the configuration of routers and switches.
Using different passwords for reading and configuring routers and switches.
Placing Domain Controllers in Secured Network Segments
Placing domain controllers in secured segments of your network assists in isolating the domain controllers from unauthorized users. At the same time, ensure that users and computers have high-speed connectivity to their respective domain controllers.
Placing Domain Controllers in Datacenters
Place domain controllers physically within the datacenter so that only designated personnel have direct physical contact with the domain controllers. Place your forest root, application, and regional domain controllers for use in your organization's private network in the datacenter. The placement of domain controllers for your perimeter network is discussed in a later section.
Placing domain controllers physically within the datacenter reduces the chance that anyone other than designated personnel will have direct physical contact with the domain controllers. Place domain controllers so that firewalls protect domain controllers from Internet users while routers, and possibly firewalls, protect domain controllers from users within the organization's private network. Figure 7 illustrates the placement of domain controllers in a datacenter.
Figure 7 Domain Controllers in a Datacenter
Placing Domain Controllers in Perimeter Networks
Place domain controllers in your perimeter networks so that the domain controllers are not directly accessible by Internet users. Ensure that only Web servers, database servers, file servers, users in the private network, and computers in the private network have direct access to the domain controllers.
Placing the domain controller behind a standalone router helps prevent Internet users from directly accessing the domain controller. To help minimize security risks, place the domain controller on the same network segment as the client computers. You should also ensure that the router communicates exclusively with the organization's hub or central location by using VPN tunnels. Prevent any other requests that originate from the Internet from reaching the branch office's network segment and, subsequently, the domain controller.
Figure 8 illustrates the placement of domain controllers in a perimeter network.
Figure 8 Domain Controllers in a Perimeter Network
Placing Domain Controllers in Branch Offices
In branch offices, domain controllers often provide other services, such as file or print services, to users in the branch office. These multifunction domain controllers communicate with the rest of the organization through a routed connection, possibly a dial-up modem that is managed by a stand-alone router. The stand-alone router provides the isolation and firewall functionality to protect the domain controller and the users in the branch office.
Place the domain controller behind the stand-alone router to prevent Internet users from directly accessing the domain controller. Place the domain controller on the same network segment as the client computers. Ensure that the router communicates exclusively with the organization's hub or central location by using VPN tunnels. Prevent any other requests that originate from the Internet from reaching the branch office's network segment and, subsequently, the domain controller.
Note: Whenever possible, use dedicated domain controllers in branch offices to minimize the threats that can compromise the security of Active Directory.
Figure 9 illustrates the placement of domain controllers in a branch office.
Figure 9 Domain Controllers in a Branch Office
Additionally, a modem can provide out-of-band management capability for a remote domain controller. The modem directly connects either to a COM port on the domain controller or to remote management hardware (such as the Compaq RILO board) or an intelligent UPS. This out-of-band management capability can provide the ability to perform BIOS configuration, monitor and select the boot process, and turn the domain controller on and off.
Ensure that the number to the modem is kept secret. Require the modem to call back to a predetermined list of numbers, and require user identification for callback.
Securing the Remote Restart of Domain Controllers
In some situations, your domain controllers may require remotely administered management, or they may be placed in branch offices outside your organization's datacenter. In these situations, the restart of a domain controller must be performed remotely.
Tasks that must be performed during the remote restart of a domain controller include:
Selection of the Windows 2000 Server boot options
Configuration of the BIOS on the domain controller
Terminal Services is unable to perform these tasks, because Windows 2000 Server must be running to support Terminal Services. These tasks require additional hardware to support remote restart functionality. Examples of this type of hardware include:
Smart UPSs
Remote access hardware that is integrated into the server, such as Compaq RILO or Dell DRAC III boards
Video switches that connect to the keyboard, mouse, and display that provide services similar to Terminal Services
Most of these devices communicate by using RS-232 or Ethernet, and they have only rudimentary security, such as a password. In datacenters, the devices that communicate through RS232 are connected to a terminal concentrator. The terminal concentrator multiplexes a number of RS-232 connections into a single RS-232 or Ethernet connection. Smart UPS and remote access hardware typically communicate through Telnet.
Secure the remote restart of domain controllers by doing the following:
When the domain controller is in a datacenter, connect the remote restart device's RS232 or Ethernet connection to a network segment that is dedicated to network management and that is isolated from clients.
When the domain controller is in a branch office, connect the remote restart device to a dedicated modem, and require the modem to provide password identification and callback functionality.
Recommendations: Deploying Secure Domain Controllers
Following the security recommendations that are described earlier in this section will help minimize the security risks involved in deploying domain controllers. Of course, as previously mentioned, you should consider the recommendations described in other sections in considering how best to enhance your comprehensive Active Directory security.
In most instances, these recommendations are intended for intranet datacenter, extranet datacenter, and branch office scenarios. However, some of the recommendations depend on the particular scenario. When the recommendations are scenario specific, notes are included to direct you to the section where the recommendation is discussed.
Recommendations for Establishing Secure Domain Controller Build Practices
The following table provides a checklist of recommendations for establishing secure domain controller rollout practices.
Check |
Securing the Domain Controller Build Environment |
|
Whenever possible, build domain controllers in secured environments, such as datacenters. |
|
When building domain controllers in unsecured environments, ensure that only trusted personnel have physical access. |
Check |
Selecting Secure Domain Controller Build Methods |
|
Use imaged-based, automated deployment methods for installing Windows 2000 Server. Note: |
|
Automate the promotion of servers to domain controllers. |
Recommendations for Ensuring Predictable, Repeatable, and Secure Domain Controller Deployments
The following table provides a checklist of recommendations for ensuring that your domain controller deployments are predictable, repeatable, and secure.
Check |
Installing Windows 2000 Server with Service Packs and Hotfixes |
|
Install Windows 2000 Server with the most recent service packs. |
|
Apply all current security-related hotfixes. |
|
Format all partitions as NTFS. |
|
Create a strong password for the Administrator account. |
|
Deselect IIS during installation. |
|
Select DNS during installation. |
|
Deselect SMTP unless Active Directory replication uses SMTP. |
Check |
Disabling NTFS Automatic 8.3 Name Generation |
|
Disable NTFS automatic 8.3 name generation. |
Check |
Running Virus-Scanning Software on the Server |
|
Run virus-scanning software before promoting any server to a domain controller. |
|
Ensure that virus-scanning software includes any updates to detect and remove the latest viruses. |
Check |
Selecting Secure Domain Controller Promotion Settings |
|
Place the Active Directory database (Ntds.dit) on a separate physical drive. |
|
Place the Active Directory logs on a separate physical drive. |
|
Place SYSVOL on the same physical drive as the Active Directory database. |
|
Disable Pre-Windows 2000 Compatibility, if possible. |
Check |
Prohibiting the Use of Cached Credentials when |
|
Prohibit cached credentials from unlocking a domain controller console. |
Check |
Creating a Reserve File to Enable Recovery from Disk-Space Attacks |
|
Create a reserve file on the same disk volume as Ntds.dit. Ensure that the reserve file is either 250 MB or 1 percent of the available disk space, whichever is larger. |
Recommendations for Enabling Only Essential Services
The following table provides a checklist of recommendations for enabling only essential services and protocols on your domain controllers.
Check |
Enabling Only Essential Services |
---|---|
|
Enable only the services that are required for a computer running Windows 2000 Server in the role of a domain controller. |
Recommendations for Securing Domain Controller Files and Executables
The following table provides a checklist of recommendations for securing the Active Directory files and executables on your domain controllers.
Check |
Setting Appropriate NTFS File and Folder Permissions |
---|---|
|
Change the default permissions assignment on the volume root from Everyone to Administrators. |
Recommendations for Running Virus Scans on Domain Controllers
The following table provides a checklist of recommendations for running virus scans on domain controllers.
Check |
Running Virus Scans on Domain Controllers |
|
After promoting servers to domain controllers, continue to run virus scans and to obtain regular virus signature updates from your antivirus software vendor. |
Check |
Preventing Interference Between Virus Scans and Active |
|
Configure the antivirus software to exclude from scanning the Active Directory database and log files that are specified in Table 12. |
Check |
Preventing Interference Between Virus Scans and FRS |
|
Configure the antivirus software to exclude from scanning the FRS database and log files that are specified in Table 13. |
Check |
Preventing Virus Scans from Triggering Excessive FRS Replication |
|
Configure antivirus software to not scan files in SYSVOL. |
|
Require script signing on domain controllers and administrative workstations. |
Recommendations for Maintaining Physical Security
The following table provides a checklist of recommendations for maintaining the physical security of your domain controllers.
Check |
Securing Domain Controllers Against Physical Access |
|
Include UPSs. |
|
Place domain controllers and UPSs in locked rooms. |
|
Require cardkey locks or cipher-locks on the entrances to the locked rooms. |
|
Require locks on individual domain controllers or on doors to the racks housing domain controllers. |
|
Require specific processes and procedures for the administration or repair of domain controllers. |
Check |
Preventing Domain Controllers from Booting into Alternate Operating Systems |
|
Disable or remove the floppy disk drive, unless it is required for SYSKEY. |
|
Disable or remove the CD-ROM or DVD drive. |
|
Set the [timeout] parameter in the Boot.ini file to 0. |
Check |
Protecting Domain Controllers on Restart by Using SYSKEY |
|
Enable SYSKEY. Note: |
Check |
Securing Backup Media Against Physical Access |
|
Store backup media used on-site in a locked cabinet or container. |
|
Store archival backup media in off-site storage. |
|
Establish processes and procedures that require signatures to bring any archival storage back on-site. |
|
Ensure that backup media is only installed during backup and that it is in secured storage otherwise. |
Check |
Enhancing the Security of the Network Infrastructure |
|
Require cardkey locks or cipher-locks on the entrances to cabling rooms. |
|
Require processes and procedures for any administration or repair of cabling, switches, or routers. |
|
Use strong passwords to secure the configuration of routers and switches. |
|
Use different passwords for reading and configuring your routers and switches. |
Check |
Securing the Remote Restart of Domain Controllers |
|
When the domain controller is in a datacenter, connect the remote restart devices to the secured management network. |
|
When the domain controller is in a branch office, connect the remote restart device to a dedicated modem, and require the modem to provide password identification and callback functionality. |
Chapter 4: Establishing Secure Domain and Domain Controller Policy Settings
Windows 2000 Active Directory contains default security policy settings for the domain and for domain controllers. These settings are configured by default when Windows 2000 Server Active Directory is installed, and they are applied to all newly promoted domain controllers.
To augment security for the domain and domain controllers, consider implementing the changes to the default policy settings presented here. To improve security for domain and domain controller policy settings, perform the following tasks:
Establish secure domain policy settings.
Establish secure domain controller policy settings.
Select policy settings for mixed operating system environments.
Apply selected domain and domain controller policy settings.
Establishing Secure Domain Policy Settings
Domain security policy settings provide Active Directory with domain-wide security options for handling authentication and authorization of Active Directory security principals. These policy settings are applied to all security principal accounts in the domain, unless inheritance is specifically blocked or overridden by another policy.
Note: Make all changes to the domain policy settings directly in the default Domain Group Policy object (GPO), because application programming interfaces (APIs) that were developed for earlier versions of the operating system update policy settings in the default Domain Controllers GPO.
Domain Group Policy controls various categories of settings. To increase comprehensive security for your domain, apply the recommended password, account lockout, and Kerberos policy settings.
Domain policy settings are divided into multiple categories of settings. To increase comprehensive domain security, perform the following tasks:
Establish password policy settings for domains.
Establish account lockout policy settings for domains.
Establish Kerberos policy settings for domains. (No changes to the default settings are recommended.)
Securing Password Policy Settings for Domains
In Windows 2000, the most common method for authenticating a user's identity is the use of secret user passwords. Once a user has been identified and authenticated, the user can perform any tasks or access any resource for which he or she is authorized. Strong passwords generally enhance security for Active Directory users. Using strong passwords helps avoid the threat of an unauthorized user guessing (cracking) a weak password and acquiring the credentials of the compromised user account (spoofing). This is especially true for administrative accounts, because an unauthorized user could obtain administrative credentials and gain elevated privileges.
A complex password that changes regularly reduces the likelihood of a successful spoofing attack. Password policy settings control the complexity and lifetime for passwords. Table 14 includes the default and recommended password policy settings for a domain.
Table 14 Default and Recommended Password Group Policy Settings
Policy |
Default |
Recommended |
Comments |
---|---|---|---|
Enforce password history |
1 passwords |
24 passwords |
Prevents users from reusing passwords. |
Maximum password age |
42 days |
(No change) |
|
Minimum password age |
0 days |
2 days |
Prevents users from cycling through their password history to reuse passwords. |
Minimum password length |
0 characters |
8 characters |
Ensures minimum password strength. |
Password must meet complexity requirements |
Disabled |
Enable |
For the definition of a complex password, see "Creating a Strong Administrator Password" earlier in this guide. |
Store password using reverse encryption for all users in domain |
Disabled |
(No change) |
|
Note: If possible, use smart cards throughout the organization to ensure the strongest possible passwords on user accounts. Using smart cards causes the system to automatically generate cryptographically strong random passwords for accounts. When you are unable to provide smart cards for all users, require service administrator accounts to use smart cards. For more information about smart cards, see "Establishing Secure Administrative Practices" later in this guide.
Securing Account Lockout Policy Settings for Domains
More than a few unsuccessful password tries during logon could represent an attacker's attempt to determine an account password by trial and error. Windows 2000 keeps track of logon attempts, and it can be configured to respond to this type of attack by disabling the account for a preset period of time. This is referred to as account lockout.
Account lockout policy settings control the threshold for this response and the actions to be taken once the threshold is reached. Table 15 includes the default and recommended account lockout policy settings.
Table 15 Default and Recommended Account Lockout Group Policy Settings
Policy |
Default |
Recommended |
Reason |
---|---|---|---|
Account lockout duration |
Not defined |
0 minutes |
The value 0 means that after account lockout an Administrator is required to re-enable the account before account lockout reset has expired. |
Account lockout threshold |
0 tries |
20 tries |
The value 0 means that failed password tries never cause account lockout. Because we are recommending an account lockout duration of 0 (administrator reset), a small number here could result in frequent administrator interventions. |
Reset account lockout counter after |
Not defined |
30 minutes |
This setting protects against a sustained dictionary attack by imposing a nontrivial delay after five unsuccessful attempts. A higher value for this setting could result in increased help-desk calls for legitimate account lockouts. |
Securing Kerberos Policy Settings for Domains
In Windows 2000, Kerberos 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 lifetimes of Kerberos tickets, the risk of having a legitimate user's credentials stolen and successfully used by an attacker diminishes. However, authorization overhead increases. Table 16 includes the default and recommended Kerberos policy settings.
Table 16 Default and Recommended Kerberos Group Policy Settings
Policy |
Default |
Recommended |
Comments |
---|---|---|---|
Enforce user logon restrictions |
Enabled |
(No change) |
A user must have the right to log on locally (for service on the same computer) or to access the service from the network. |
Maximum lifetime for service ticket |
600 minutes |
(No change) |
|
Maximum lifetime for user ticket |
10 hours |
(No change) |
|
Maximum lifetime for user ticket renewal |
7 days |
(No change) |
|
Maximum tolerance for computer clock synchronization |
5 minutes |
(No change) |
This refers to maximum tolerance between the client's and server's clocks. |
Establishing Secure Domain Controller Policy Settings
In addition to establishing Group Policy settings for your domains in Active Directory, you can also establish Group Policy settings and Windows 2000 configuration settings to secure your domain controllers. Domain controller policies are set on the Domain Controllers organizational unit (OU) in each domain.
Domain controller policies are divided into multiple categories of settings. To enhance comprehensive security for your domain controllers, perform the following tasks:
Establish domain controller user rights assignment policy settings.
Establish domain controller audit policy settings.
Enable auditing on Active Directory database objects.
Establish domain controller security options policy settings.
Establish domain controller event log policy settings.
Establishing Domain Controller User Rights Assignment Policy Settings
User rights allow users to log on and perform specific administrative or operations tasks on your domain controllers. Ensure that the appropriate user rights are assigned to users in the domain so that the users can perform their intended functions without compromising the security of the domain controllers. Establish the policy settings for domain controller user rights assignment to properly limit the users who can log on to the domain controllers and perform the necessary administrative tasks.
Table 17 lists the default and recommended settings for domain controller user rights assignment policies. All other user rights assignment policies are unchanged.
Note: Make changes to the user rights assignment policy settings directly in the default Domain Controllers GPO because APIs that were developed for earlier versions of the operating system update the user rights assignment in the default Domain Controllers GPO.
Table 17 Default and Recommended Domain Controller User Rights Assignment Policy Settings
Policy |
Default Setting |
Recommended Setting |
Comments |
---|---|---|---|
Log on locally |
Administrators Backup Operators Account Operators Server Operators |
Administrators Backup Operators Server Operators |
Account Operators are for account management and have few (if any) reasons to log on locally. |
Shut down the system |
Administrators Backup Operators Account Operators Server Operators Print Operators |
Administrators Backup Operators Server Operators |
Account Operators and Print Operators have few (if any) reasons to shut down domain controllers. |
Note: Members of the Backup Operators group can log on locally to domain controllers, archive files to backup media, and overwrite system files through restore operations. The only members of this group should be those users who perform domain controller backup and restore operations. To reduce the number of users that have these rights, do not make users who are responsible only for application backup and restore operations, such as SQL Server operators, members of the Backup Operators group.
Establishing Domain Controller Audit Policy Settings
By default, Windows 2000 Active Directory does not configure any audit policy settings, and no Active Directory access or domain controller operation is audited in the default configuration. The recommendations presented here provide the minimum recommended security audit policy settings that you should configure to maintain an audit trail of security-sensitive operations.
Important: There are many possible goals that you can have when you audit a domain for security purposes, such as intrusion detection or forensic analysis of security breaches. The primary goal of the security audit settings is to provide accountability for sensitive directory operations, including any administrative or configuration changes. When auditing for other reasons, such as intrusion detection, additional auditing may need to be enabled.
When you enable auditing on a domain controller, the number of events that are recorded in the Security event log increases. As a result, the maximum size of the Security event log must be increased. For the recommended settings for the maximum size of the Security event log, see "Establishing Domain Controller Event Log Policy Settings" later in this guide.
Note: Make all changes to the domain controller audit policy settings directly in the default Domain Controllers GPO, because APIs that were developed for earlier versions of the operating system update in the default Domain Controllers GPO.
Table 18 lists the default and recommended settings for domain controller audit policies.
Table 18 Default and Recommended Domain Controller Audit Policy Settings
Policy |
DefaultSetting |
Recommended Setting |
Comments |
---|---|---|---|
Audit account logon events |
No auditing |
Success |
Account logon events are generated when a domain user account is authenticated on a domain controller. |
Audit account management |
Not defined |
Success |
Account management events are generated when security principal accounts are created, modified, or deleted. |
Audit directory service access |
No auditing |
Success |
Directory services access events are generated when an Active Directory object with a system access control list (SACL) is accessed. |
Audit logon events |
No auditing |
Success |
Logon events are generated when a domain user interactively logs on to a domain controller or when a network logon to a domain controller is performed to retrieve logon scripts and policies. |
Audit object access |
No auditing |
(No change) |
|
Audit policy change |
No auditing |
Success |
Policy change events are generated for changes to user rights assignment policies, audit policies, or trust policies. |
Audit privilege use |
No auditing |
(No change) |
|
Audit process tracking |
No auditing |
(No change) |
|
Audit system events |
No auditing |
Success |
System events are generated when a user restarts or shuts down the domain controller or when an event occurs that affects either the system security or the security log. |
Enabling Auditing on Active Directory Database Objects
Enabling the audit policies for your domain controller is only part of the task for auditing your domain controller. In addition, you should enable auditing on important Active Directory objects with suitable audit policy settings.
To set the required audits for an Active Directory object, you need to change the system access control list (SACL) on the object. You should change the SACL of objects in Active Directory based on the tables provided later in this section.
Active Directory comprises multiple directory partitions. Directory partitions are logical divisions of the Active Directory database. To enable auditing on Active Directory database objects, perform the following tasks:
Enable auditing on the Schema directory partition.
Enable auditing on the Configuration directory partition.
Enable auditing on the Domain directory partition.
For a procedure for these tasks, see "Enabling Auditing on Active Directory Database Objects" in "Appendix: Procedures" later in this guide.
Note: Be sure to remove any SACLs that were previously applied.
Enabling Auditing On the Schema Directory Partition
To enable auditing on the Schema directory partition, set the SACLs for the objects that are listed in Table 19. The directory operations that are audited by the settings in Table 19 include any additions, deletions, or modifications to the schema, as well as the transfer of the schema operations master role.
Table 19 Settings for CN=Schema,CN=Configuration,DC=ForestRootDomain
Type |
Name |
Access |
Apply To |
---|---|---|---|
Success |
Everyone |
Modify Permissions Modify Owner Create All Child Objects Delete Delete All Child Objects Delete Subtree |
This object only |
Success |
Everyone |
Write All Properties |
This object and all child objects |
Success |
Everyone |
Change Schema Master |
This object only |
Success |
Administrator |
All Extended Rights |
This object only |
Success |
Domain Users |
All Extended Rights |
This object only |
Enable Auditing on the Configuration Directory Partition
To enable auditing on the Configuration directory partition, set the SACLs for the objects listed in Table 20, Table 21, Table 22, Table 23, and Table 24.
The directory operations that are audited by the settings in Table 20 include any modifications to the permissions and the wellKnownObjects attribute on the Configuration directory partition.
Table 20 Settings for CN=Configuration,DC=ForestRootDomain
Type |
Name |
Access |
Apply To |
---|---|---|---|
Success |
Everyone |
Modify Permissions Modify Owner Write All Properties |
This object only |
Success |
Administrator |
All Extended Rights |
This object only |
Success |
Domain Users |
All Extended Rights |
This object only |
The directory operations that are audited by the settings in Table 21 include:
Addition and removal of domain controllers in the forest
Addition and removal of Group Policy settings that are applied to a site
Association and disassociation of a subnet with a site
Execution of the following control operations on a domain controller: Do Garbage Collection, Recalculate Hierarchy, Recalculate Security Inheritance, and Check Stale Phantoms
Table 21 Settings for CN=Sites,CN=Configuration,DC=ForestRootDomain
Type
Name
Access
Apply To
Success
Everyone
Create All Child Objects
Delete
Delete All Child Objects
Delete Subtree
This object and all child objects
Success
Everyone
All Extended Rights
Domain Controller Settings objects
Success
Everyone
Write gPLink (property)
Write gPOptions (property)
Site objects
Success
Everyone
Modify siteObject (property)
Subnet objects
Success
Everyone
Modify siteObject (property)
Site link objects
Success
Everyone
Modify siteObject (property)
Connection objects
The directory operations that are audited by the settings in Table 22 include:
Addition and removal of domains (or external directory knowledge references) in the forest
Modifications to valid UPN Suffixes for the forest
Transfer of the domain naming operations master role
Table 22 Settings for CN=Partitions,CN=Configuration,DC=ForestRootDomain
Type
Name
Access
Apply To
Success
Everyone
Modify Permissions
Modify Owner
Write All Properties
Create All Child Objects
Delete All Child Objects
Delete Subtree
All Extended Rights
This object and all child objects
The directory operations that are audited by the settings in Table 23 include changes to the dsHeuristics attribute, which controls certain characteristics of forest-wide behavior of the directory service.
Table 23 Settings for CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain
Type |
Name |
Access |
Apply To |
---|---|---|---|
Success |
Everyone |
Write dSHeuristics (property) |
This object only |
The directory operations that are audited by the settings in Table 24 include changes to forest-wide parameters that govern the behavior of Lightweight Directory Access Protocol (LDAP)-based queries and operations.
Table 24 Settings for CN=Default Query Policy,CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain
Type |
Name |
Access |
Apply To |
---|---|---|---|
Success |
Everyone |
Write lDAPAdminLimits (property) |
This object only |
Enabling Auditing on the Domain Directory Partition
To enable auditing for the Configuration directory partition, set the SACLs for the objects listed in Table 25, Table 26, Table 27, Table 28, Table 29, and Table 30.
The directory operations that are audited by the settings in Table 25 include:
Transfer of the PDC emulator operations master role
Addition and removal of Group Policy settings that are applied to the domain
Modifications to valid DNS Suffixes for the domain
Modifications to the permissions and the wellKnownObjects attribute on the Domain directory partition
Migration of SID history
Table 25 Settings for DC=Domain,DC=...ForestRootDomain
Type
Name
Access
Apply To
Success
Everyone
Modify Permissions
Modify Owner
Write All Properties
This object only
Success
Administrators
All Extended Rights
This object only
Success
Domain Users
All Extended Rights
This object only
The directory operations that are audited by the settings in Table 26 include:
Addition and removal of domain controllers for the domain
Modifications to any properties of domain controller computer accounts
Table 26 Settings for OU=Domain Controllers,DC=Domain,DC=...ForestRootDomain
Type
Name
Access
Apply To
Success
Everyone
Modify Permissions
Modify Owner
Create All Child Objects
Delete
Delete All Child Objects
Delete Subtree
This object only
Success
Everyone
Write All Properties
This object and all child objects
The directory operations that are audited by the settings in Table 27 include the transfer of the infrastructure operations master role.
Table 27 Settings for CN=Infrastructure,DC=Domain,DC=...ForestRootDomain
Type |
Name |
Access |
Apply To |
---|---|---|---|
Success |
Everyone |
All Extended Rights Write All Properties |
This object only |
The directory operations that are audited by the settings in Table 28 include:
Addition and removal of GPOs
Modifications to GPOs
Table 28 Settings for CN=Policies,CN=System,DC=Domain,DC=...ForestRootDomain
Type
Name
Access
Apply To
Success
Everyone
Modify Permissions
Modify Owner
Create groupPolicyContainer Objects
Delete
Delete groupPolicyContainer Objects
Delete Subtree
This object only
Success
Everyone
Modify Permissions
Write All Properties
GroupPolicyContainer objects
The directory operations that are audited by the settings in Table 29 include modifications to the special security descriptor that protects all service administrator accounts.
Table 29 Settings for CN=AdminSDHolder,CN=System,DC=domain,DC=...ForestRootDomain
Type |
Name |
Access |
Apply To |
---|---|---|---|
Success |
Everyone |
Modify Permissions Modify Owner Write All Properties |
This object only |
The directory operations that are audited by the settings in Table 30 include the transfer of the RID operations master role.
Table 30 Settings for CN=RID Manager$,CN=System,DC=Domain,DC=...ForestRootDomain
Type |
Name |
Access |
Apply To |
---|---|---|---|
Success |
Everyone |
All Extended Rights Write All Properties |
This object only |
Establishing Domain Controller Security Options Policy Settings
Policy settings for domain controller security options affect the security-related Windows 2000 Server configuration settings. The domain controller security options policy settings affect not only the Active Directory-related security configuration settings, but other components in Windows 2000 as well, such as the network, file system, and user logon security configuration settings. Table 31 lists the default and recommended policy settings for domain controller security options.
Table 31 Recommended Domain Controller Security Options Policy Settings
Policy |
DefaultSetting |
Recommended Setting |
Comments |
---|---|---|---|
Additional restrictions for anonymous connections |
Not defined |
(See comments) |
For operating system requirements, see "Selecting Policy Settings for Mixed Operating System Environments." |
Allow Server Operators to schedule tasks (domain controllers only) |
Not defined |
Disabled |
Restricts the individuals who can schedule tasks to Administrators, because scheduling usually runs as an elevated service. |
Allow system to be shut down without having to log on |
Not defined |
Disabled |
Requires an authenticated, authorized service account to shut down or restart the domain controller. |
Allow to eject removable NTFS media |
Not defined |
Administrators |
Allows only Administrators to eject removable NTFS media to protect against the theft of sensitive data. |
Amount of idle time required before disconnecting session |
Not defined |
15 minutes |
Controls when a domain controller suspends an inactive server message block (SMB) session, which has no security implications but which reduces SMB traffic resource usage. |
Audit the access of global system objects |
Not defined |
Disabled |
Disables the creation of a default SACL on system objects, such as mutexes (mutual exclusive), events, semaphores, and DOS devices because the default policy is "No auditing." |
Audit use of Backup and Restore privilege |
Not defined |
Disabled |
Disables auditing for the use of user privileges, including Backup and Restore, when the "Audit privilege use" policy is enabled because this policy is configured for "No auditing." |
Automatically log off users when logon time expires |
Not defined |
Enabled |
Forcibly disconnects client sessions with the SMB Service when the user's logon hours expire to ensure that network connections are secured during nonworking hours. |
Automatically log off users when logon time expires (local) |
Not defined |
Enabled |
Forcibly logs off users with interactive sessions when the user's logon hours expire to ensure that network connections are secured during nonworking hours. |
Clear virtual memory pagefile when system shuts down |
Not defined |
Enabled |
Eliminates process memory data from going into the pagefile on shutdown in case an unauthorized user manages to directly access the pagefile. |
Digitally sign client communication (always) |
Not defined |
(See comments) |
See "Selecting Policy Settings for Mixed Operating System Environments" for requirements. |
Digitally sign client communication (when possible) |
Not defined |
(No change) |
See "Selecting Policy Settings for Mixed Operating System Environments" for requirements. |
Digitally sign server communication (always) |
Not defined |
(See comments) |
See "Selecting Policy Settings for Mixed Operating System Environments" for requirements. |
Digitally sign server communication (when possible) |
Enabled |
(No change) |
See "Selecting Policy Settings for Mixed Operating System Environments" for requirements. |
Disable CTRL + ALT + DEL requirement for logon |
Not defined |
Disabled |
Requires CTRL+ALT+DEL before users log on to ensure that users are communicating by means of a trusted path when entering their passwords. |
Do not display last user name in logon screen |
Not defined |
Enabled |
Removes the name of the last user to successfully log off from the Log On to Windows dialog box to prevent attackers from discovering service account names on domain controllers. |
LAN Manager Authentication Level |
Not defined |
(See comments) |
See "Selecting Policy Settings for Mixed Operating System Environments" for requirements. |
Message text for users attempting to log on |
Not defined |
(No change) |
|
Message title for users attempting to log on |
Not defined |
(No change) |
|
Number of previous logons to cache (in case domain controller is not available) |
Not defined |
0 logons |
The value 0 indicates that the domain controller does not cache previous logons and requires authentication at each logon. |
Prevent system maintenance of computer account password |
Not defined |
Disabled |
Not enabled because computer account passwords are used to establish secure channel communications between members and domain controllers and, within the domain, between the domain controllers themselves. After it is established, the secure channel is used to transmit sensitive information that is necessary for making authentication and authorization decisions. |
Prevent users from installing printer drivers |
Not defined |
Enabled |
Allows only Administrators and Server Operators to install a printer driver when adding a network printer to ensure that users cannot install a printer driver (add a network printer) and perform disk-space attacks by submitting large print jobs. |
Prompt user to change password before expiration |
Not defined |
14 days |
Notifies users in advance (in days) that their password is about to expire so that the user has time to construct a password that is sufficiently strong. |
Recovery Console: Allow automatic administrative logon |
Not defined |
Disabled |
Requires that an Administrator account password must be given before access is granted to a domain controller to ensure that anyone logging on requires administrator credentials. |
Recovery Console: Allow floppy copy and access to all drivers and all folders |
Not defined |
Disabled |
Prevents unauthorized users from gaining access to, copying, and removing the Active Directory database and other secure files from the domain controller. |
Rename administrator account |
Not defined |
(No change) |
|
Rename guest account |
Not defined |
(No change) |
|
Restrict CD-ROM access to locally logged-on users only |
Not defined |
Enabled |
Allows only the interactively logged-on service administrator to access removable CD-ROM media to ensure that when no one is logged on interactively, the CD-ROM cannot be accessed over the network. |
Restrict floppy access to locally logged-on users only |
Not defined |
Enabled |
Allows only interactively logged-on service administrators to access removable floppy media to ensure that the floppy cannot be accessed over the network when no one is logged on. |
Secure channel: Digitally encrypt or sign secure channel data (always) |
Not defined |
Enabled |
Requires Windows NT 4.0 with Service Pack 6 (SP6) or newer software on all domain controllers in local and all trusted domains to ensure that all security fixes have been made. |
Secure channel: Digitally encrypt secure channel data (when possible) |
Not defined |
(No change) |
|
Secure channel: Digitally sign secure channel data (when possible) |
Not defined |
(No change) |
|
Secure channel: Require strong (Windows 2000 or later) session key |
Not defined |
Enabled |
Requires that a secure channel be established with 128-bit encryption to ensure that the key strength is not negotiated but always uses the most secure connection possible with the domain controller. |
Secure system partition (for RISC platforms only) |
Not defined |
(No change) |
|
Send unencrypted password to connect to third-party SMB servers |
Not defined |
Disabled |
Prohibits the SMB redirector from sending plaintext passwords to non-Microsoft SMB servers that do not support password encryption. Disable this policy unless your domain controller needs to communicate with non-Microsoft SMB servers. |
Shut down system immediately if unable to log security audits |
Not defined |
Disabled |
Stops the domain controller if a security audit cannot be logged. The auditing goals for domain controllers in "Establishing Domain Controller Audit Policy Settings" allow overwriting Security audit events as required. |
Smart card removal behavior |
Not defined |
Force logoff |
Forces service administrators to keep smart cards inserted while logged on interactively on domain controllers to ensure that domain controllers are not left logged on to and unattended. |
Strengthen default permissions of global system objects (e.g. Symbolic Links) |
Not defined |
Enabled |
Allows users who are not administrators to read shared objects but not modify them. Strengthens the default DACL of objects in the global list of shared resources, such as DOS device names, mutexes, and semaphores. |
Unsigned driver installation behavior |
Not defined |
Do not allow installation |
Prevents insecure or untrusted device drivers from being installed on domain controllers. |
Unsigned non-driver installation behavior |
Not defined |
Silently succeed |
Nondriver signing was not implemented in most software applications and services. This policy has no real benefit, and it is set to eliminate unnecessary notification. |
Establishing Domain Controller Event Log Policy Settings
If you enable the recommended domain controller audit policy, the maximum size of the security log should also be increased to accommodate the increased number of audited events that will be generated.
The event log policy settings recommended here reflect the changes that are necessary to support the recommended audit policy. In your environment, you may need to adjust the policy settings for the application or system event logs to support other operational goals.
As a part of your normal operations tasks, archive the security and system event logs regularly and frequently before they fill up, which can cause events to be missed. The recommended event log policy settings allow the events in the security and system event logs to be overwritten as needed. Back up the logs for future reference before any events can be overwritten.
Table 32 lists the default and recommended settings for domain controller event log policy settings.
Table 32 Recommended Domain Controller Event Log Policy Settings
Policy |
DefaultSetting |
Recommended Setting |
Comments |
---|---|---|---|
Maximum application log size |
Not defined |
(No change) |
|
Maximum security log size |
Not defined |
128 MB |
Increased to accommodate security auditing that is enabled in the domain controller audit policies. |
Maximum system log size |
Not defined |
(No change) |
|
Restrict guest access to application log |
Not defined |
Enabled |
Prevents members of the built-in group Guests from reading the application log events. |
Restrict guest access to security log |
Not defined |
Enabled |
Prevents members of the built-in group Guests from reading the security log events. |
Restrict guest access to system log |
Not defined |
Enabled |
Prevents members of the built-in group Guests from reading the system log events. |
Retain application log |
Not defined |
(No change) |
|
Retain security log |
Not defined |
(No change) |
|
Retain system log |
Not defined |
(No change) |
|
Retention method for application log |
Not defined |
(No change) |
|
Retention method for security log |
Not defined |
Overwrite events as needed |
Overwrites the security log when the maximum log size is reached to ensure that the log contains the most recent security events and to ensure that logging continues. |
Retention method for system log |
Not defined |
Overwrite events as needed |
Overwrites the system log when the maximum log size is reached to ensure that the log contains the most recent security events and to ensure that logging continues. |
Shutdown the computer when the security audit log is full |
Not defined |
(No change) |
|
Selecting Policy Settings for Mixed Operating System Environments
Although you are deploying - or have already deployed - Active Directory and Windows 2000 Server, your organization may have a mixture of earlier versions of Windows operating systems running on client and server systems. These operating systems include Microsoft® Windows® 95, Windows 98, Windows Millennium Edition, and Windows NT 4.0.
Although Active Directory domain controllers support all the security features discussed in this guide, earlier versions of Windows operating systems support only a subset of the security features in Active Directory and Windows 2000 Server. These earlier versions of Windows operating systems can run on workstation computers, member servers, and domain controllers. When your environment includes a mixture of Windows operating systems, you may have to adjust the security recommendations, given earlier in this chapter, to provide compatibility with the earlier versions of Windows operating systems.
Some of the security settings cannot be configured through Group Policy. Instead, these settings must be set directly through the domain controller's registry. Incorporate as many of these additional security settings as possible. When you are unable to adopt all the recommendations presented here, modify the registry script to reflect the security settings that you need in your organization.
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
Secure Active Directory in mixed operating system environments by:
Identifying when earlier versions of operating systems are an issue.
Restricting anonymous access to domain controllers.
Disabling LAN Manager authentication.
Signing SMB traffic between domain controllers and between domain controllers and member computers.
Disabling Pre-Windows 2000 Compatibility access.
Note: Restart the domain controller after any change to any of these registry settings so that the settings can take effect.
Identifying When Earlier Versions of Operating Systems Are an Issue
When your network environment is made up of Windows 2000 and later operating systems, you can incorporate all the security recommendations that are described in this document. When your network environment is made up of Windows operating systems earlier than Windows 2000, implementing these security recommendations may disrupt the normal operation of your network.
Compatibility issues with Windows operating systems earlier than Windows 2000 can be divided into the following categories:
Authenticating users with earlier authentication protocols
Digitally signing file services, print services, and other SMB traffic
Allowing anonymous access to domain controllers
Authenticating Users with Earlier Authentication Protocols
Any authentication protocol earlier than Windows NT challenge/response version 2 (NTLMv2) provides weaker security. To provide the strongest possible security, ensure that all domain controllers, member servers, and workstations support NTLMv2. For a more detailed description of the requirements to support NTLMv2, see "Disabling LAN Manager Authentication" later in this guide.
Digitally Signing File Services, Print Services, and Other SMB Network Traffic
The SMB protocol provides the basis for Microsoft file and print sharing and for many other networking operations, such as remote Windows administration. To prevent attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets.
Domain controllers, member servers, and workstations access file shares during the user logon process to access logon scripts and profiles in the NETLOGON share. Also, the File Replication service (FRS) uses file shares. As a result, all domain controllers should take advantage of SMB signing to improve security. For a more detailed description of the requirements for supporting SMB signing, see "Enabling SMB Signing on Domain Controllers" later in this guide.
Allowing Anonymous Access to Domain Controllers
Some of the operating systems and applications that were developed before Windows 2000 require anonymous access to other servers, including domain controllers. For example, the Spooler service running on Windows NT 4.0 requires anonymous access to remote printers.
Because the focus for this guide is on securing Active Directory, the ideal security goal would be to disable all anonymous access to your domain controllers. For a more detailed description of the requirements for allowing anonymous access to domain controllers, , see "Restricting Anonymous Access to Domain Controllers" later in this guide.
Allowing Anonymous Access to Active Directory Data
Certain applications also require anonymous access to Active Directory data. For example, SQL Server version 6.0 and Routing and Remote Access Service running on Windows NT 4.0 require anonymous access to Active Directory to authenticate users and enumerate their group memberships when it is running in Mixed or Windows Integrated security modes.
Because the focus for this guide is on securing Active Directory, the ideal security goal is to disable all anonymous access to Active Directory data. You can eliminate anonymous access to your Active Directory data by performing the following tasks:
Enable security monitoring for anonymous access on all domain controllers. For a procedure to perform this task, see "Monitoring for Anonymous Access" in "Appendix: Procedures" later in this guide.
Monitor the security logs for servers that initiate anonymous access to the domain controllers for about 30 days. For a procedure to perform this task, see "Monitoring for Anonymous Access" in "Appendix: Procedures" later in this guide.
Identify the applications running on the server that initiate anonymous access.
Eliminate the requirement for anonymous access to the domain controllers.
Based on the type of anonymous access that you identify in the list below, follow the recommendations in the corresponding section to eliminate the requirement for that type of anonymous access to your domain controllers:
Restricting Anonymous Access to Domain Controllers
Disabling Pre-Windows 2000 Compatibility Access
Monitor the security logs for servers that initiate anonymous access to the domain controllers for another 30 days.
After reviewing the security logs and ensuring that the domain controllers are not accessed anonymously, you are ready to disable the corresponding security feature that allows anonymous access by following the tasks for the same corresponding sections that you select in step 4.
Figure 10 illustrates the process that is described in the previous steps.
Figure 10 Process for Detecting and Eliminating Anonymous Access to Active Directory Data
Restricting Anonymous Access to Domain Controllers
If possible, restrict anonymous user access to your domain controllers. However, many earlier-version domain controllers, member servers, or workstations use anonymous access to perform normal system functions. For example, establishing trust relationships between a Windows NT 4.0 domain and a Windows 2000 domain requires anonymous access. These anonymous access connections are also known as null session connections.
You can use the Security Option policy Additional restrictions for anonymous connections, which is listed in "Establishing Domain Controller Security Options Policy Settings" earlier in this guide, to adjust the level of anonymous access that you can allow to your domain controller.
The levels of anonymous access that you can allow include:
None. Rely on default permissions (default).
With this policy setting, anonymous connections are only restricted by the resource permissions on individual resources.
Do not allow enumeration of SAM accounts and shares.
With this policy setting, anonymous connections cannot display lists of share names. This setting does not affect the ability of anonymous connections to enumerate users and groups in Active Directory, because domain controllers have no registry-based SAM. For more information about disabling anonymous access to Active Directory, see "Disabling Pre-Windows 2000 Compatible Access" later in this guide.
No access without explicit anonymous permissions.
With this policy setting, anonymous connections have no access without explicit anonymous permissions being granted to resources. The access token that is built for anonymous connections on a domain controller with this setting does not include the special group Everyone. As a result, anonymous connections cannot enumerate users and groups in Active Directory even if the domain is in Pre-Windows 2000 Compatibility mode. This can cause undesired behavior, because many Windows 2000 services, as well as third-party programs, rely on anonymous access capabilities to perform legitimate tasks.
Consider using the last two policy settings only when your network environment consists of domain controllers, member servers, and workstations - all running Windows 2000 or later. For example, when an administrator in a trusting domain wants to grant local access to a user in a trusted domain, the users in the trusted domain need to be enumerated. Because the trusted domain cannot authenticate the trusting domain's administrator, the request is made anonymously.
The benefits of restricting the capabilities of anonymous users from a security perspective should be weighed against the corresponding requirements of services and programs that rely on anonymous access for complete functionality.
The following limitations apply when the policy is set to No access without explicit anonymous permissions:
Earlier-version member workstations or servers are not able to set up a Netlogon secure channel.
Note: Earlier-version workstations and servers include computers running Microsoft operating systems earlier than Windows NT 4.0 SP3.
Earlier-version domain controllers in trusting domains are not be able to set up a Netlogon secure channel.
Windows NT users are not able to change their passwords after they expire. Also, Macintosh users are not able to change their passwords at all.
The Browser service is not able to retrieve domain lists or server lists from backup browsers, master browsers, or domain master browsers running on domain controllers with the policy set. Because of this, any program that relies on the Browser service does not function properly.
Because of these side effects, avoid setting the policy to No access without explicit anonymous permissions in mixed-mode environments that include earlier-version clients. Configuring the policy to this setting should only be considered in Windows 2000 environments and only after sufficient quality assurance tests have verified that appropriate service levels and program functionality are maintained.
The registry setting that corresponds to this policy setting is as follows: HKLM\System\CurrentControlSet\Control\Lsa
Entry name: RestrictAnonymous Data type: REG_DWORD Value: 1
For more information about restricting anonymous access, see article Q246261, "How to Use the RestrictAnonymous Registry Value in Windows 2000," and related articles in the Microsoft Knowledge Base.
You can create a script that automatically restricts anonymous access on all domain controllers in the domain by performing the following tasks:
Create the ComputerSearch.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Identifying Computers to Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B: Procedures" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.
Create a list of domain controllers in the domain by typing the following command at a command prompt:
Cscript computersearch.vbs /r:DC
This command creates a list of domain controllers in the domain and saves this list as ComputerSearch*-date-time.*csv.
Create the ApplyReg.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Applying Registry Settings to a List of Computers with ApplyReg.vbs" in "Appendix B: Procedures" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.
Create a .reg file for the following path, registry entry, and value:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa] "RestrictAnonymous"=dword:00000001
Save the file as *Registryfile*.reg. For information about how to create the .reg file, see "Creating a .reg File" in "Appendix: Procedures" later in this guide:
Apply the registry entry to the domain controllers by typing the following command at the command prompt:
Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-date-time.csv
This set of tasks applies the registry changes that are expressed in the file *Registryfile*.reg to all computers that are listed in the file ComputerSearch-*date*-*time*.csv.
Disabling LAN Manager Authentication
By default, earlier versions of Windows operating systems support only the LAN Manager (LM) authentication protocol. To provide compatibility with these earlier versions of Windows, Active Directory stores the account passwords in an LM hash format. Active Directory stores the password for the Windows NT authentication protocol (NTLM) and NTLM version 2 (NTLMv2) protocols in NTLM hash format.
Because the NTLM hash is cryptographically stronger than the LM hash, disable the storage of passwords in LM hash format to provide higher security. In the event that an attacker removes a domain controller or a domain controller hard disk, it is easier for that attacker to decrypt the passwords in LM hash format.
When you use a SYSKEY password or floppy disk, you encrypt the entire Active Directory database and protect any passwords. When you use one of these SYSKEY methods, there is no benefit to disabling the storing of passwords in LM hash format, aside from reducing the size of the Active Directory database.
For more information about allowing only the NTLMv2 authentication protocol, see articles 285901, "Remote Access and VPN Clients Cannot Connect to a Server with NtlmcompatabilityLevel Set to 5"; 281648, "Error Message: The Account Is Not Authorized to Login from This Station"; and Q239869, "How to Enable NTLM 2 Authentication for Windows 95/98/2000 and NT" in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441.
Disable the storing of passwords in LM hash format by performing the following tasks:
Configure all domain controllers, member servers, and workstations to support the NTLMv2 authentication protocol.
Table 33 lists the operating systems and the software requirements to support the NTLMv2 authentication protocol.
Table 33 Operating System and Software Requirements to Support NTLMv2
Operating System
Requires
Windows 95, Windows 98, Windows Me
The Directory Services Client (Dsclient.exe), found in the Clients\Win9x folder on Windows 2000 CD-ROM.
Windows NT 4.0 Workstation and Server
Service Pack 4 (SP4) or later.
Windows 2000 Professional and Server
Included as part of the operating system.
Windows XP Professional
Included as part of the operating system.
Configure the domain controller Group Policy setting LAN Manager Authentication Level found in Table 31 to the value Send NTLMv2 responses/reject LM.
Configure each domain controller registry setting to disable the creation of passwords in LM hash format by modifying the registry key HKLM\System\CurrentControlSet\Control\Lsa:
Entry name: NoLMHash Data type: REG_DWORD Value:* *1
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
You can create a script that automatically disables the creation of passwords in LM hash format on all domain controllers in the domain by performing the following tasks:
Create the ComputerSearch.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Identifying Computers to Receive New Registry Settings with ComputerSearch.vbs" in "Appendix B: Procedures" of the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II.
Create a list of domain controllers in the domain by typing the following command at a command prompt:
Cscript computersearch.vbs /r:DC
This command creates a list of domain controllers in the domain and saves this list as ComputerSearch*-date-time.*csv.
3. Create the ApplyReg.vbs script, and copy it to a computer that is a member of the domain.
For information about how to create this script, see "Applying Registry Settings to a List of Computers with ApplyReg.vbs" in "Appendix B: Procedures" of the *Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations:* *Part II*.
4. Create a .reg file for the following path, registry entry, and value:
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] "NoLMHash"=dword:00000001
Save the file as *Registryfile*.reg. For information about how to create the .reg file, see "Creating a .reg File" in :Appendix: Procedures" later in this guide.
Apply the registry entry to the domain controllers by typing the following command at the command prompt:
Cscript ApplyReg.vbs /r:registryfile.reg /f:ComputerSearch-date-time.csv
This set of tasks applies the registry changes that are expressed in the file *Registryfile*.reg to all computers that are listed in the file ComputerSearch-*date*-*time*.csv.
Require all users to change their passwords immediately.
The passwords that are already created in LM hash format are retained until the users change their passwords. Forcing password changes eliminates any passwords that are stored in LM hash format.
Enabling SMB Signing on Domain Controllers
The SMB protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent "man-in-the-middle" attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets.
Domain controllers, member servers, and workstations access file shares during the user logon process to access logon scripts and profiles in the NETLOGON share. In addition, domain policies are accessed through the SYSVOL share. As a result, all domain controllers should take advantage of SMB to improve security.
You can specify Group Policy settings that make SMB signing a requirement or that allow the SMB server or client to negotiate SMB packet signing. Table 34 lists the Group Policy settings for SMB signing, and it explains how each setting affects client and server communications.
Table 34 Group Policy Settings for SMB Packet Signing
SMB Setting |
Explanation |
---|---|
Digitally sign client communication (always) |
The domain controller requires SMB signing when initiating SMB requests with other domain controllers, member servers, or workstations. The domain controller will not communicate with other systems that do not support SMB signing. For enhanced security, enable this Group Policy setting. |
Digitally sign client communication (when possible) |
The domain controller negotiates SMB signing when initiating SMB requests with other domain controllers, member servers, or workstations. The domain controller requests SMB signing, but it will communicate with other systems that do not support SMB signing. For compatibility with Windows 95 and earlier operating systems, enable this Group Policy setting. |
Digitally sign server communication (always) |
The domain controller requires SMB signing when receiving SMB requests from other domain controllers, member servers, or workstations. The domain controller will not communicate with other systems that do not support SMB signing. For higher security, enable this Group Policy setting. |
Digitally sign server communication (when possible) |
The domain controller negotiates SMB signing when receiving SMB requests with other domain controllers, member servers, or workstations. The domain controller requests SMB signing, but it will communicate with other systems that do not support SMB signing. For compatibility with Windows 95 and earlier operating systems, enable this Group Policy setting. |
Enable the Digitally sign client communication (when possible) and Digitally sign server communication (always) Group Policy settings on your domain controller unless:
Your network has a large number of Windows 95 and earlier operating systems, and you are unable to upgrade these systems to Windows 98 or later operating systems. (SMB signing requires Windows 98 and later operating systems.)
Your domain controllers, member servers, and workstations have insufficient available processor utilization to support SMB signing. SMB signing generates higher processor utilization on the client and server side (an increase of up to 15 percent in processor utilization).
Enabling Digitally sign server communication (always) on your domain controller overrides the default value of Digitally sign server communication (when possible).
Note: By default, the local policy on stand-alone computers does not perform SMB signing. Therefore, if a domain controller with the setting Digitally sign client communication (always), attempts to communicate with a server that does not perform SMB signing, the operation fails.
Disabling Pre-Windows 2000 Compatible Access
In some instances, your domain controllers are already installed and configured with Pre-Windows 2000 Compatibility enabled. For security reasons, you should, if possible, disable Pre-Windows 2000 Compatibility to prevent anonymous access to Active Directory.
As previously discussed, enabling Pre-Windows 2000 Compatibility allows certain applications, such as Routing and Remote Access Service on Windows NT 4.0, to query information about Active Directory objects. These applications run in the security context of the Local System. When they attempt to query Active Directory, they do so as anonymous users. Enabling Pre-Windows 2000 Compatibility allows anonymous Read access to these applications.
In Active Directory, the group Pre-Windows 2000 Compatible Access is assigned Read permissions on the domain root and on user, computer, and group objects. When you enable Pre-Windows 2000 Compatibility, the special group Everyone is added to the group Pre-Windows 2000 Compatible Access. Because Everyone includes anonymous users, in addition to authenticated users, anonymous users can read these objects.
The process for identifying the server and applications that require anonymous access to Active Directory is discussed in general in "Allowing Anonymous Access to Domain Controllers" earlier in this guide. However, the specifics on how to eliminate the requirement for anonymous access and how to disable anonymous access on your domain controller are provided in the following sections, below:
"Eliminating the Requirement for Pre-Windows 2000 Compatibility"
"Disabling Pre-Windows 2000 Compatibility on Your Domain Controllers"
For more information about Pre-Windows 2000 Compatibility, see articles 257942, "Error Message: Unable to Browse the Selected Domain Because the Following Error Occurred ..."; 303973, "HOW TO: Add Users to the Pre-Windows 2000 Compatible Access Group"; 240855, "Using Windows NT 4.0 RAS Servers in a Windows 2000 Domain"; 254311, "Enable Windows NT 4.0-Based RAS Servers in a Windows 2000-Based Domain"; and 266712, "SMS: Security Based on Global Groups Fails in Windows 2000 Domains" in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441.
Eliminating the Requirement for Pre-Windows 2000 Compatibility
Typically, a newer version of the software, for example Routing and Remote Access in Windows 2000, does not require anonymous access. You must upgrade to a newer version of the software before you can disable Pre-Windows 2000 Compatibility.
Disabling Pre-Windows 2000 Compatibility on Your Domain Controllers
After you are certain that no applications are establishing anonymous connections to your domain controllers, you are ready to disable Pre-Windows 2000 Compatibility. You can do this by removing the special group Everyone from the group Pre-Windows 2000 Compatible Access and adding the special group Authenticated Users to the group Pre-Windows 2000 Compatible Access.
To disable Pre-Windows 2000 Compatibility
On the PDC emulator role holder, remove Everyone from the Pre-Windows 2000 Compatible Access group.
Add Authenticated Users to the Pre-Windows 2000 Compatible Access group.
Wait for changes to replicate to all domain controllers in the domain.
Note: You can push the changes to other domain controllers by using the following command:
repadmin /syncall /d/e/P/q DNS name of the PDC emulator role holder
On every domain controller in the domain, run the following command:
net session /delete
For more information about performing this task, see "Disabling Pre-Windows 2000 Compatibility" earlier in this guide.
Applying Selected Domain and Domain Controller Security Settings
The changed policy settings recommended in this chapter apply to either the default domain Group Policy or the default Domain Controllers OU Group Policy. After you have selected the list of settings that you want to update according to the business considerations and security requirements for your environment, the method that you use to make the necessary changes depends on the specific policy or settings that are updated.
To apply the recommended security updates, you can modify Group Policy in one of two ways. First, you can modify the default domain policy and the default Domain Controllers OU policy directly to update policy settings. Second, you can create a new Group Policy object (GPO) with the modified settings and link it above the default GPO so that the changed settings take precedence over the default settings.
When you apply changes to Group Policy settings in the following policies, the changes must be made directly in the default domain GPO or in the default Domain Controllers OU GPO:
Domain password policy
Domain account lockout policy
Domain Kerberos policy
Domain Controller User Rights Assignment policy
Domain Controller Audit policy
Important: Policy setting changes to the policies listed above must be made in the default policy, because the APIs from previous versions of the operating system change the settings for these policies by making updates directly to the default policy GPO.
Table 35 lists the Active Directory locations where the default policies are applied, the type of settings in each default policy, and the method for applying the recommended changes to the Group Policy settings.
Table 35 Methods for Applying Changed Settings in Group Policy
Location Where Policy Is Applied |
Policy Settings Being Changed |
How to Apply the Changed Settings in Policy |
---|---|---|
Domain root |
Domain security policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) |
Make all changes to the default domain GPO. |
Domain Controllers OU |
User Rights Assignment |
Make all changes to the default Domain Controllers OU GPO. |
|
Audit |
Make all changes to the default Domain Controllers OU GPO. |
|
Event Log |
Create a new GPO, and link this GPO above the default Domain Controllers OU GPO. |
|
Security Options |
Create a new GPO, and link this GPO above the default Domain Controllers OU GPO. |
When a new Windows 2000 domain is created, Active Directory creates a domain object and a built-in, protected OU called OU=Domain Controllers directly under the domain root for domain controllers. Active Directory places the new domain controller computer account in this special OU. As additional domain controllers are promoted, the corresponding computer accounts are also placed in the Domain Controllers OU. Figure 11 shows the Domain Controllers OU and two of the default containers that are created when Active Directory is installed.
Figure 11 Default Containers and OU Created by Active Directory
All domain controller computer accounts in a domain should remain in the default Domain Controllers OU to ensure that domain-controller-specific Group Policy settings are consistently applied to all domain controllers in a domain.
Note: In addition to the Domain Controllers OU, Active Directory also builds two containers: Users and Computers. Unlike the Domain Controllers OU, Users and Computers represent containers; therefore, Group Policy settings cannot be applied to objects in these containers.
Modifying the Default Group Policy for the Domain and the Domain Controllers OU
Apply changes directly in the default domain GPO for Password Policy settings, Account Lockout Policy settings, and Kerberos Policy settings. Apply changes directly in the default Domain Controller OU GPO for User Rights Assignment Policy settings and Audit Policy settings.
Update the default domain and Domain Controllers OU GPOs by following the procedure "Updating the Default Group Policy on the Domain and the Domain Controllers OU" in "Appendix: Procedures" later in this guide.
Applying a New GPO to the Domain Controllers OU
As a best practice, you should create and link a new GPO above the default policy when you want to apply changed policy settings to the entire domain or domain controllers, with the exception of the policies listed earlier that must be changed directly in the default policy. The advantage of this approach is that if a problem is encountered because of the changed settings, the new GPO can very easily be backed out, restoring the original policy settings.
Apply the changed policy settings to the default Domain Controllers OU policy through a new GPO by following the procedure "Linking a New Policy to the Domain Controller OU-Level GPOs" in "Appendix: Procedures" later in this guide.
Recommendations: Establishing Secure Domain and Domain Controller Policy Settings
You can create secure domain and domain controller policy settings by following the security recommendations described earlier in this section. Of course, as previously mentioned, your comprehensive Active Directory security plan should also take into consideration the recommendations that are described in the other sections of this guide.
Recommendations for Establishing Secure Domain Policy Settings
The following table provides a checklist of recommendations for ensuring that your domain and domain controller policy settings are applied in a secure and consistent manner.
Check |
Securing Password Policy Settings for Domains |
|
Apply the password policy settings in Table 14 at the domain level. |
Check |
Securing Account Lockout Policy Settings for Domains |
|
Apply the account lockout policy settings in Table 15 at the domain level. |
Check |
Securing Kerberos Policy Settings for Domains |
|
Apply the Kerberos policy settings in Table 16 at the domain level. |
Recommendations for Establishing Secure Domain Controller Policy Settings
The following table provides a checklist of recommendations for ensuring that your domain controller policy settings are applied in a secure and consistent manner.
Check |
Establishing Domain Controller User Rights Assignment Policy Settings |
|
Apply the domain controller User Rights Assignment policy settings in Table 17. |
Check |
Establishing Domain Controller Audit Policy Settings |
|
Enable auditing to provide accountability for sensitive operations. |
|
When needed, enable additional auditing for other requirements, such as intrusion detection. |
|
Apply the domain controller Audit policy settings in Table 18. |
Check |
Enabling Auditing on Active Directory Database Objects |
|
Enable auditing on the Schema directory partition. |
|
Enable auditing on the Configuration directory partition. |
|
Enable auditing on the Domain directory partition. |
Check |
Establishing Domain Controller Security Options Policy Settings |
|
Apply the domain controller Security Options policy settings in Table 31. |
Check |
Establishing Domain Controller Event Log Policy Settings |
|
Apply the domain controller event log policy settings in Table 32. |
Recommendations for Selecting Policy Settings for Mixed Operating System Environments
The following table provides a checklist of recommendations for securing Active Directory in mixed operating system environments.
Check |
Identifying When Earlier Versions of Operating Systems Are an Issue |
|
Identify users that are authenticated with earlier versions of authentication protocols. |
|
Identify computers that do not support SMB signing. |
|
Identify anonymous access to domain controllers. |
Check |
Restricting Anonymous Access to Domain Controllers |
|
Change the Security Option policy Additional restrictions for anonymous connections to Do not allow enumeration of SAM accounts and shares. |
|
Configure the registry setting for RestrictNullSessAccess to Reg_Dword=1. |
Check |
Disabling LAN Manager Authentication |
|
Configure the registry setting for NoLMHash to Reg_Dword=1. |
Check |
Enabling SMB Signing on Domain Controllers |
|
Enable SMB client and server signing so that SMB signing is always required. |
Check |
Disabling Pre-Windows 2000 Compatible Access |
|
Disable Pre-Windows 2000 Compatibility. |
Recommendations for Applying Selected Domain and Domain Controller Security Settings
The following table provides a checklist of recommendations for ensuring that your domain controller policy settings are applied in a secure and consistent manner.
Check |
Updating Group Policy settings |
|
Create a new GPO for the recommended domain policies. |
|
Create a new GPO for the recommended domain controller policies. |
|
Link the domain security template to the domain GPO. |
|
Link the domain controller security template to the Domain Controllers OU GPO. |
|
Set each new security policy with the highest precedence. |
Check |
Applying New GPOs to the Domain and Domain Controllers OU |
|
Ensure that all domain controller computer accounts reside in the Domain Controllers OU. |
Chapter 5: Establishing Secure Administrative Practices
Any user who has administrative access to domain controllers can cause breaches in security. Individuals seeking to damage the system may be unauthorized users who have obtained administrative passwords, or they may be legitimate administrators who are coerced or disgruntled for one reason or another. Furthermore, not all problems are caused with malicious intent. An inexperienced user who is granted administrative access may inadvertently cause problems by failing to understand the ramifications of configuration changes.
You can minimize these problems by carefully controlling the scope of influence that you give your administrative accounts. For the day-to-day management of your environment, avoid using all-powerful administrative accounts that have complete access to every domain controller and full access to the directory. Instead, configure your administrative accounts so that their scope of influence is limited to the specific containers in Active Directory that they need to do their jobs. In the event that one of these accounts is misused, this will limit the amount of damage that can be done.
For Windows 2000 Active Directory, there are two types of administrative responsibility: service management and data management. Service administrators are responsible for maintaining and delivering the directory service. This includes managing the domain controllers and configuring the directory service. Data administrators are responsible for maintaining the data that is stored in the directory service and on domain member servers.
Service administrators are responsible for the delivery of the directory service, directory-wide settings, installation and maintenance of software, and application of operating system service packs and fixes on domain controllers. To perform these functions, service administrators must have physical access to domain controllers.
Data administrators are responsible for managing data that is stored in the directory and on computers that are members of the forest. They have no control over the configuration and delivery of the directory service itself. Data administrators control subsets of objects in the directory. Using access control list (ACL) settings on objects that are stored in the directory, it is possible to limit the control of a given administrator account to very specific areas of the directory. Data administrators also manage computers (other than domain controllers) that are members of their domain. Data administrators can perform all of their responsibilities from management workstations, and they do not need physical access to the domain controllers.
Some information that is needed to manage or configure the Active Directory service is controlled by objects that are stored in directory itself. Even though this information is stored in the directory, it is used and managed by service administrators. Because of this, service administrators can act as data administrators. As a result of their limited access, data administrators cannot act as service administrators.
Establishing Secure Service Administrative Practices
Service administrators have the ability to configure domain controllers and control your Active Directory environment. They are responsible for installing and maintaining all software, including the operating system and patches, on all domain controllers. They control server settings and networking options on domain controllers. They also manage the overall configuration of the directory service, including replication behavior, schema management, and domain creation and deletion. Service administrators have the most widespread power in your environment.
Because of the elevated privileges of service administrators, steps must be taken to keep the service administrator accounts secure. There are two aspects to securing your service administrator accounts. You can control:
How the accounts are used, by securing the service administrator accounts themselves.
Where the accounts can be used, by securing the service administrator workstations.
Securing Service Administrator Accounts
Like regular user access, administrative access to resources is controlled by the ACLs that are set on the various resources being managed and by the privileges that are granted to the administrative accounts. Active Directory has a number of default service administrator accounts. By default, these accounts are granted access to directory and server resources when Active Directory is installed. Table 36 lists the default service administrator accounts and provides a brief description of each account.
Table 36 Default Service Administrator Accounts
Account Name (Mnemonic) |
Scope |
Description |
---|---|---|
Enterprise Admins (EA) |
Forest |
This group is automatically added to the Administrators group in every domain in the forest, providing complete access to the configuration of all domain controllers. This group can modify the membership of all administrative groups. Its own membership can be modified only by the default service administrator groups in the root domain. This account is considered a service administrator. |
Schema Admins (SA) |
Forest |
This group has full administrative access to the schema. The membership of this group can be modified by any of the service administrator groups in the root domain. This account is considered a service administrator because its members can modify the schema, which governs the structure and content of the entire directory. |
Administrators (BA) |
Domain |
This built-in group controls access to all the domain controllers in its domain, and it can change the membership of all administrative groups. Its own membership can be modified by the default service administrator groups BA and DA in the domain, as well as the EA group. This group has the special privilege to take ownership of any object in the directory or any resource on a domain controller. This account is considered a service administrator because its members have full access to the domain controllers in the domain. |
Domain Admins (DA) |
Domain |
This group controls access to all domain controllers in a domain, and it can modify the membership of all administrative accounts in the domain. Its own membership can be modified by the service administrator groups BA and DA in its domain, as well as the EA group. This is a service administrator account because its members have full access to a domain's domain controllers. |
Server Operators (SO) |
Domain |
By default, this built-in group has no members, and it has access to server configuration options on domain controllers. Its membership is controlled by the service administrator groups BA and DA in the domain, as well as the EA group. It cannot change any administrative group memberships. This is a service administrator account because its members have physical access to domain controllers and they can perform maintenance tasks (such as backup and restore), and they have the ability to change binaries that are installed on the domain controllers. |
Account Operators (AO) |
Domain |
By default, this built-in group has no members, and it can create and manage users and groups in the domain, including its own membership and that of the SO group. This group is a service administrator because it can modify the SO group, which in turn can modify domain controller settings. As a best practice, you should leave the membership of this group empty and not use it at all for any delegated administration. |
Backup Operators (BO) |
Domain |
By default, this built-in group has no members, and it can perform backup and restore operations on domain controllers. Its membership can be modified by the default service administrator groups BA and DA in the domain, as well as the EA group. It cannot modify the membership of any administrative groups. While members of this group cannot change server settings or modify the configuration of the directory, they do have the permissions needed to replace files (including operating system binaries) on the domain controllers. Because of this, they are considered service administrators. |
Administrator |
DS Restore Mode |
This special account is created during the Active Directory installation process, and it is not the same as the Administrator account in the Active Directory database. This account is only used to start the domain controller in Active Directory Restore mode. When it is in restore mode, this account has full access to the directory database, as well as files (including operating system binaries) on the domain controller. Because of this, this account is considered a service administrator. |
Limiting the Exposure of Service Administrator Accounts
Service administrator accounts are highly privileged, making them desirable as targets for attack. Therefore, it is especially important to protect the integrity of these accounts. The recommendations in this section of the guide are designed to enhance the security of your service administrator accounts. Limiting the exposure of the service administrator accounts gives attackers fewer targets of opportunity. Observe the practices in the following sections to limit the exposure of service administrator accounts.
Limiting the Number of Service Administrator Accounts
Keep the membership of service administrator accounts to the absolute minimum that is necessary to support your organization. Do not use service administrator accounts for day-to-day administrative tasks, such as account and member server management; instead, delegate these tasks to data administrators. Tasks that are performed by service administrators should be limited to changing the Active Directory service configuration and reconfiguring domain controllers, and they should not include normal, day-to-day operations.
Separating Administrative and User Accounts for Administrative Users
For users who fill administrative roles, create two accounts: one regular user account that to be used for normal, day-to-day tasks and one administrative account to be used only for performing administrative tasks. The administrative account should not be mail enabled or used for running applications that are used every day, such as Microsoft Office, or for browsing the Internet. These precautions reduce the exposure of the accounts to the outside world, and they reduce the amount of time that administrative accounts are logged on to the system.
Hiding the Domain Administrator Account
Every installation of Active Directory has an account named Administrator in each domain. This is the default administrative account, which is created during domain setup, that you use to access and administer the directory service. This is a special account that the system protects to help ensure that it is available when needed. This account cannot be disabled or locked out.
The fact that this account is always created during domain setup, cannot be deleted, and cannot be disabled means that every malicious user who attempts to break into your system will assume that the account exists and that can it can be used as a target. For this reason, you should rename it to something other than Administrator. When you rename the account, make sure that you also change the text in the Description field for the account. In addition, you should create a decoy user account, called Administrator, that has no special permissions or user rights.
To hide the default Administrator account, perform the following tasks:
Rename the default Administrator account. For a procedure to perform this task, see "Renaming the Default Administrator Account" in "Appendix: Procedures" later in this guide.
Create a decoy Administrator account with no special permissions or privileges. For a procedure to perform this task, see "Creating a Decoy Administrator Account" in "Appendix: Procedures" later in this guide.
Managing Service Administrators in a Controlled Subtree
To help protect highly privileged service administrator accounts, allow only service administrators to manage service administrator accounts. Because such accounts have elevated privileges, data administrators should not be given the authority to modify these accounts. Doing so allows data administrators to elevate their privileges. Service administrator accounts should be accessed and managed in a highly controlled subtree in each domain.
To provide a more controlled environment that facilitates the management of service administrator accounts and workstations, create a controlled subtree to manage service administrator accounts in Active Directory, as shown in Figure 12. The controlled subtree structure should be created for each domain by a member of the Domain Admins group for that domain, and it should be configured with the recommended security settings.
By creating your own subtree containing all service administrator accounts and the administrative workstations that they use, you have the ability to apply controlled security and policy settings to them to maximize their protection. Figure 12 shows an example of a controlled administrative subtree and its access control settings.
Figure 12 Sample Subtree for Managing Service Administrator Accounts
To create the controlled subtree, perform the following tasks:
Create the organizational unit (OU) structure for the controlled subtree.
Set the ACLs on the controlled subtree OUs.
Add service administrator groups to the controlled subtree.
Add service administrator user accounts to the controlled subtree.
Add service administrator workstation accounts to the controlled subtree.
Enable auditing on the controlled subtree.
Protect service administrator groups outside the controlled subtree.
The steps that follow describe each of the tasks in greater detail.
Step 1: Create the OU structure for the controlled subtree.
Create a high-level OU to hold the groups and user accounts that constitute your service administrators and their workstations. Within that OU, create one OU to hold administrative user and group accounts and another OU for administrative workstations.
Figure 12 depicts a recommended OU hierarchy for the controlled subtree to manage service administrator accounts and workstations. It consists of a controlled subtree rooted at the Service Admins OU that contains two additional OUs: the Users and Groups OU, to hold the administrative user and group accounts, and the Administrative Workstations OU, to hold the computer accounts of the workstations that are used by the service administrators.
Step 2: Set the ACLs on the controlled subtree OUs.
To limit access to the controlled subtree such that only service administrators would typically be able to administer the membership of service administrator groups and workstations, do the following:
Block inheritance of permissions on the Service Admins OU so that future changes that are made higher up in the domain tree are not inherited down, altering the locked-down settings.
Set the ACL on the Service Administrators OU, as indicated in Table 37.
Table 37 ACL Settings for the Service Administrators OU
Type
Name
Access
Applies To
Allow
Enterprise Admins
Full Control
This object and all child objects
Allow
Domain Admins
Full Control
This object and all child objects
Allow
Administrators
Full Control
This object and all child objects
Allow
Pre-Windows 2000 Compatible Access
List Contents
Read All Properties
Read Permissions
User Objects
Step 3: Add service administrator groups to the controlled subtree.
Move the following service administrator groups from their current location in the directory into the Users and Groups OU in your controlled subtree:
Domain Admins
Enterprise Admins (if this is the root domain of the forest)
Schema Admins (if this is the root domain of the forest)
For complete protection of service administrator groups, it would be ideal to move the built-in groups from Table 36 (Administrators, Server Operators, Account Operators, and Backup Operators) to the controlled subtree. However, built-in groups cannot be moved from their default container. Step 7 explains how to protect those accounts.
Step 4: Add service administrator user accounts to the controlled subtree.
Move all administrative user accounts that are members of any of the service administrator groups listed in Table 36 from their current locations in the directory into the Users and Groups OU in your controlled subtree. This also includes the domain Administrator account.
As recommended, each service administrator should have two accounts: one for administrative duties and one for their normal user access. Place the administrative user accounts in the Users and Groups OU in your controlled subtree. If these accounts already exist elsewhere in the directory, move them into the subtree now. The regular user account for those administrators should not be placed in this controlled subtree.
Step 5: Add service administrator workstation accounts to the controlled subtree.
Designate administrator's computers as administrative workstations. Move the computer accounts for those workstations into the Administrative Workstations OU in your controlled subtree.
Important: Do not move any domain controller accounts out of the default Domain Controllers OU, even if some administrators log on to them to perform administrative tasks. Moving these accounts will disrupt the consistent application of domain controller policies to all domains.
Step 6: Enable auditing on the controlled subtree.
It is important to audit and track any additions, deletions, and changes to the service administrator accounts and workstations - and changes in policies that are applied to them - so that improper or unauthorized changes can be detected.
Assuming that you have enabled auditing on your domain controllers in accordance with the recommendations in Chapter 4, "Establishing Secure Domain and Domain Controller Policies," set the system access control list (SACL) on the Service Administrators OU, as specified in Table 38. Monitor the security audit log for changes to the controlled subtree so that you can ascertain that the changes are legitimate.
Table 38 SACL Settings on OU=Service Admins,DC=Domain,DC=...ForestRootDomain
Type |
Name |
Access |
Applies To |
---|---|---|---|
Allow |
Everyone |
Write All Properties Delete Delete Subtree Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects |
This object and all child objects |
Step 7: Protect service administrator groups outside the controlled subtree.
Some of the built-in service administrator accounts are protected by special default security descriptor settings that are applied during the installation of Active Directory. These settings are described in the following section, "Protecting the Service Administrator Accounts." However, the Server Operators, Backup Operators, and Account Operators groups are not protected by these settings.
Also, because these are built-in accounts, they cannot be moved to the controlled subtree for protection. To protect these three groups, apply the same default ACL that is used to protect the other service administrator accounts, as listed in Table 39.
At this point, your controlled subtree for service administrators is set up and ready for use.
Protecting the Service Administrator Accounts
To prevent the security descriptors on the key service administrator accounts in each domain from being modified and possibly becoming unusable, a background process runs on the primary domain controller (PDC) emulator operations master that periodically checks and applies a standard security descriptor on the protected accounts. This background process overwrites the administrative policies that are stored as the protected settings in the AdminSDHolder object to protect service administrator accounts. This process starts 15 minutes after the system boots and then runs once every half hour thereafter. This refresh interval is not configurable.
This process ensures that if a hostile user or other administrator does manage to modify the security descriptor on one of the administrative accounts, the modified security descriptor is overwritten and replaced with the standard security descriptor within a half hour.
In Windows 2000 Active Directory, the following administrative groups and all their nested member groups and users are protected with this process:
Administrators
Domain Admins
Enterprise Admins
Schema Admins
The master security descriptor for service administrator accounts is stored as the security descriptor attribute of the AdminSDHolder object, which is located in the system container (CN=AdminSDHolder,CN=System,DC=DomainName) of the domain directory partition.
The security descriptor on this object serves two purposes. First, it controls access to the AdminSDHolder object itself. Second, it acts as the master security descriptor that is periodically applied to the service administrator accounts listed above and their members to ensure that they remain protected. The default settings in the master security descriptor of the AdminSDHolder object are listed in Table 39.
Table 39 Default Permissions on the AdminSDHolder Object on CN=AdminSDHolder,CN=System,DC=DomainName,DC=...ForestRootDomain
Type |
Name |
Permission |
Apply To |
---|---|---|---|
Allow |
Everyone |
Change Password |
This Object Only |
Allow |
Administrators |
List Contents Read All Properties Write All Properties Delete Read Permissions Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects |
This Object Only |
Allow |
Authenticated Users |
List Contents Read All Properties Read Permissions |
This Object Only |
Allow |
Domain Admins |
List Contents Read All Properties Write All Properties Read Permissions Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects |
This Object Only |
Allow |
Enterprise Admins |
List Contents Read All Properties Write All Properties Read Permissions Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects |
This Object Only |
Allow |
Pre-Windows 2000 Compatible Access |
List Contents Read All Properties Read Permissions |
Special |
Allow |
SYSTEM |
Full Control |
This Object Only |
If you want to modify the security descriptor on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object so that it will be applied consistently. Be careful when making these modifications, because you are also changing the default settings that will be applied to all of your protected administrative accounts.
Configure the default security descriptor settings on the service administrator accounts by changing the security descriptor on AdminSDHolder. For a procedure to perform this task, see "Changing the Security Descriptor on AdminSDHolder" in "Appendix: Procedures" later in this guide.
Hiding the Membership of the Service Administrator Groups
Because members of the service administrator groups are highly privileged, they constitute an attractive target for attackers. Therefore, the membership information of these groups should be guarded as much as possible. For maximum security, it is best to hide the membership information for all service administrator groups from regular users. However, the default security descriptor on AdminSDHolder that is used to protect service administrator groups allows their membership information to be visible to regular users.
The entry in Table 39 that grants Read Access to Authenticated Users allows them to list the membership information for all service administrator groups. Some applications and services rely on this access control entry (ACE) to enumerate the members of an administrative group. For example, applications such as SQL Server, which run under service accounts, may read the list of administrative group members to make its own application-specific access control decisions. Other third-party applications and line-of-business (LOB) applications may also rely on this capability. Because there is no way to anticipate every service account that will need this type of read access, the Authenticated Users entry exists to support all such cases.
It is possible to tighten security further by removing access for Authenticated Users from the security descriptor on AdminSDHolder. Because this can cause some server-based applications to stop functioning, care must be taken when doing this. Systematically remove access for Authenticated Users by performing the following set of tasks:
If you have not already done so, disable Pre-Windows 2000 Compatible Access for your domain. For more information, see "Disabling Pre-Windows 2000 Compatible Access" earlier in this guide.
Create a group called "Server Applications," and grant it Read access to AdminSDHolder by adding the ACE, as shown in Table 40.
Add the individual service accounts used by your applications that require the ability to enumerate group membership of the service administrator groups to this group.
Remove the Authenticated User entry and the Pre-Windows 2000 Compatible Access entry from the security descriptor.
Table 40 ACL Change on AdminSDHolder for the Server Applications Group
Type
Name
Permission
Apply To
Allow
Server Applications
List Contents
Read All Properties
Read Permissions
This Object Only
At this point, your service administrator accounts should not be visible to regular users on your network. Because it is impossible to predict the impact on every application, closely monitor applications running in your environment, and make sure that they still function properly. If you observe application problems, simply add Authenticated Users as a member of the newly created Server Applications group to restore functionality while you diagnose how to remove the application dependency.
Managing Group Memberships for Service Administrator Accounts
To enhance security, we recommend limiting the membership in each of the service administrator groups to the absolute minimum that your organizational logistics allow, while still enabling you to manage your Active Directory service functions. This reduces the number of possible administrative accounts that can be compromised by hostile users. The following sections explain some recommended practices for managing the membership of the service administrator groups.
Assigning Trustworthy Personnel
Service administrators control the configuration and functioning of the directory service. Therefore, this responsibility should be given only to reliable, trusted users who have demonstrated responsible ownership and who fully understand the operation of the directory. They should be completely familiar with your organization's policies regarding security and operations, and they should have demonstrated their willingness to enforce those policies
Restricting Service Group Membership to Users in the Forest
Do not include users or groups from another forest as members of service administrator groups, unless you completely trust the service administrators of the other forest. Because service administrators in the other forest have full control on the user accounts in that forest, they can easily impersonate or authenticate to your forest using the credentials of one of those users. Further, by trusting the remote domain (or forest) in this way, you also trust their security measures, which is something over which you have no control.
If it is necessary to have a user from another forest act as a service administrator in your domain, create an account in your domain that he or she can use when performing the administrative role. This eliminates your dependence on the security measures of the other forest.
Limiting the Schema Admins Group to Temporary Members
The Schema Admins group is a special group in the forest root domain that provides administrative access to the Active Directory schema. Members of this group have the necessary user rights to make changes to the schema. In general, because schema changes are only made rarely, it is not necessary for a schema administrator to be available at all times. This account is needed only when a schema update must be processed or if a change must be made to the configuration of the schema operations master role holder.
To minimize the possibility of an Active Directory attack through a schema administrator account, keep the membership of the Schema Admins group empty. Add a trusted user to the group only when an administrative task must to be performed on the schema. Remove the member after the task is completed.
Limiting Administrator Rights to Those Rights That Are Actually Required
Active Directory contains a built-in group named Backup Operators. Members of this group are considered service administrators, because the group's members have the privilege to log on locally and restore files, including the system files, on domain controllers. Membership in the Backup Operators group in Active Directory should be limited to those individuals who back up and restore domain controllers.
All member servers also contain a built-in group called Backup Operators that is local to each server. Individuals who are responsible for backing up applications (for example, SQL Server) on a member server should be made members of the local Backup Operators group on that server - as opposed to the Backup Operators group in Active Directory.
On a dedicated domain controller, you can reduce the number of members in the Backup Operators group. When a domain controller is used for running other applications, as it might be in a branch office, individuals who are responsible for backing up applications on the domain controller must also be trusted as service administrators, because they will have the privileges necessary to restore files, including system files, on domain controllers.
Avoid using the Account Operators group for strictly delegating a "data administration" task, such as account management. Because the default directory permissions give this group the ability to modify the membership of other service administrator groups, such as Server Operators, a member of the Account Operators group can elevate his or her privileges to become a service administrator. By default, there are no members of the Account Operators group, and its membership should be left empty.
Controlling the Administrative Logon Process
The members of the Administrators, Enterprise Admins, and Domain Admins groups represent the most powerful accounts in your forest and in each individual domain. To minimize security risks, it is recommended that you take the steps in the following sections to enforce strong administrative credentials.
Requiring Smart Cards for Administrative Logon
Require your service administrators to use smart cards for their interactive logons. Besides forcing the administrative users to have physical possession of the cards to log on, smart cards also ensure the use of cryptographically strong passwords on the user accounts that are randomly generated. This helps protect against the theft of weak passwords to gain administrative access. To implement this strategy, you must have a public key infrastructure (PKI) available to authenticate the smart cards.
You can enforce the use of smart cards by enabling the Smart card is required for interactive logon option for each administrative account. If you create a subtree, as described in "Managing Service Administrators in a Controlled Subtree" earlier in this guide, set this option for each user account in the Users and Groups OU.
Require the use of smart cards for administrative logon by setting the smart card option on the administrative accounts. For procedures to perform these tasks, see "Appendix: Procedures" later in this guide.
For more information about using smart card authentication, see "The Smart Card Deployment Cookbook" on the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=18552.
Sharing Logons for Sensitive Administrative Accounts
For each account that is a member of the Enterprise Admins and Domain Admins groups in the forest root domain, assign two users to share that account, so that both users must be present for a successful logon with that account. This provides inherent visual auditing of the use of the account, where one user observes the actions that are performed by the other. It also means that a single user cannot log on privately to access the system as an administrator and compromise its security, either as a rogue administrator or under circumstances involving coercion.
Shared administrative accounts can be implemented through either split passwords or split smart cards plus personal identification numbers (PINs). If you are using:
Password-based credentials for administrative accounts:
Split the password for the administrative account between the two users sharing that account so that each user knows only one half of the password. Each user is responsible for maintaining their half of the password. For example, you can create an administrative account called Admin1 and assign two trusted users, Jane and Bob, to share this account. Each of them maintains half of the password. For one of them to log on and use the account, the other must be present to enter the other half of the password.
Smart-card-based credentials for administrative accounts:
Split the ownership of the smart card and its PIN between the two users sharing that account so that one user retains physical ownership of the smart card and the other user maintains the PIN for the card. This way, both users must be present for the account to be used. In the example above, Jane keeps the smart card, and Bob is the only one who knows the PIN for that card.
Securing Service Administrator Workstations
In addition to limiting access to resources that are stored on the domain controllers and the information that is stored in the directory, you can also enhance security by strictly controlling the workstations that can be used by service administrators for administrative functions and by controlling the security on those workstations.
Restricting Service Administrators Logon to Administrative Workstations
Each administrative account can be restricted so that it is only allowed to log on to specific workstations. If one of your administrative accounts is compromised, this will limit the number of locations where that account can be used to log on.
The "Managing Service Administrators in a Controlled Subtree" section earlier in this guide describes the process of creating a controlled subtree of OUs to facilitate tighter control on the management of service administrator accounts. Moving the administrative workstations into this subtree makes it easy to apply Group Policy settings that control who can log on at which location.
To limit the locations where the service administrator accounts can log on, perform the following set of tasks:
Modify the User Rights Assignment policy in the default domain policy to Deny logon locally to the following groups: Administrators, Schema Admins, Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators.
For a procedure to perform this task, see "Denying Logon Access to the Domain" in "Appendix: Procedures" later in this guide.
Create and apply Group Policy settings to the Administrative Workstations OU in the controlled subtree that sets the User Rights Assignment policy to allow Log on locally to Everyone.
Enable the Deny logon locally setting in the User Rights Assignment policy for the Administrative Workstations OU.
If the Deny logon locally setting in the User Rights Assignment policy for the Administrative Workstations OU is already enabled, remove any users.
For a procedure to perform this task, see "Allowing Logon Access to Administrator Workstations" in "Appendix: Procedures" later in this guide.
Figure 13 provides a summary of policies to apply to restrict administrative logon.
Figure 13 Summary of Policies Applied to Restrict Administrative Logon
Note: The default domain controller policy, which is applied to the Domain Controllers OU, allows administrators to log on to the domain controllers. Denying logon access across the entire domain applies to all workstations and member servers.
Prohibiting the Use of Cached Credentials When Unlocking an Administrative Console
When the console on an administrative workstation is locked, either by the action of a user or automatically by a screensaver time-out, the console must be unlocked to regain access to the workstation. The workstation maintains cached credentials for any users that have been authenticated locally. When the console is unlocked, by default the workstation uses these cached credentials, if they exist, for the user who attempts to unlock the console.
When cached credentials are used to unlock the console, any changes to the account, such as user rights assignment, group membership changes, or disabling of the account, are not enforced. For example, if an administrator who is logged on to a workstation console is terminated, he or she could still unlock the console, even if his or her account were disabled. To ensure that any changes to the account are enforced immediately, require domain controller authentication of the account to unlock the console, instead of cached credentials.
Configure the administrative workstation to require domain controller authentication to unlock the workstation console by adding or modifying the following entry under the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
Entry name: ForceUnlockLogon Data type: REG_DWORD Value: 1
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
Avoiding Running Applications in Administrative Contexts
When a computer becomes a member of a domain, the Domain Admins group is automatically added to the local Administrators group on that computer. This gives members of the Domain Admins group full access to the member computer. On the downside, however, if the computer contracts a virus while a domain administrator is logged on, the virus runs in the context of that domain administrator, which is also a local administrator. This enables the virus to use the administrator's privileges to infect the workstation.
Avoid running applications in the context of a service administrator account by removing the Domain Admins group from the local Administrators group on workstations in the Administrative Workstations OU in your controlled subtree. If a service administrator contracts a virus while logged on, the virus will not have administrative access to the computer.
Avoid running application or service agents on administrative workstations in the context of an service administrator account. For example, a monitoring agent running in the context of a Domain Admins member might make it possible for compromised agent software to be used to compromise the security of the domain and the domain controllers. The local administrator account on the workstation has the necessary privileges to take control of the agent and act as the service administrator. If a user manages to gain access to the system as a local administrator, that user can then assume control of the agent and any information it is collecting.
Running Antivirus Software
Running antivirus software regularly on administrative workstations helps to protect the workstations from contracting a virus that can exploit the privileges of a logged-on service administrator to spread itself through the computer and into the domain.
Securing Traffic Between Administrative Workstations and Domain Controllers
It is possible for attackers to gain access to sensitive information by intercepting network traffic between administrative workstations and domain controllers. Managing domain controllers from administrative workstations results in two types of vulnerabilities to the data: information disclosure and data tampering.
Table 41 lists the features in Windows 2000 that can be used to secure traffic between administrative workstations and domain controllers, along with the threats that are mitigated by each feature.
Table 41 Features in Windows 2000 Used to Secure Administrative Traffic
Feature |
Information Disclosure Threat |
Data Tampering Threat |
---|---|---|
LDAP packet signing |
|
Mitigated |
Terminal Services for remote administration |
Obfuscated* |
Obfuscated |
Requiring LDAP Packet Signing on Administrator Workstations
Lightweight Directory Access Protocol (LDAP) packet signing can help prevent packet tampering between administrative workstations and domain controllers.
LDAP packet signing does not encrypt the data in the packet, and the data can still be read by someone who captures the packet. LDAP packet signing does, however, use a digital signature to help prevent the attacker from altering the packet and putting it back on the network. Digital signatures in the packet guarantee the integrity of the data. LDAP packet signing applies only to LDAP traffic to Active Directory.
To use LDAP packet signing, both the administrative workstations as well as the domain controllers must be running at least Windows 2000 with Service Pack 3 (SP3), and they must require LDAP packet signing. Update the following registry entries to enforce LDAP signing.
Configure each administrative workstation registry setting to enable LDAP packet signing by modifying the registry key HKLM\System\CurrentControlSet\Services\LDAP:
Entry name: LDAPClientIntegrity Data type: REG_DWORD Value: 2
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
Using Terminal Service for Remote Administration
Terminal Services is the graphical remote administration component in the Windows 2000 Server family. Terminal Services is built into each version of Windows 2000 Server, and it is the recommended method for all graphical remote administration tasks that are performed on computers running Windows 2000 Server
Terminal Services in Remote Administration mode enables system administrators with the appropriate permissions to remotely administer any domain controller over a TCP/IP connection. In this scenario, a system administrator can use any of the built-in Windows 2000 management tools, such as Microsoft Management Console (MMC)-based Active Directory Users and Computers, to remotely administer any domain controller in the forest. Remote management can be provided to both native and mixed mode domains.
Remote access to your domain controllers permits most administrative personnel to work from a centralized datacenter and still perform normal administrative tasks on a domain controller in a branch office site. This feature can reduce costs by minimizing the number of service administrators needed to support branch offices.
Limiting administrative access to domain controllers to a few secure workstations can also enhance Active Directory security by minimizing the number of locations where Active Directory can be administered and minimizing the number of individuals that require administrative rights and privileges.
Recommendations for securing terminal sessions between a remote client and a domain controller include the following:
Install the latest service pack on domain controllers.
Service Pack 2 (SP2) for Windows 2000 Server enhances security by hiding domain controller configuration information from a potential attacker. Service Pack 3 (SP3) provides encryption for Terminal Service client-server communications. For more information, see article 324380, "MS02-051: Cryptographic Flaw in RDP Protocol Can Cause Information Disclosure" in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441.
Install the latest version of Remote Desktop Connection on administrative workstations.
If you are using the Windows 2000 32-bit Terminal Services client, you should upgrade to the Windows Server 2003 Remote Desktop Connection. This upgrade is compatible with Windows 2000 Professional.
Coordinate remote administrative tasks with other administrators.
If you are remotely administering domain controllers with Terminal Services, ensure that only one administrator is managing a specific domain controller at the same time. This ensures that administrators do not run potentially destructive tasks at the same time. For example, two administrators might try to reconfigure the disk subsystem and undermine each other's work, or even worse, destroy data. Use the Terminal Services Manager tool or the query user command-line utility to check for the presence of other administrators.
Configure the remote desktop session to disconnect when the connection is broken.
This is the default setting, and it is especially important if you perform system updates over unreliable network connections. If a session is interrupted as a result of a network problem, the session goes into a disconnected state and continues executing the processes that were running before the interruption occurred. If the session is configured to reset when the connection breaks, all processes that are running in that session stop.
Avoid tasks that require reboots.
Some tasks (for example, system upgrades and domain controller promotion) require reboots at their completion. These tasks work correctly from within a remote desktop session, but something as simple as a floppy disk in the drive or a bad boot sector on the disk can prevent the server from restarting. Therefore, you should not remotely reboot mission-critical servers unless you have the ability to physically intervene at the server if a problem occurs.
Avoiding the Delegation of Security-Sensitive Operations
There are some forest-level and domain-level operations that should not be delegated away from the trusted service administrator accounts that they are assigned to by default. Delegation of these operations could lead to an elevation-of-privilege or denial-of-service attack, launched by the user that is delegated the task, that could impair the functionality of the entire forest or domain. Control of such operations should be retained solely within the service administrator groups. The following sections list security-sensitive operations that should not be delegated.
Restricting the Delegation of Sensitive Forest-Level Operations
The operations in Table 42 should only be performed by a member of the forest-level service administrator groups (Enterprise Admins or Schema Admins), and they should not be delegated to anyone else. Delegating these operations can lead to an elevation-of-privilege attack by a malicious user.
Table 42 Forest-Level Operations That Typically Should Not Be Delegated
Operation |
Reason Why the Operation Should Not Be Delegated |
---|---|
Installing the Enterprise Certification Authority (CA) |
This is a very crucial security operation. Any user with the authority to set up the CA has the authority needed to issue certificates to individuals that can result in elevated privileges. The authority to perform this action must remain with the most trusted service administrator account in your organization. |
Modifying Forest LDAP Policy Settings |
Some LDAP policies control the performance of domain controllers. These policies are applied across the forest. Therefore, they can affect every domain controller. If improper settings are distributed, they can result in denial of service. |
Modifying the Schema |
Modifications to the schema have forest-wide impact. Improper modifications can result in the failure of existing applications or possible directory corruption. The ability to modify schema also makes it possible to modify the default security descriptors of classes that are used to protect new objects that are created in the directory. By making changes to default security descriptors, a person can gain the ability to create security principals with elevated privileges. |
Managing Forest-Level Operations Master Roles |
A person with this ability has the authority to seize operations master roles. If done improperly, this operation can result in a directory that is unusable. Improperly seizing the domain naming operations master can result in a situation in which domains with duplicate names may be created in the forest. After they are discovered, the process of repairing them may result in trusts with other domains in the forest being rendered invalid, and portions of the forest may need to be rebuilt. If the schema operations master role is improperly seized, it can result in the existence of multiple schemas, which in turn can lead to islands of domain controllers that are associated with each copy of the schema. |
Managing Site Topology |
A person who has been delegated control over management of the site topology can launch a denial-of-service attack against every domain in the forest. This can be accomplished by breaking all inbound replication connections (that is, no inbound replication). |
Managing crossRef objects |
This can result in elevation of privilege. A user with this ability can create a private domain that he or she can specify as trusted and then modify the SID history of an account in the private domain to introduce security identifiers (SIDs) that represent the account as a domain administrator in the main domain, which gives that person elevated privileges. |
Restricting the Delegation of Sensitive Domain-Level Operations
To enhance security, we recommend that the operations in Table 43 only be performed by members of the domain-level service administrator groups (Domain Admins, Server Operators, or Backup Operators). They should not be delegated to anyone else.
Table 43 Domain-Level Operations That Should Not Be Delegated
Operation |
Reason Why the Operation Should Not Be Delegated |
---|---|
Installation and Removal of Active Directory |
The account that is delegated this authority has the ability to add and remove domains in the forest. It has the ability to add and remove domain controllers from the domain. This means it has control over adding and removing nodes of the distributed directory service and the associated security infrastructure. To do this, the account is given access to password and account information in those domains that can be used for offline password-cracking attacks. It also has the ability to delete entire domains, which is an extreme example of a denial-of-service attack. |
Software Installation on Domain Controllers |
To do this, the user must have local administrator access to the domain controller. With this type of access, the user can gain direct access to the directory database file, with the ability to copy it for an offline attack. The user also has the necessary permissions to install software updates and add services to the operating system. These may include rogue agents that filter passwords or debuggers to monitor the Local Security Authority (LSA) process for sensitive information. |
Managing Outbound Trusts |
Users who have the authority to create outbound trusts to external domains or to manipulate trusts with non-Windows Kerberos realms have the authority needed to establish trust with a dummy target forest of their creation in which they are administrators, such as domain administrator or enterprise administrator, of the root domain. In the dummy target forest, they can manipulate their group membership in the directory to introduce group SIDs that represent a privileged entity in the source forest. Creating an external trust (unless proper SID filtering has been enabled) can result in elevation of privileges in the source forest. |
Managing Replication |
Anyone with these rights has the ability to direct replication to an outside source, where data from the directory can be collected and then taken offline for a password-cracking attack. In a given domain, if the people who are delegated this right have full control over any computer object in the domain, they can inject arbitrary changes into the domain by creating a fake replication source. They also have the ability to launch denial-of-service attacks by removing replication links and preventing replication from taking place. |
Managing Domain-Level Operations Master Roles |
The domain controller with the relative ID (RID) operations master role controls the domain RID pool as well as the allocation of RIDs to the domain controllers. Improper seizure of this role can result in duplicate RIDs being allocated. As a result, new objects will be given invalid SIDs. |
Modifying Domain Controller Security Policies |
A user with this ability can control all access to the domain controller. Policy configuration is generally fairly static, and once it is initially set, this is an infrequent operation. There is no real need to delegate this operation. |
Modifying Domain Security Policies |
Domain security policies affect all domain users, member servers, and workstations that are members of the domain. The person with this ability can apply security policies to the entire domain. This can be used to spread a weak password policy, which in turn can lead to broken passwords. This is an infrequent operation, and there is no real need to delegate it. |
Backup and Restore Operations |
Users with these rights have the ability to overwrite files on the system and use tools that copy files off the system. This can lead to the installation of rogue agents or the removal of files for offline password cracking. |
Establishing Secure Data Administrative Practices
Data administrators manage data that is stored in the directory but that is not related to directory service configuration or the operation of Active Directory itself. Data administrators manage local resources, such as print and file shares on local servers, and they also manage the group and user accounts for their own part of the organization.
Delegation of data administration is accomplished by creating groups, granting the appropriate user rights to those groups, and applying Group Policy settings to the members of those groups. After these steps are complete, delegation is a matter of adding user accounts to the groups that are created. The critical part of this operation is granting proper access and applying the proper policies to maximize security, while still allowing your administrators to perform their delegated functions.
Delegating Data Management
Because the creation of data administrator accounts and of the specific functions that are delegated to them is driven by the needs of individual organizations, it is difficult to list specific recommendations for creating and managing individual accounts. However, this section provides a list of considerations to keep in mind while delegating control to your data administrator accounts.
Restricting Access Group Policy to Trusted Individuals
Group Policy should only be created and applied by completely trusted individuals. These individuals should be familiar with your organization's security policies, and they should have demonstrated their willingness to enforce those policies.
Users with accounts that have the ability to create or modify Group Policy settings can elevate the privileges of another user account through those policies. For example, if these users modify a GPO that has been applied to a group of administrative accounts, they may be able to configure a logon script that runs the next time one of the administrators logs on.
The logon script may contain a script that adds their user account to the Administrators group. Because the script is launched during the administrator's logon process, it runs in the security context of the administrator. In this case, it acts as if the administrator is adding a user to the group. After this process is complete, the user has administrative access.
Taking Ownership of a Data Object
If your data administrators will be given the ability to create objects, make sure that you understand the scope of that ability. When a user creates an object, he or she also becomes the owner of that object by virtue of being its creator, and this person is called the Creator Owner. In the discretionary access control model that is used by Windows 2000, the owner of an object has Full Control of that object, including the ability to change the ACL of that object.
By implication, the owner of an object also has Full Control on any child objects that may be added under that object. The owner has the ability to block ACL inheritance from parent objects and to block service administrators' access to that object.
If a situation arises in which access to an object has been blocked so that even the service administrators cannot access it, a member of the Administrators group must take ownership of the object to regain control. Members of the Administrators group always have the right to take ownership of an object, and as the owner they can modify the security descriptor of the object.
Reserving Ownership of Partition Root Objects for Service Administrators
Ensure that the Administrators or Domain Admins groups in each domain own the domain root object for that domain partition. Because the owners of these partition root objects have the ability to change the security settings of all other objects in that partition through inheritable ACEs, it is vitally important to ensure that the partition root object is owned by a highly trusted administrative group. By default, Active Directory partitions are set up so that the partition root objects are owned by the corresponding administrative groups. This means that the members of the Schema Admins group have ownership of the Schema directory partition and members of the Enterprise Admins group have ownership of the Configuration directory partition.
Preventing Concurrent Group Membership Changes
When planning your account management operations, institute operational practices ensuring that changes to group memberships within a delegated scope - for example, within an OU - are performed by a single data administrator within that OU or that they are tightly coordinated between a few data administrators for that OU. This means that you should try to limit the group administration to a single account - or as few accounts as possible - in each administrative entity (domain or OU).
Managing group membership changes this way is necessary because of the way that Windows 2000 replicates and handles conflicts in group membership information among domain controllers. When the membership of a group changes, the entire list of members (which is stored as a single attribute in the group object) replicates as a whole. If a conflict is detected between two concurrent changes to the group membership originating at two separate domain controllers, one change wins and the other loses, causing one change to be made to the entire group membership.
Losing group membership changes can be a problem if you have more than one administrator who is capable of making changes to the group membership. For example, consider a group of administrators (Admin1, Admin2, and Admin3) who can modify group membership:
Admin1 is terminated from the organization.
Admin2, in an effort to protect company resources, immediately removes Admin1 from the Administrators group.
At the same time, Admin3 modifies the membership of the Administrators group to add a new member.
Admin2 finishes removing Admin1 and closes the group.
The new membership list of the Administrators group then replicates to all domain controllers in the domain.
Admin3 finishes adding a new member and closes the Administrators group.
Replication will then start replicating the membership list to all domain controllers. The problem is that the membership list that contains the newly added member still lists Admin1 as a member. This membership list overwrites the changes made by Admin2, because the replication of this version of the membership list starts later than the update to remove Admin1. The result is that Admin1 is still a member of the Administrators group, with access to company resources.
Establishing Other Secure Practices for Delegating Administration
When manipulating ACLs on objects in the directory, you should be mindful of certain considerations so that you can avoid problems with unpredictable or confusing access control behavior.
Avoiding Use of the DNPROTECT Tool
Building Enterprise Active Directory Services - Notes from the Field (Microsoft Press) suggests a utility (DNProtect.exe) to secure objects in the directory. When this tool sets a bit on a directory object, the object can only be changed on a domain controller that is a member of the same domain as the object's owner.
Normally, when a user attempts to access an object, the user's access token is evaluated against the ACL on the object to determine if the requested access is allowed. If the bit has been set by DNProtect.exe, the operating system verifies that the user requesting access is a member of the same domain as the object's owner before evaluating the ACL on the object. If the user making the change is not a member of the same domain, access is denied.
While this tool may provide some security for directory partitions that are widely replicated in the forest across multiple domains, it also introduces an element of confusion into the security model in your environment. It is possible to end up in a situation in which a user is listed on an object's ACL as having access but access is denied when the user attempts to access the object. Use of the DNPROTECT tool is not supported in Windows 2000.
Avoiding the Use of Domain Local Groups for Controlling Read Access to Global Catalog Data
Do not use domain local groups to control Read permissions on object attributes that are replicated to the global catalog. Using domain local groups to control Read access to object attributes that replicate to the global catalog can result in unpredictable access control behavior for searches. Results can vary, depending on which global catalog services the search requests, as illustrated by the following example.
Suppose that a local group, called LocGrp1 and defined in domain Dom1, is granted Read access to an object that replicates to the global catalog. A user that is a member of LocGrp1 initiates a search for that object. When a user initiates a search for an object in the global catalog, DC Locator requests and obtains the address of a global catalog from DNS. The address of the global catalog that is returned can be one of many global catalog s in the forest, not necessarily a global catalog in domain Dom1. If the user binds to a global catalog in domain Dom1, Read access is granted to the user, because the user's authorization data (that is, list of groups of which the user is a member) that is evaluated on that global catalog includes the local group LocGrp1.
However, if the user binds to a global catalog in a different domain (Dom2), the user's authorization data that is evaluated on that global catalog does not include the group LocGrp1. Therefore, the user would not be granted access to the object. Because the user has no control over which global catalog is selected, the results of the search are unpredictable.
Recommendations: Establishing Secure Administrative Practices
The following checklists summarize the recommendations made in this chapter.
Recommendations for Establishing Secure Service Administrative Practices
The following table provides a checklist of recommendations for enhancing the security of your service administrator user and group accounts.
Check |
Limiting the Exposure of Service Administrator Accounts |
|
Limit the number of service administrator accounts. |
|
Use separate administrator and user accounts for administrative users. |
|
Hide the domain Administrator account. |
Check |
Managing Service Administrators in a Controlled Subtree |
|
Create a controlled subtree to manage service administrator accounts and administrative workstations. |
Check |
Protecting the Service Administrator Accounts |
|
Hide the membership of the service administrator groups. |
Check |
Managing Group Memberships for Service Administrator Accounts |
|
Assign trustworthy personnel. |
|
Do not include accounts from outside the forest as members of service administrator groups. |
|
Assign members in the Schema Admins group temporarily. |
|
Do not use the Backup Operators group for anything other than domain controller backup functions. |
|
Do not use the Account Operators group to delegate account management. |
Check |
Controlling the Administrative Logon Process |
|
Require smart cards for administrative logon. |
|
Use shared logons for sensitive administrative accounts. |
Check |
Securing Service Administrators Workstations |
|
Restrict service administrator's logon to administrative workstations. |
|
Prohibit cached credentials from unlocking administrative workstations. |
|
Avoid running applications in administrative contexts. |
|
Use antivirus software on administrative workstations. |
|
Secure LDAP traffic between administrative workstations and domain controllers. |
Check |
Avoiding the Delegation of Security-Sensitive Operations |
|
Do not delegate the forest-level operations described in Table 42. |
|
Do not delegate the domain-level operations described in Table 43. |
Recommendations for Establishing Secure Data Administrative Practices
The following table provides a checklist of recommendations for enhancing the security of your data administrative practices.
Check |
Delegating Data Management |
|
Only allow trusted individuals to access Group Policy. |
|
Understand the ramifications of Creator Owner. |
|
Ensure that service administrators own partition root objects. |
|
Prevent concurrent group membership changes. |
Check |
Establishing Other Secure Practices for Delegating Administration |
|
Avoid the use of the DNPROTECT tool. |
|
Avoid the use of domain local groups for controlling Read access to global catalog data. |
Chapter 6: Securing DNS
Active Directory uses Domain Name System (DNS) to locate servers that host various directory partitions. This facilitates replication and client access to the information that is stored in the directory partitions. Because DNS is an integral part of the architecture that is used to access Active Directory, it is important to implement DNS as securely as possible to help prevent unauthorized users from exploiting it as a means of gaining access to the directory. Whether their intent is malicious or innocent, any users who gain access to the DNS infrastructure with anything other than the Read permission can make changes that may result in the failure of the directory or in unauthorized access to information in the directory.
The process of protecting DNS begins during deployment. Awareness of the ways that DNS can be exploited can help drive decisions that are made during deployment. After deployment, the next step is properly delegating administrative responsibilities to implement those deployment decisions.
Note: This discussion assumes the use of Active Directory-integrated DNS zones. Microsoft recommends this practice, because integrating DNS zones into Active Directory simplifies the process of securing the DNS infrastructure.
When Active Directory-integrated zones are used, zone-specific data is stored in containers inside the directory, while configuration data is stored in the registry. Information that is related to DNS servers, such as server configuration settings like restricting NS record registration, is stored in the registry. Data that pertains to a single DNS zone that is hosted on the server is stored in the MicrosoftDNS container in the directory.
Deploying Secure DNS
In a distributed environment, such as Active Directory, multiple servers work together to make the directory available to all users on the network. Advantages of the distributed model include elimination of single points of failure, shared resources for more efficient operation, and an administrative model that can be customized to match existing organizations.
When a distributed model is used, an infrastructure must be provided so that the servers and clients can locate one another in the environment. In the case of Active Directory, this infrastructure is DNS. Because DNS is used to locate resources within the directory environment, it becomes a point of interest for unauthorized users attempting to access the system.
Unauthorized users can attempt to use DNS to gain access to the directory environment in a variety of ways. One type of attack involves adding invalid entries to DNS zones so that the DNS servers respond to client requests with misleading data. Another type of attack involves responding to DNS client requests, which are intended for a valid DNS server with invalid information, under the guise of the legitimate DNS server. These types of attacks can have the results described in Table 44.
Table 44 Results of Attacks Made Through DNS
Result |
Description |
---|---|
Clients are directed to unauthorized domain controllers. |
When a client sends a DNS query looking for the address of a domain controller, a compromised DNS server can be instructed to return the address of an unauthorized domain controller. Then, with the use of other non-DNS-related attacks, the client can pass on secure information to the unauthorized domain controller. |
DNS queries receive responses with invalid addresses. |
When a DNS query receives a response with invalid addresses, the result is that clients and servers are unable to locate one another. If clients cannot locate servers, they cannot access the directory. If domain controllers cannot locate other domain controllers, the directory stops functioning. |
You can increase protection for your DNS infrastructure at two levels. First, take steps to protect the DNS server and the integrity of its responses to client requests. Second, improve security for data that is stored on the server so that, if the server is compromised, this you can prevent unauthorized changes to the zone data.
Protecting DNS Servers
When a DNS server is attacked, the goal of the attacker is to assume control of the information that is returned in response to DNS client queries. This way, clients can be misdirected to unauthorized locations without their knowledge. After the clients start communicating with these unauthorized locations, attempts can be made to gain access to information that is stored on the client computers. Spoofing and cache pollution are examples of this type of attack.
Not all attacks are about gaining access to information. Denial-of-service attacks use DNS information to provide invalid addresses in response to client queries so that computers cannot locate one another. The recommendations in the following sections can help you protect your DNS servers from these attacks.
Implementing Internet Protocol Security Between DNS Clients and Servers
Internet Protocol security (IPSec) encrypts all traffic over a network connection. Encryption minimizes the risk that data that is sent between the DNS clients and the DNS servers can be scanned for sensitive information or tampered with by anyone attempting to collect information by monitoring traffic on the network. When IPSec is enabled, both ends of a connection are validated before communication begins. This way, a client can be certain that the DNS server with which it is communicating is a valid server. Also, all communication over the connection is encrypted; therefore, the client can assume that it has not been tampered with. This prevents spoofing attacks, which are false responses to DNS client queries by unauthorized sources that act like a DNS server.
IPSec is not enabled by default. Many organizations choose not to enable IPSec across their entire network, because it may have an impact on the performance of the network.
For more information about IPSec, see the "Internet Protocol Security (IPSec)" link on the Web Resources page at https://go.microsoft.com/fwlink/?LinkId=17304.
Protecting the DNS Cache on Domain Controllers
It is possible to add unauthorized entries directly into the cache on a DNS server so that clients can be misdirected to unauthorized locations. This is referred to as cache pollution. In Windows 2000, you can use the properties dialog box for a DNS server to enable the Secure cache against pollution option. This protects the cache from outside interference. By default, this option is not enabled.
Monitoring Network Activity
Denial-of-service attacks through DNS come in two forms. First, an attacker can cause the server to respond with invalid addresses so that clients and servers cannot locate resources that they need to function. (For more information, see "Protecting DNS Data" later in this guide). Second, an attacker can flood a DNS server with so many client requests that it cannot keep up with legitimate requests. Watch for unusually high amounts of traffic, and look for anomalies, such as high volume from a single location or high volume for a single type of traffic.
Closing All Unused Firewall Ports
Firewalls are a common way to protect servers from outside attack. Firewalls limit the available ports that can be used to communicate between points on your network. DNS servers use User Datagram Protocol (UDP) port 53 to communicate with one another. Open port 53 on firewalls when a firewall is located between the following:
DNS servers that perform zone transfers
DNS servers that delegate zones and the servers that are authoritative for the zones
DNS clients and their DNS servers
DNS forwarders and servers that are higher in the DNS namespace hierarchy
Protecting DNS Data
If an attacker can gain access to the DNS server itself, the attacker may attempt to alter data that is stored in the DNS zone files. The recommendations in the following sections can help keep your zone data secure from a direct attack.
Using Secure Dynamic Update
One type of DNS attack involves entering invalid data into the zone files. This is done for two reasons. First, the attacker can add records that contain invalid IP addresses that result in misdirection of clients for denial of service or in misdirection to unauthorized servers. Second, dummy records can be registered in an attempted denial-of-service attack. Possible goals of this type of attack are to:
Exhaust the server's disk space by generating a huge zone file, filled with dummy records.
Create a huge number of entries (more than 50,000) in the zone container in the directory to cause slow replication.
In a DNS environment that uses dynamic update, the DNS server processes any DNS registration request if the request applies to the zone for which the DNS server is authoritative. To prevent a rogue user from registering bad records, use secure dynamic update. Using secure dynamic update guarantees that registration requests are processed only if they are sent from valid clients in the forest. This makes it more difficult for a rogue user to launch this type of attack. The rogue user has to first gain access to a workstation that is a member of the forest.
Ensuring That Third-Party DNS Servers Support Secure Dynamic Update
If your environment uses a third-party DNS solution, and you want to continue to use it with Active Directory, make sure that you are using a version that is current enough that it supports secure dynamic update. If your DNS provider does not support this option, update to a current DNS version that does support secure dynamic update, if possible. As an alternative, you can disable any dynamic update functionality and manually add the necessary service (SRV) records to support Active Directory. Continuing to use dynamic update without using secure dynamic update leaves the integrity of your DNS data at risk.
Ensuring That Only Trusted Individuals Are Granted DNS Administrator Privileges
Members of the DNS Admins group have control over the configuration of the DNS environment. This means that they can disrupt the functionality of the directory service by using denial-of-service attacks or by misdirecting clients to rogue servers. This puts them in the same category as the service administrator accounts mentioned in "Establishing Secure Administrative Practices" earlier in this guide. Use the same care in determining who is granted membership in the DNS Admins group. Choose only individuals who are aware of your operational policies and who have demonstrated their willingness to enforce those policies. Also, grant access only to the portion of the DNS infrastructure for which each individual is responsible.
Setting ACLs on the DNS Data
Access control lists (ACLs) can be set on the zone containers to limit access by users who attempt to modify the zone containers with management tools, such as the DNS or ADSI Edit snap-ins. By default, Administrators, Domain Admins, Enterprise Admins, and DNS Admins have Full Control access to all components of DNS. Everyone else has Read access.
Using Forwarders Instead of Secondary Zones
If you plan on deploying secondary zones in your DNS infrastructure, consider using forwarders instead. Secondary zone data is not stored in the directory; it is stored in a text-based zone file, which makes the data more vulnerable to attack. It is possible to protect that data using NTFS permissions; however, eliminating the existence of the zone file altogether removes the need to protect the data. Using forwarders is another way to distribute the load on the DNS servers; however, forwarders do not require zones files to be stored on every server. They simply forward DNS requests to servers that have the zone data. Using forwarders reduces the surface area of your DNS deployment to potential threats.
The downside of using forwarders is an increase in traffic on your network and a reduction in the fault tolerance of your DNS infrastructure. Forwarders do not maintain their own copy of the database. When they receive a client query, forwarders first check their own DNS cache to see if the query has been processed before and if the result is in memory. If the result is not in memory, a query is sent to the forwarders' primary DNS server to be processed. Because forwarders must always forward new queries, rather than processing them in a local database, forwarders end up generating more traffic on the network. The reduction in fault tolerance occurs because the use of forwarders means that there are fewer copies of the database available in case a DNS server fails. When a primary or secondary DNS server fails, it means that there is one less DNS server available to process client requests. If you are using forwarders, and the primary DNS server used by the forwarders fails, the primary DNS server and all the forwarders become unavailable.
Using Separate Internal and External Namespaces
If your organization will have an Internet presence, you should create a namespace for use on the Internet and a different namespace for use on your intranet. DNS was designed to distribute information in response to queries from clients. It was not designed to provide secure access to the information it distributes. Because of this, DNS environments are vulnerable to attacks that cause information disclosure.
As security becomes a higher and higher priority for network operations, features have been added to DNS to make it a more secure environment. However, these features are geared more toward preventing the registration of invalid information than preventing information disclosure. A DNS server responds to any DNS client queries that are applicable to the zone for which the DNS server is authoritative. It does not perform any kind of security check to make sure that a valid user or client is making the query. If you use the same namespace for your Internet presence and your intranet, clients on the Internet can send queries to your DNS servers in an attempt to learn the names of resources on your intranet.
Most organizations have an internal DNS infrastructure for name resolution of internal resources and a separate external DNS infrastructure that gives them a presence on the Internet. This is referred to as a split namespace. This infers a set of DNS servers for the internal namespace and a separate set of servers for the external namespace. A split namespace ensures that users who query for the external name cannot access or get information about an internal resource.
For more information about configuring DNS, see Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks. To download these guides, see the Active Directory link on the Web Resources page at https://go.microsoft.com/fwlink/?LinkId=291.
Non-Active Directory-Integrated DNS Security
This guide focuses on using Active Directory-integrated zones, which is the recommended practice for DNS deployment. Although details about file-based DNS deployments (non-Active Directory-integrated deployments) are not presented here, setting NTFS file permissions on zone files is important enough to mention. DNS database files are stored in a plaintext format. Any user who can gain access to the disk drive where these files are stored can open these files with a text editor, such as Notepad, and make changes. You can use NTFS file permissions to prevent this type of access, although you should make sure that any changes do not prevent normal system access.
Recommendations: Securing DNS
The following tables summarize the recommended steps for increasing the security of a DNS environment that is used to support Active Directory.
Recommendations for Deploying Secure DNS
The following table provides a checklist of recommendations for making the DNS environment used by Active Directory more secure.
Check |
Protecting DNS Servers |
|
Use Active Directory-integrated DNS zones. |
|
Implement IPSec between DNS clients and servers. |
|
Protect the DNS cache on domain controllers. |
|
Monitor network activity. |
|
Close all unused firewall ports. |
Check |
Protecting DNS Data |
|
Use secure dynamic update. |
|
Ensure that third-party DNS servers support secure dynamic update. |
|
Ensure that only trusted individuals are granted DNS administrator privileges. |
|
Set ACLs on DNS data. |
|
Use forwarders instead of secondary zones. |
|
Use separate internal and external namespaces. |
Recommendations for Non-Active Directory-Integrated DNS Security
The following table provides a checklist of recommendations for making your DNS environment more secure when you are not using Active Directory-integrated zones.
Check |
Enhancing Non-Active Directory-Integrated DNS Security |
---|---|
|
Set NTFS file permissions on zone files. |
Appendix: Procedures
This appendix contains the procedures needed to perform the security updates that are recommended in this guide. In some instances, a link to another document is provided, rather than a procedure.
Allowing Logon Access to Administrator Workstations
Limit the locations where the service administrator accounts can log on by allowing logon locally to Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators only on administrative workstations. Administrative workstations are the computer objects in the Administrative Workstations organizational unit (OU).
Requirements
Credentials: Domain Admins
Tools: Active Directory Users and Computers
To allow logon access to the Administrative Workstations OU
Log on with Domain Admins credentials, and then open Active Directory Users and Computers.
In the console tree, right-click Administrative Workstations, and then click Properties.
On the Group Policy tab, click New.
Type Service Administrator Policies, and then click Edit.
Expand the policy tree to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights.
In the details pane, double-click Logon locally.
Select Define these policy settings, and then click Add.
Add Everyone to the list, and then click OK.
In the details pane, double-click Deny logon locally.
Click Define these policy settings.
Remove any users from the list, and then click OK.
Changing the Security Descriptor on AdminSDHolder
The security descriptor on AdminSDHolder serves two purposes. First, it controls access to the AdminSDHolder object itself. Second, it acts as the master security descriptor that is periodically applied to the service administrator accounts and their members to ensure that they remain protected.
Requirements
Credentials: Domain Admins
Tools: Active Directory Users and Computers
To change the security descriptor on AdminSDHolder
Log on with Domain Admins credentials, and then open Active Directory Users and Computers.
On the View menu, click Advanced Features.
In the console tree, click the System node.
In the details pane, right-click AdminSDHolder, and then click Properties.
On the Security tab, modify the security descriptor by changing the settings as specified in Table 39.
Creating a Decoy Administrator Account
This procedure adds an additional layer of protection when hiding the default Administrator account. An attacker planning a password attack on the Administrator account can be fooled into attacking an account with no special privileges.
Requirements
Credentials: Domain Admins
Tools: Active Directory Users and Computers
To create a decoy Administrator account
Log on with Domain Admins credentials, and then open Active Directory Users and Computers.
In the console tree, right-click the Users node, click New, and then click User.
Create a New User with the following information:
In First name and User logon name, type Administrator.
Type and confirm a password.
Your new account will appear in the Users container.
In the details pane, right-click Administrator, and then click Properties.
On the General tab, in the Description box, type Built-in account for administering the computer/domain.
Creating a .reg File
To create a scripting solution that changes a registry setting on a computer, you can use the registry editor to add or modify a registry setting and then export the setting to a .reg file. You can use the .reg file in scripts to apply the setting to other computers.
Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at .
Requirements
Credentials: Administrators
Tools: Regedit.exe
To export a registry setting to a .reg file
Click Start, click Run, type regedit, and then click OK.
In the console tree, navigate to the registry entry that you want to export to the file.
Add or modify the registry entry that you want to export to the .reg file.
With the registry entry selected, on the Registry menu, click Export Registry File.
In the Save in box, navigate to the location for the .reg file.
In the File name box, type a name for the .reg file (Registration Files type).
Under Export range, click Selected branch, and then click Save.
Creating a Reserve File
This procedure reserves disk space by creating a file on the same disk volume as the Active Directory database. The reserve file size should be 250 megabytes (MB) or 1 percent of the size of the logical disk volume where the Active Directory database is stored, whichever is larger.
Requirements
Credentials: Domain Admins
Tools: Fsutil.exe
To create a reserve file on your domain controller
Log on to a client computer running Windows XP Professional.
Connect to the remote administrative share for the disk volume where the Active Directory database is stored, for example, C$ or D$.
Create the reserve file on the same disk volume as the Active Directory database by using the following command from any Windows XP Professional client:
fsutil file createnew reserve_file_name reserve_file_size
Ensure that the reserve file name you specify resides on the same disk volume as the Active Directory database files. The reserve file size should be 250 MB or 1 percent of the size of the logical disk volume where the Active Directory database is stored, whichever is larger.
- Grant Administrators Full Control on the reserve file.
Denying Logon Access to the Domain
Limit the locations where the service administrator accounts can log on by denying logon locally to Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators at the domain level. This will prohibit administrators from logging on to any computers in the domain. Be sure also to implement the procedure "Allowing Logon Access to Administrator Workstations" to restore logon capability to administrators when they are logging on to administrator workstations.
Requirements
Credentials: Domain Admins
Tools: Active Directory Users and Computers
Caution: Do not use this procedure without also following the procedure in "Allowing Logon Access to Administrator Workstations." Failure to do so may result in your service administrators being unable to log on to any workstations or member servers in the domain.
To deny logon access at the domain-level to service administrators
Log on with Domain Admins credentials, and then open Active Directory Users and Computers.
Expand the console tree, right-click domain_name, and then click Properties.
On the Group Policy tab, click Default Domain Policy, and then click Edit.
Expand the policy tree to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights.
In the details pane, double-click Deny logon locally.
Select Define these policy settings, and then click Add.
Add all service administrator accounts (Administrators, Schema Admins, Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators) to the list.
Enabling Auditing on Active Directory Database Objects
This procedure configures auditing on actions that are performed against Active Directory objects. The actions to be audited are specified in Table 19 through Table 30.
Requirements
Credentials: Domain Admins
Tools: ADSI Edit administrative tool console (in Windows 2000 Service Pack 3 (SP3) Support Tools)
To enable auditing on Active Directory database objects
Log on to a domain controller in the root domain using an account with Domain Admins credentials, and then open ADSI Edit.
To open ADSI Edit, run mmc, click File, click Add/Remove Snap-ins, select ADSI Edit, and then click Add
In the console tree, right-click ADSI Edit, and then click Connect to.
In the Connection dialog box, in Naming Context, select naming_context (where naming_context is the directory partition of interest), and then click OK.
Expand the console tree, right-click container_object (where container_object is the domain or domain controller OU where auditing will be enabled), and then click Properties.
On the Security tab of the Properties dialog box, click Advanced.
On the Auditing tab of the Access Control Settings dialog box, click Add.
Create auditing settings to match the settings in Table 19 through Table 30.
Enabling Monitoring for Anonymous Access
Enabling monitoring for anonymous access is set through SACLs on the Active Directory object CN=Server, CN=System, domain, DC=.... The SACLs ensure that a security audit log event is generated whenever an application or service attempts to list or read domain data in Active Directory with anonymous access. The most common instances are applications such as Routing and Remote Access Service (RRAS) running on Windows NT 4.0 domain controllers or on member servers in the context of Local System.
Note: In addition to setting these SACLs, the Audit directory service access audit policy must be configured to audit successful access to the directory. For more information about enabling the Audit directory service access audit policy, see "Establishing Domain Controller Audit Policy Settings earlier in this guide.
Requirements
Credentials: Domain Admins
Tools: ADSI Edit (in Windows 2000 Server SP3 Support Tools)
To enable monitoring for anonymous access
Log on to a domain controller in the root domain using an account with Domain Admins credentials, and then open ADSI Edit.
To access ADSI Edit, run mmc, click File, click Add/Remove Snap-ins, select ADSI Edit, and then click Add.
In the console tree, right-click ADSI Edit, and then click Connect to.
In the Connection dialog box, in Naming Context, select DomainNC, and then click OK.
In the console tree, browse to the domain_name/System node, and then click System.
In the details pane, right-click Server, and then click Properties.
On the Security tab, click Advanced.
On the Auditing tab, set the SACLs, based on the information in Table 45.
Table 45 SACL Settings for CN=Server,CN=System,DC=Domain,DC=...ForestRootDomain
Type
Name
Access
Apply To
Success
Anonymous Logon
Read property
This object only
Success
Anonymous Logon
Enumerate Entire SAM Domain
This object only
Enabling SID Filtering
SID filtering is applied to an external trust between a trusting domain and a trusted domain to "quarantine" the trusted domain. This feature removes any security identifiers (SIDs) from the trusted domain's authorization data that do not reference the trusted domain.
Requirements
Credentials: Domain Admins for the trusting domain
Tools: Netdom.exe (in Windows 2000 Server SP3 Support Tools)
Note: This procedure assumes that an external trust already exists between the trusting and trusted domains.
To enable SID filtering
Log on to a domain controller in the trusting domain using an account with Domain Admins credentials.
At a command line, type:
netdom trust trustingDomainName /domain:trustedDomainName /filtersids:yes /userd:username [/passwordd:userpassword]
If you do not specify a password in the command, you will be prompted for one.
Linking a New Policy to the Domain Controller OU-Level GPOs
This procedure accomplishes two things. First, the new Group Policy is added to the list of Group Policy objects (GPOs) that are applied at the Domain Controllers OU level. Second, the new GPO is moved to the top of the list of GPOs to ensure that its policy settings are not overridden by other GPOs.
Requirements
Credentials: Domain Admins
Tools: Active Directory Users and Computers
Important: Policy setting changes to user rights or auditing must be made on the default GPO rather than added to the list of GPOs.
To link a domain controller Group Policy object to the default GPO
Log on with Domain Admins credentials, and then open Active Directory Users and Computers.
In the console tree, right-click Domain Controllers, and then click Properties.
On the Group Policy tab, click Add.
On the All tab in the Add a Group Policy Object Link dialog box, select the new GPO, and then click OK.
Move the new GPO to the top of the list of domain controller GPOs to ensure that its settings take precedence.
Restart the computer, or run Secedit/refreshpolicy machine_policy to update the Domain Controllers OU Group Policy settings.
Monitoring for Anonymous Access
In a previous procedure, you enabled security monitoring for anonymous access by setting SACLs. These SACLs are set on the objects that are accessed anonymously by applications and services on other domain controllers, member servers, or workstations in the domain.
Note: To complete this procedure you need software that is capable of aggregating the Security event logs on all domain controllers into a single log. In addition, you need software that can query the Security event log based on the criteria in this procedure.
To make the analysis of the aggregated Security event logs easier, export the aggregated Security event logs to a database, such as Microsoft® Access. Collect the event logs for about 30 days to ensure that all applications have attempted anonymous access, paying special attention to applications and services running on Windows NT 4.0 in the security context of Local System.
Requirements
Credentials: Domain Admins
Tools: unspecified database product
To monitor for anonymous access
Collect Security event logs for 30 days on all domain controllers.
Aggregate the event logs from each domain controller into a database.
Identify the anonymous access events in the aggregated event logs by querying the Security event log for any events with the Event ID 565 (directory service access events) and the text "anonymous" (case insensitive) in the event.
Identify the logon IDs that generated the anonymous access (for the events that meet the criteria in the previous step).
The output of this query gives you the list of the logon IDs that generated the anonymous access.
Identify the logon and logoff events that are associated with the logon IDs identified in the previous step by querying the results of the events in the previous step for event IDs 528 (logon events) or 540 (logoff events).
Identify the domain controllers, member servers, or workstations where the logon and logoff events, identified in the previous step, originated.
Identify the applications or services running on the domain controllers, member servers, or workstations where the anonymous access originated.
Examples of the applications or services that require anonymous access include Routing and Remote Access Service running on Windows NT 4.0, SQL Server running on Windows NT 4.0 (with Integrated or Mixed SQL logon), and print servers running Windows NT 4.0.
Renaming the Default Administrator Account
This procedure eliminates any information that can alert attackers that this account has elevated privileges. Although an attacker still needs the password to the account, hiding the default Administrator account adds an additional layer of protection against password attacks seeking elevation of privilege.
Requirements
Credentials: Domain Admins
Tools: Active Directory Users and Computers
To rename the default Administrator account
Log on with Domain Admins credentials, and then open Active Directory Users and Computers.
In the console tree, click Users.
By default, the Administrator account is in the Users container. However, if you have already created a Service Admin subtree, it may have been moved to the Users and Groups OU in the new subtree.
In the details pane, right-click Administrator, and then click Properties.
On the General tab, change Description to resemble other user accounts.
Eliminate anything indicating that this is the Administrator account. In First name and Last name, type a fake name.
On the Account tab in the User logon name dialog box, type a new name.
Again, type a name that cannot be identified as the Administrator account.
Note: This only changes the default Administrator account's logon name and the account details that someone can see if they manage to enumerate a list of accounts on your system. This does not affect the Administrator account that is used to boot into Directory Service Restore Mode.
Securing Scripts with Script Signing
Two alternatives exist for creating signed scripts. For anyone who is interested in developing their own script host, the Windows Product Software Development Kit (SDK) contains a set of tools for signing scripts (Signcode.exe and Chktrust.exe). When writing your own script host, call Win32 API WinVerifyTrust. This API verifies the trust on a .vbs or .js file.
Alternatively, Windows Script Host (WSH) 5.6 ships with a signer object to create and verify signed scripts. The following JScript® code creates a signed file:
var Signer = new ActiveXObject("Scripting.Signer"); var File = "c:\\myfile.vbs"; var Cert = "Jane Q. Programmer"; var Store = "my"; Signer.SignFile(File, Cert, Store);
The following sample, in this case as Microsoft® Visual Basic®, Scripting Edition (VBScript) code, verifies the signing on a file:
Dim Signer, File, ShowUI, FileOK Set Signer = CreateObject("Scripting.Signer") File = "c:\newfile.wsf" ShowUI = True FileOK = Signer.VerifyFile(File, ShowUI) If FileOK Then WScript.Echo File & " is trusted." Else WScript.Echo File & " is NOT trusted." End If
Updating the Default Group Policy on the Domain and the Domain Controllers OU
This procedure modifies either the default domain-level Group Policy or the default Domain Controllers OU-level Group Policy.
Requirements
Credentials: Domain Admins
Tools: Active Directory Users and Computers
Important: Policy setting changes to user rights or auditing must be made on the default GPO rather than added to the list of GPOs.
Table 46 Policy Settings Applied to the Default GPO
Where Policy Is Applied
Policy
Recommended Policy Settings
Domain root
Password
See Table 14
Account Lockout
See Table 15
Kerberos
See Table 16
Domain Controllers OU
User Rights Assignment
See Table 17
Audit
See Table 18
To link a domain controller GPO to the default GPO
Log on with Domain Admins credentials, and then open Active Directory Users and Computers.
In the console tree, right-click the container where the policy will be applied, as specified in Table 46, and then click Properties.
On the Group Policy tab, select the default GPO, and then click Edit.
In the policy tree, click the appropriate policy, as specified in Table 46.
In the details pane, double-click the policy setting of interest.
In the policy setting dialog box, type the recommended value.
Restart the computer, or run Secedit/refreshpolicy machine_policy to update the Domain Controllers OU Group Policy settings.