Securing Windows 2000 Server

The previous chapter provides you with a solid understanding of how to develop and deploy a secure baseline using Group Policy for the Microsoft® Windows® 2000 servers in the Contoso, Ltd. scenario. When a secure baseline across these servers is established, you need to consider how to secure each server according to the role that it plays in the infrastructure of your organization.

This chapter contains the recommended security settings to achieve a secure environment for the following four major server roles that are present in most organizations running Windows 2000 servers:

Each server in your environment hosts a set of application services that dictate a complementary set of security settings that must be applied to ensure maximum availability and reliability of those services. These sets of security settings that you apply ensure that the data accessible from those servers is protected.

As detailed in the Member Server Baseline Policy (MSBP) discussed in Chapter 6, "Hardening the Base Windows 2000 Server," Group Policy is used to apply as many security enhancements to the Windows 2000 servers in your environment as possible.

For each server role, the policy settings are stored in individual security templates that are imported into a corresponding Group Policy object (GPO). A GPO represents a collection of policy settings used to define security settings in a Windows 2000–based environment.

For example, to secure the IIS servers in this scenario, the policy settings described are stored in the MSS IIS Role.inf security template. This template is imported into the GPO for the IIS Group Policy that is linked to the Web organizational unit (OU) in the child domain for Contoso.

The location of the GPOs within the Active Directory for Contoso is highlighted in the following figure:

Figure 7.1  OU security template GPO design by server role for Contoso
See full-sized image

The settings contained within the security template for each server role in Figure 7.1 are defined in this chapter. However, some security hardening procedures cannot be automated through Group Policy. In these cases, specific procedures recommended for each one are described in the later sections of this chapter.

The MSS Baseline.inf security template, which is detailed in Chapter 6, "Hardening the Base Windows 2000 Server," is also used as the basis for the security template called MSS DCBaseline Role.inf. The differences between the MSS Baseline.inf and MSS DCBaseline Role.inf security templates are explained in the "Domain Controllers Group Policy" section of this chapter.

On This Page

	Active Directory Domain Controller Role
	Infrastructure Server Role
	File and Print Server Role
	IIS Server Role
	Summary

Active Directory Domain Controller Role

The domain controller server role is one of the most important roles to defend in a Windows 2000 Active Directory enterprise environment. The loss or compromise of the domain controllers would be devastating to clients, servers, and applications that consume such things as domain authentication, Group Policy, and the central lightweight directory access protocol (LDAP) directory.

Because of their importance, domain controllers should be stored in physically secure facilities, which are accessible only to qualified administrative staff. When domain controllers must be stored in unsecure locations, branch offices for example, certain security settings can be adjusted to limit the potential damage from physical threats. Where applicable, the recommended settings for domain controllers stored in unsecure locations are noted within this chapter.

Domain Controller Baseline Policy

Unlike the other server role policies detailed in this chapter, the Group Policy for the Domain Controllers role is a baseline policy, putting it in the same class as the Member Server Baseline Policy (MSBP) defined in Chapter 6, "Hardening the Base Windows 2000 Server." Therefore, the Domain Controller Group Policy requires no other security policies to be applied other than the Default Domain Policy inherited from the domain container and the Default Domain Controllers Policy configured in the Domain Controllers OU.

Because the Domain Controller Baseline Policy is based on the MSBP, you should have read Chapter 6 to understand many of the settings that are also in the Domain Controller Baseline Policy. Most of the Domain Controller Baseline Policy is a direct copy of the MSBP. Any settings in the Domain Controller Baseline Policy that differ from the MSBP are documented in this section.

Note   Protection of the Directory Service (the contents of Active Directory including the objects, classes, and attributes) is addressed in Chapter 5, "Securing the Domain Infrastructure."

Audit Policy Settings

The Audit Policy settings for the Domain Controller Baseline Policy are the same as those specified in the MSBP. The baseline policy settings ensure that all the relevant security audit information is logged on the domain controllers, including Directory Services Access.

Event Log Settings

The Event Log settings for the Domain Controller Baseline Policy are the same as those specified in the MSBP.

User Rights Assignment

The Default Domain Controllers Policy specifies a number of User Rights Assignments for the domain controllers. In addition to the default settings, there are two user rights for which you should increase the security for the domain controllers:

The recommended settings for these rights are identified in the following table.

Table 7.1  Domain Controller Baseline Policy User Rights Settings

Log on Locally

Vulnerability

Any account with the right to log on locally could be used to log on at the console of a domain controller. When someone uses Terminal Services over the network, the account also requires the Log on locally user right. If a user attempts to log on to the server using Terminal Services, that person must use an account that also has Guest Access or User Access permissions for the Terminal Services Remote Desktop Protocol (RDP).

It is a best practice to not allow unauthorized users to log on locally. In the case of the domain controllers, this best practice typically applies to the Account Operators and Printer Operators groups. Providing this privilege gives unauthorized users the ability to download, view, and potentially install new code, which can then be used to exploit any escalation of privilege vulnerability that requires local logon access.

Countermeasure

Remove the following two default groups: Account Operators and Print Operators. Neither of these default groups should require the ability to log on to the domain controllers in your environment. Perform this action through the Domain Controller Baseline Policy.

Alternatively, you can add these groups to the Deny Logon Locally privilege in the Domain Controller Baseline Policy. This privilege setting is configured in the Domain Controller Baseline Policy template.

Potential Impact

Removing these default groups could limit the delegated abilities of assigned user roles in your environment. Confirm that delegated activities will not be adversely affected.

Contoso Scenario

Only Administrators, Backup Operators and Server Operators have the Log on locally privilege on Contoso's domain controllers. Backup Operators require this privilege to support backup software, which requires service accounts. Server Operators require this privilege to be able to shut down the domain controllers, because it is also necessary to log on to the domain controller to be able to shut it down.

This setting was configured to remove these default groups in the Domain Controller Baseline Policy template.

Shut Down the System

Vulnerability

The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be very careful about the accounts and groups that you allow to shut down a domain controller. For detailed information, see Chapter 6 under the setting "Allow system to be shut down without having to log on."

Shutting down the domain controllers would make them no longer available to perform such functions as processing logons, serving Group Policy, and answering LDAP queries. The impact of shutting down domain controllers that possess Flexible Single-Master Operations (FSMO) roles is that these servers can disable key domain functionality, such as processing logons for new passwords (the PDC Emulator role).

Countermeasure

Remove the following three default groups from any Domain Controller Group Policy that assigns the Shut down the system privilege: Account Operators, Backup Operators, and Print Operators. These default groups should not require the ability to shut down domain controllers.

Alternatively, if you want to delegate the ability to shut down domain controllers to other groups, you can do so. However, remember that you would typically not want to shut down your central authentication databases, because then users cannot be authenticated by the domain.

Potential Impact

The impact of removing these default groups could include limiting the delegated abilities of assigned roles in your environment. Confirm that delegated activities will not be adversely affected.

Contoso Scenario

Only Administrators and Server Operators have the Shut down the system privilege on Contoso domain controllers. Backup Operators do not require this privilege to support backup software. Server Operators require this privilege because they are often delegated the ability to shut down the domain controllers without being assigned Administrators membership.

This setting to remove these default groups was configured in the Domain Controller Baseline Policy template.

Security Options

The following table outlines the security option settings that are different from those in the MSBP, or that require special considerations in the context of a domain controller. None of these settings required any changes to default client configuration to support connectivity with the domain controllers.

Table 7.2  Domain Controller Baseline Policy Security Option Settings

Some of the security options documented in Table 7.2 merit additional explanation. The rest of this section details the considerations behind these settings as implemented in the domain controllers for the Contoso scenario.

Additional Restrictions for Anonymous Connections

Domain controllers are especially sensitive to the need of some clients for anonymous access. For this reason, the domain controllers must allow anonymous connections to support the following types of functionality:

Allow Server Operators to Schedule Tasks (Domain Controllers Only)

Vulnerability

Legitimate users who belong to the Server Operators group could schedule tasks in the Domain Controllers group. Because the Scheduler Service runs by default as System, an attacker with Server Operators membership could exploit this privilege. For example, an attacker could schedule a task that adds their account to the Domain Administrators group.

Countermeasure

Configure Allow server operators to schedule tasks (domain controllers only) to the value Disabled.

Potential Impact

Only users with domain administrator privileges will be able to schedule tasks through the Scheduler Service on the domain controllers.

Contoso Scenario

In the Contoso scenario, only administrators need the ability to schedule tasks on the domain controllers. Group Policy was used to configure Allow server operators to schedule tasks (domain controllers only) to Disabled.

LAN Manager Authentication Level

For the Windows 2000 domain controller, it is especially important that all clients are able to authenticate to a domain controller to join the domain in the first place, as well as to continue to participate in the domain. It is also very important that domain controllers authenticate to domain controllers in other domains (inter-forest or Windows NT 4.0 domains) to validate credentials outside the forest. Both of these operations require some form of local area network (LAN) Manager (that is, non-Kerberos version 5 authentication protocol) authentication.

All Windows clients (including Windows 2000 and Microsoft Windows XP) are configured by default to send LAN Manager (LM) and NTLM authentication responses (except Windows 9x clients that only send LM). They do not send NTLMv2 authentication responses by default. Therefore, enforcing NTLMv2 authentication on a Windows 2000 domain controller is not possible until all clients (and domain controllers outside the forest that participates in trust relationships) are reconfigured to send NTLMv2 responses.

Number of Previous Logons to Cache

Vulnerability

Although it is typical to allow cached logons on Windows domain clients, it is fundamentally unnecessary to cache domain logons on a domain controller—because it is impossible for the domain controller not to validate its own domain credentials.

Countermeasure

Configure the Number of previous logons to cache (in case domain controller is not available) setting to the value 0 for domain controllers.

Potential Impact

By disabling cached logons on the domain controllers, it would be impossible to authenticate previously authenticated accounts from other domains on a domain controller, if the other domain's domain controllers were all inaccessible. For example, in the Contoso child domain, it is possible that if all Contoso root domain controllers were inaccessible, accounts such as Enterprise Admins could not log on to the child domain controllers.

The impact of such a position is not permanent and is resolved as soon as access to the inaccessible domain controllers is restored.

Contoso Scenario

Group Policy was used to configure the Number of previous logons to cache (in case domain controller is not available) setting in the Domain Controller Baseline Policy to the value 0.

Secure Channel: Digitally Encrypt or Sign Secure Channel Data (Always)

Digital encryption and signing of the “secure channel” is worth investigating where it is supported. However, digital encryption and signing of the secure channel is only supported in Windows NT 4.0 SP6a or later and is not supported in Windows 9x clients. Therefore, this setting cannot be enabled on domain controllers when they have to support Windows 9x clients as members of the domain.

This setting will only enforce signing or encryption if one of the other "when possible" settings related to it has been applied to the domain controller. If neither of these settings has been applied, then this setting has no effect on the domain controller. However, when either of these other settings is enabled on the domain controller, you cannot enable this setting until the following conditions are met.

Potential impacts from this setting include disabling the ability to create or delete downstream trust relationships, disabling logons from downstream clients, and not being able to authenticate other domain users from a downstream trusted domain.

This setting should only be enabled on your domain controllers when all the following conditions are true:

System Services

The following table summarizes the prescribed system services that must be enabled on all Windows 2000 domain controllers. The system services are configured in the SCI DCBaseline Role.inf policy template, which is then imported into the Domain Controller Policy GPO.

Table 7.3  Mandatory Domain Controller Services in Baseline Policy

There are additional services that are commonly enabled on Windows 2000 domain controllers, but they are not essential in every organization. The settings recommended for these services fit the Contoso scenario, but they are frequently the subject of debate and may not be applicable in your environment.

Table 7.4  Additional Domain Controller Services Considerations

Note   If you run the DCDiag.exe utility from the Windows 2000 Support Tools, it will check for all services that could run on the domain controllers in your environment. Because some services are disabled in the Domain Controller Baseline Policy—including IISADMIN, SMTPSVC, and TrkSvr—DCDiag.exe will report errors. These errors are to be expected and do not indicate a problem with your configuration.

DNS Server

Vulnerability

The DNS Server service is required to support Active Directory-integrated DNS services. The DNS Server is used to support the dynamic DNS update protocol in Windows 2000 Server.

Any running service or application is a potential point of attack—services and components that are not running cannot effectively be attacked. Therefore, to create more secure computers, a best practice is to turn off unused features to reduce the "surface area" available for attack.

Countermeasure

None. This service is required.

Alternatively, if Active Directory-integrated DNS is not required, this service may be disabled on the domain controllers and enabled in the Infrastructure server role. The Infrastructure server role could then run the DNS Server service as a primary or secondary DNS server.

Potential Impact

Disabling Active Directory-integrated DNS Services where required will make all domain operations fail, including those for replication, logon, and Group Policy. It will also cause failures in Active Directory-integrated applications such as Microsoft® Exchange 2000.

Contoso Scenario

The Contoso environment requires Active Directory-integrated DNS, so the DNS Server service Startup Type was configured to the value Automatic.

Intersite Messaging

Vulnerability

This service is required by the Active Directory Knowledge Consistency Checker (KCC). This service is also used to support SMTP–based Active Directory replication between sites. Each transport used for replication is defined in a separate add-in dynamic link library (DLL). The add-in DLLs are loaded into Intersite Messaging.

Intersite Messaging directs send and receive requests to the appropriate transport add-in DLLs, which then route the messages to Intersite Messaging on the destination computer. If you use SMTP for replication in your environment, you need to enable this service.

Any running service or application is a potential point of attack, and, conversely, services and components that are not running cannot effectively be attacked. Therefore, to create more secure computers, it is a best practice to turn off unused features to reduce the surface area available for attack.

Countermeasure

The option for the Intersite Messaging service should be configured to Automatic in the Domain Controller Baseline Policy.

Alternatively, if you want to generate manual replication topologies and thus do not need to support the KCC, you may want to disable this service.

Potential Impact

None.

Contoso Scenario

Because the Contoso environment depends on the KCC to calculate replication topologies, the Intersite Messaging service is required, and, therefore, this service was enabled in the Domain Controller Baseline Policy.

IIS Admin Service

Vulnerability

If the SMTP service is enabled, then the IIS Admin Service also needs to be enabled because the former is dependent on the IIS Admin Service.

As stated previously, any running service or application is a potential point of attack, and, therefore, to create more secure computers in your environment, it is a best practice to turn off unused features and options.

Countermeasure

Configure the option for IIS Admin Service in the Domain Controller Baseline Policy to Disable.

Alternatively, if SMTP–based replication is required, then this service should be configured to Automatic startup in the Domain Controller Baseline Policy.

Potential Impact

Because this service is required for the SMTP service to successfully run, disabling the IIS Admin Service also disables SMTP–based replication of Active Directory information. If SMTP–based replication is required to traverse slow links and high-latency links, then this setting will prevent such Active Directory replication. For this reason, you should configure this service to Automatic.

Contoso Scenario

Because the Contoso environment is composed of high-speed links between Active Directory sites, SMTP–based replication is not required, and, therefore, this service was disabled.

NTLM Security Support Provider

Vulnerability

The NTLM Security Support Provider supports the NTLM Security Support Provider Interface (SSPI) for RPC applications that call down to the SSPI for RPC message security. This service is considered essential for Windows 2000 servers to operate.

The NTLM SSPI provides the potential for RPC applications to authenticate to the domain controller using the weaker LM or NTLM authentication protocols rather than the NTLMv2 authentication protocol.

Countermeasure

None. This service, which is enabled by default, may be required for application compatibility.

This service may be disabled in some circumstances, but it is considered an essential service for supporting some older applications running under Windows 2000. If you want to disable this service, it is strongly recommended that you first test all applications running on or accessing your domain controllers to ensure that the absence of the NTLM SSPI does not cause those applications to fail.

Eliminating LM and NTLM authentication (in favor of the stronger NTLMv2 and Kerberos authentication protocols) in your environment will require some research, planning, and testing. You should first investigate the following Microsoft Knowledge Base articles:

Potential Impact

Enabling this service allows the relatively weak LM and NTLM protocols to authenticate to the domain controllers in your organization, which can be mitigated by using NTLMv2 on clients of the domain controllers.

Contoso Scenario

The NTLM Security Support Provider service is needed to support many scenarios in the Contoso environment. For this reason, this service was enabled in the Domain Controller Baseline Policy.

Simple Mail Transport Protocol (SMTP)

Vulnerability

The SMTP service on a domain controller allows other domain controllers to replicate Active Directory updates between sites by means of the SMTP protocol, as opposed to the default RPC protocol. It is useful when attempting replication across very slow or high-latency network links between sites containing domain controllers and is necessary when an organization does not allow RPC to cross internal network boundaries such as firewalls.

Intersite replication can occur using either RPC or SMTP. If you use SMTP for intersite replication in your environment, you must enable the SMTP service.

SMTP presents two potential vulnerabilities:

Countermeasure

If SMTP–based Active Directory replication is not needed for your environment, the option for the SMTP service should be configured to Disabled in the Domain Controller Group Policy.

Alternatively, if you do not want to disable the SMTP service, you may want to investigate securing the SMTP service itself with either Access Connection filters—the SMTP Server Properties, Access tab, and Connection button—or Internet Protocol Security (IPsec) filters that block connections on TCP port 25 for all but specified Internet Protocol (IP) addresses. IPsec is a developing standard for security at the network or packet processing layer of network communication. It is useful for implementing virtual private networks (VPNs) and for authenticating or encrypting IP data between individual IP hosts.

You should also consider enabling the SMTP service only on replication partners that replicate between domains that require SMTP–based Active Directory replication.

Note   If you want to enable SMTP replication, you will need to configure digital certificates on each domain controller that will participate in the SMTP replication partnership. See Appendix D, "Configuring Digital Certificates on Domain Controllers," for more details.

Potential Impact

The potential impact of disabling SMTP on domain controllers is minimal, unless you have configured SMTP–based Active Directory replication to be handled by those domain controllers—in which case the replication would fail.

Contoso Scenario

All Active Directory replication in the Contoso environment was configured to occur by means of the IP (otherwise known as RPC) transport. For this reason, the SMTP service was disabled.

File Access Control Lists

Vulnerability

File permission ACLs for all newly-created volumes other than the %SystemDrive% (usually the C partition) default to Everyone: Full Control. Therefore, any files or folders added to such volumes will generally inherit Everyone: Full Control permissions.

Any file shares created on such volumes will expose the shared files to these file permissions by default. These files would then be exposed to Information Disclosure and Tampering with Data threats as defined in the STRIDE (Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) model. See Chapter 2, "Defining the Security Landscape" in the "Categorizing Threats" section for a more detailed description of these threats.

The only file permission ACLs changes that are enabled in the Domain Controller Baseline Policy are on the %SystemDrive%.

You should update the file permissions on any additional nonremovable volumes that are created along with the %SystemDrive% (for example, the D, E, and F partitions), especially the partition that contains the Active Directory database, the DNS log files, and any other sensitive data files.

Countermeasure

Configure the default permissions for all nonsystem disk partitions by enabling Full Control inheritable permissions for Administrators, Creator/Owner, and SYSTEM. Do not assign permissions to any other groups or users. Assigning such permissions to Creator/Owner allows the system to assign ownership to individual administrators rather than just to the Administrators group.

Alternatively, you may want to select different permissions for the root of each volume. However, at a minimum you should ensure that the permissions on the folders for DNS logs and for the Active Directory database and log files are locked down to allow Full Control only for Administrators and SYSTEM.

Potential Impact

Any applications already installed in these nonsystem partitions might fail to operate properly if the existing permissions are overwritten. Some Windows applications are configured to set their own explicit permissions in the directories in which they are installed. For this reason, these applications should always be tested in a lab environment with the permission setting changes applied to them as recommended here.

Contoso Scenario

The %SystemDrive% (typically the C partition) root permissions were configured in the Domain Controller Baseline Policy to allow Full Control only for Administrators, Creator/Owner, and SYSTEM and to inherit and propagate those permissions to child folders and files. For other disk partitions, those permissions were configured manually.

To change root folder permissions on nonsystem disk partitions (for example the E partition) manually

Additional Security Settings—Directory Services

Disabling the NoLmHash Setting on Domain Controllers

Vulnerability

The NoLmHash setting mitigates the vulnerability of the storage of LM hashes in the accounts database and prevents the use of LM Challenge/Response authentication.

However, whereas the NoLmHash setting was enabled in the MSBP, it is not possible in the Contoso scenario to enable this setting on the domain controllers because Contoso needs to support the Windows 98 clients in the scenario that are not capable of NTLM or NTLMv2 authentication. Because the Contoso Windows 98 clients can only authenticate with the LM authentication protocol, the domain controllers must preserve the ability to authenticate using LM, as well. Unfortunately, this ability requires a stored version of the LM Hash on the domain controllers, which precludes the use of the NoLmHash setting on any Contoso domain controllers.

Countermeasure

Ensure that the NoLmHash registry key does not exist on your domain controllers.

Potential Impact

The impact of not disabling the LM Hash creation is to continue to store an LM hash value representing users' passwords in Active Directory. However, the risk of attackers gaining access to these weaker hashes is generally lower on domain controllers than on servers and workstation because physical access is usually harder to obtain for domain controllers. See the Use of Syskey topic later in this chapter for more information on mitigating physical access attacks.

Not disabling the creation of the LM Hash also allows the LM Challenge-Response authentication to occur over the network, which is the weakest of the Windows challenge-response authentication methods. This method is required for support of Windows 98 SE clients, but is not necessary after all Windows 9x clients have been removed from the domain environment.

Contoso Scenario

The manual change to disable the creation of the LM hash was not performed on the domain controllers. The NoLmHash key was not added to the HKLM\SYSTEM\CurrentControlSet\Lsa registry key in the domain controllers' registry.

Data Relocation—Active Directory Database and Log Files

Vulnerability

The database and log files (ntds.dit, edb.log, and temp.edb) are always exclusively locked when the directory service is online; that is, these files cannot be directly read or written. However, it is theoretically possible that they could be subverted if an attacker somehow gained access to the files through the (lsass.exe) process that locks these files.

It is a best practice to move the Active Directory database and log files to a nonsystem disk volume to improve domain controller performance, preferably to a striped or striped/mirrored volume. General security best practices also recommend that sensitive files such as these should be moved off the system volume to minimize the risk of directory traversal attacks on these files.

Countermeasure

Ensure that during installation of the Active Directory domain controller, you select store the Database and Log directories on a nonsystem volume (usually not on the C: volume). The best choice would be a high-performance disk volume such as a striped or striped/mirrored array.

Alternatively, for pre-existing domain controllers—assuming that you have not already moved these files off the system partition—you could move the Active Directory database and log files by doing the following:

Potential Impact

Placing the database and logs on a nonsystem volume during installation has minimal or no impact, as long as a volume with sufficient size and performance is chosen.

Moving the database and logs on an existing domain controller can have significant impact, because the computer will have to be taken offline during the operation. Also, there is always the small risk that the hardware could fail during the move procedure.

Always create a backup of the System State before proceeding with such an operation. For complete instructions on the following procedure, see the Microsoft Knowledge Base article 257420, "How To Move the Ntds.dit File or Log Files," at http://support.microsoft.com/default.aspx?scid=257420.

Contoso Scenario

In the Contoso environment, the database and logs were installed on a nonsystem volume during the installation process.

To change the location of the Active Directory database and logs during installation of a domain controller

To move the database and logs on an existing domain controller

Note   A domain controller that has been successfully promoted has the following permissions assigned by default to the Ntds folder structure: Administrators and SYSTEM = Full Control. No additional lockdown of these files is recommended.

Secure the Pre–Windows 2000 Compatible Access Group

Vulnerability

The default permissions on most objects in Active Directory assign read access to the Pre–Windows 2000 Compatible Access group. All User and Group objects have this permission, and the domain partition assigns the List Contents permission to this group.

When the Everyone special group is made a member of the Pre–Windows 2000 Compatible group in an Active Directory domain, all User and Group objects become allowed for LDAP read operations by anonymous users, including each user object's group memberships. These anonymous users can also list the contents of the domain.

Countermeasure

Remove the Everyone alias from the Pre–Windows 2000 Compatible Access group for an existing domain.

Alternatively, for new domains, choose the permissions compatible only with Windows 2000 servers setting in the Permissions dialog box during the DCPROMO process for the first domain controller.

Theoretically, you could remove the inherited permissions for the Pre–Windows 2000 Compatible Access group from the domain container. However, removing blanket permissions creates a greater risk because this alternative has not been fully tested by Microsoft. Also, this approach limits your flexibility to make the most of this permission in the future.

It should also be pointed out that changing those permissions on Active Directory objects does not strengthen security in your environment any more than emptying the Pre–Windows 2000 Compatible Access group in the first place to ensure that this group remains empty unless an attacker or worm added another account to this group.

Potential Impact

Any applications that require anonymous access to Active Directory will lose their ability to work as expected. Services and applications known to suffer when the Everyone group is removed from the Pre–Windows 2000 Compatible Access group include:

Contoso Scenario

In the Contoso scenario, the Everyone alias was removed from the Pre–Windows 2000 Compatible Access group for each domain using the following procedure.

To remove the Everyone alias from the Pre–Windows 2000 Compatible Access group

net localgroup "Pre-Windows 2000 Compatible 
Access" Everyone /DELETE

C:\>net localgroup "pre-windows
2000 compatible access"
Alias name     pre-windows 2000 compatible access
Comment        A backward compatibility group 
        which allows read access on all 
        users and groups in the domain
Members
-------------------------------------------
-------------------
The command completed successfully.

Remove the Add Workstations to Domain Right

Vulnerability

By default, all authenticated users have the ability to add up to 10 computer accounts to a Windows 2000 domain. These new computer accounts are created in the Computers container.

As opposed to the Windows NT 4.0 domain model, in a Windows 2000 domain each computer account is a full security principal, with the ability as the computer to authenticate and access domain resources. Some organizations want to limit the number of computers in the Active Directory environment so that they can be consistently built and managed.

Giving users the ability to add workstations to the domain can hamper this effort. It also provides avenues for users to perform activities that would be more difficult to trace by allowing them to create additional unauthorized domain computers.

Finally, if an existing computer shuts down gracefully, it will unregister its Service Principal Name (SPN) from Active Directory. During the time that the computer is down—for example, after a Denial of Service (DoS) attack—an attacker could register their own computer to that SPN and then intercept all traffic destined for the legitimate server.

Countermeasure

Remove the Authenticated Users group from the Add workstations to domain user right in the Default Domain Controllers Policy.

Alternatively, if you want to allow a different, more restricted group of users to create computer accounts, you can change the value of Add workstations to domain user right in the Default Domain Controllers Policy. For example, you could create a new domain group called Computer Account creators, populate the new group with the accounts of users who should have the Add workstations to domain right, and then add the new group name to this domain right in the Default Domain Controllers Policy.

You also can assign the Create Computer Accounts and Delete Computer Accounts permissions on any OU (or the domain container) in the Active Directory domain to specific groups of users. Users with these permissions are able to create any number of computer accounts in that container (for example, a branch office OU) to which they have these permissions.

For example, a security group called Server Management Staff could be assigned the Create Computer Accounts and Delete Computer Accounts permissions on the Member Servers OU. Any member of the Server Management Staff group would then have the ability to create any number of computers accounts in the Member Servers OU. For more information about creating computer accounts in OUs, see the Microsoft Knowledge Base article 251335, "Domain Users Cannot Join Workstation or Server to a Domain," at http://support.microsoft.com/default.aspx?scid=251335.

Finally, if you still want to allow all Authenticated Users to create computer accounts by means of the Add workstations to domain privilege, but fewer than the default setting for ten accounts, you can change the value of the ms–DS–MachineAccountQuota attribute from the default value of 10 to another decimal value greater than 0. Setting this value to 0 disables this privilege. For more information, see Microsoft Knowledge Base article 251335 (referenced in the previous paragraph).

Potential Impact

Users who previously had the ability to add their own workstations to the domain will no longer be able to perform that action. This lack of capability could have an impact on their ability to perform their jobs, especially if they frequently create computer accounts.

This step can increase the overhead for the environment by forcing the organization to provision computer accounts ahead of time for new computers. It also can increase the need to coordinate computer rollouts with a central information technology (IT) release management team, which will have to create the computer accounts on demand.

Creating computer accounts ahead of time for new computers also creates a new vulnerability. The longer new computer accounts go unclaimed, the more likely someone may "steal" one by adding an unauthorized computer to the domain, and registering it under the name of an unclaimed account. Such a scenario is possible because Windows 2000 uses a predictable default computer account password. The default password for each unused account registered in Active Directory remains the same until a new computer claims one by joining the domain.

The computer account "theft" would typically be reported when the legitimate user is unable to join their new computer to the domain. However, the attacker may use the domain computer during this interim period.

Contoso Scenario

In the Contoso scenario, all additions to the network are performed by IT staff that has Create/Delete permissions in the relevant OUs. No users are allowed to add workstations to the domain, so the privilege was revoked for all users.

The Authenticated Users group was removed from the Add Workstations to Domain right in the MSS DCBaseline Role.inf template using the following procedure.

To modify the groups that have the Add workstations to domain privilege

Protect Against Denial of Service Attacks on Kerberos/TCP

Vulnerability

There are limited conditions under which Windows 2000 domain controllers will temporarily stop accepting the Kerberos protocol requests through TCP, which is a known issue that can be resolved with a post-SP3 hotfix. A hotfix is a cumulative package composed of one or more files used to address a defect in a product. Hotfixes address specific customer situations and may not be distributed outside the customer organization without written legal consent from Microsoft.

This vulnerability is detailed more fully in Microsoft Knowledge Base article 320903, "Clients Cannot Log On by Using Kerberos over TCP" at http://support.microsoft.com/default.aspx?scid=320903.

It is extremely unlikely that even highly utilized domain controllers will experience this issue during legitimate use. However, it is possible that an attacker may exploit this DoS condition and temporarily exhaust the ability of a domain controller to service Kerberos through TCP requests.

By default and by design, the Kerberos authentication protocol traffic is sent and received on User Datagram Protocol (UDP) port 88. If the Kerberos protocol packets exceed 2,000 bytes (the default size limit) then Windows 2000 will switch to using TCP port 88.

Some organizations will choose to configure their Windows 2000 and Windows XP clients to always use TCP for the Kerberos protocol traffic. Microsoft Knowledge Base article 244474, "How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000," at http://support.microsoft.com/default.aspx?scid=244474 explains the most common situation that warrants making this change.

Countermeasure

If your environment is such that you believe this vulnerability to be a credible threat, or if you are experiencing the conditions detailed in Microsoft Knowledge Base article 320903, obtain the hotfix prescribed in this Knowledge Base article from Microsoft and deploy it to all affected domain controllers.

Alternatively, you could monitor the calls to your help desk for indications of unusually slow logon times, which might mean that you are experiencing this issue. However, slower than usual logon times can be the result of many other issues. Determining what is causing slow logon times is notoriously difficult.

You also can limit the use of the workaround detailed in Knowledge Base article 244474 to minimize the volume of Kerberos traffic through TCP. However, 244474 describes a problem of failed logons, which are often due to dropped packet fragments. Problems related to this issue are much harder to resolve without switching over to TCP. If you have deliberately chosen to make that switch, it is unlikely you will be able to switch back to the UDP.

Also, many organizations are choosing to increase the reliability of their Kerberos protocol authentication, because this authentication protocol method is becoming key to their enterprise applications, and switching to TCP is a key means of increasing this reliability. For these reasons, limiting the use of TCP to minimize the DoS potential is not recommended.

Potential Impact

The potential impact is the same as for any hotfix. As always, you should be sure to test before rolling out the hotfix to your production environment.

Contoso Scenario

In the Contoso scenario, there is a high degree of sensitivity to logon times and the potential of internal network attacks. For this reason, the hotfix for Microsoft Knowledge Base article 320903 was deployed as a proactive measure.

To obtain and deploy the hotfix for 320903

Additional Security Settings—Active Directory Integrated DNS

Microsoft recommends using Active Directory-integrated DNS, in part because integrating the zones into Active Directory simplifies the process of securing the DNS infrastructure.

Protect DNS Servers

Vulnerability

When a DNS server is attacked, one possible goal of the attacker is to control the DNS information being returned in response to DNS client queries. This way, clients could be misdirected to unauthorized computers without their knowledge. IP spoofing and cache poisoning are examples of this type of attack.

In IP spoofing, a transmission is given the IP address of an authorized user to obtain access to a computer or network. Cache poisoning occurs when by default any names added from referral answers are cached to help expedite resolving subsequent DNS queries.

After clients start inadvertently communicating with unauthorized computers, those computers may attempt to gain access to information stored on the client computers.

Not all attacks focus on spoofing DNS servers. Some DoS attacks could alter DNS records in legitimate DNS servers to provide invalid addresses in response to client queries. By causing the server to respond with invalid addresses, clients and servers cannot locate the resources they need to function, such as domain controllers, Web servers or file shares. This issue is discussed in the "Secure the DNS Data Container" section later in this chapter.

Countermeasure

Because all DNS client configurations are based on IP addresses, configure all routers to drop spoofed IP packets to ensure that the IP addresses of the DNS servers are not being spoofed by other computers.

Alternatively, you could limit the damage to your DNS servers from such attacks by monitoring DNS server performance.

Potential Impact

None.

Contoso Scenario

Because the Contoso DNS servers (domain controllers) in the Northamerica domain have a relatively high Asset Priority, all routers in the Contoso environment were configured to prevent IP address spoofing.

Not all Contoso clients are capable of using IPsec, so IPsec encryption or signing was not enabled on the DNS servers. However, IPsec blocking filters were enabled for different reasons—for more information, see the "Blocking Ports with IPsec Filters" section later in this chapter.

Domain controller and DNS server performance was monitored using Microsoft Operations Manager (MOM).

Configure Secure Dynamic Updates

Vulnerability

The Windows 2000 DNS server and client supports DDNS updates, which allow client computers to add DNS records directly into the database on supporting DNS servers.

Unauthorized DDNS updates can be made to a Windows 2000 DNS server if:

At a minimum, an attacker could add bogus entries to the DNS database; at worst, the attacker could overwrite or delete legitimate entries in the DNS database. The result of this kind of attack could include:

Countermeasure

You should use secure dynamic updates to prevent an attacker from registering bad records. Using secure DDNS updates guarantees that registration requests are only processed if they are sent from valid clients in the forest, which makes it more difficult for an attacker to launch this type of attack. An attacker must then gain access to a workstation that is a member of the forest first.

Alternatively, you could disable DDNS updates to prevent the described types of exploits. However, this configuration would significantly increase the cost of maintaining up-to-date DNS records because all updates would then have to be manually processed. In a Windows 2000 environment, the number of DNS records that have to be maintained is probably much higher than DNS administrators would be accustomed to in pre–Windows 2000 environments.

For more details on this issue, see the following Microsoft Knowledge Base articles:

Potential Impact

Some non–Windows 2000 computers may not be able to record DDNS entries in the Active Directory-integrated DNS zones after the zones are secured. This issue can be mitigated for DHCP clients by enabling Windows 2000 DHCP servers to register DNS records on behalf of DHCP clients.

However, the use of DHCP servers to register DDNS records will be of no help for non–DHCP clients. For computers that do not support secure DDNS updates or acquire their IP address information from a Windows 2000 DHCP server, but must have their DNS information registered in the secure Active Directory-integrated DNS zones, you will have to register these records manually.

Contoso Scenario

The Active Directory-integrated DNS servers in the Contoso scenario were manually configured to accept only secure DDNS updates.

To enable secure DDNS updates for each DNS zone (Forward Lookup Zone and Reverse Lookup Zone)

Note   This procedure assumes that on the General tab of the zone of interest, the Type is configured as Active Directory-integrated.

Secure the DNS Data Container

Vulnerability

Permissions ACLs can be configured on the zone containers to limit access by users who might attempt to modify them with management tools such as the DNS snap-in or ADSIEdit. Administrators, Domain Administrators, Enterprise Administrators, and DNS Administrators have Full Control permission by default to all DNS components; everyone else is assigned Read access.

If the default ACLs are changed, you may encounter a nonmalicious threat from users who could unintentionally be assigned the permission to modify the DNS Data containers. This situation could allow modifications of the DNS server properties or any of the data being stored in the integrated DNS zones. Nonmalicious threats typically result from employees who are untrained in computers and unaware of security threats and vulnerabilities.

Countermeasure

Limit the ACLs on the Microsoft DNS container in any domain that uses Active Directory-integrated DNS to the default ACLs.

Alternatively, you could limit the membership of groups that, by default, have the ability to modify these settings and data (that is, Administrators, Domain Administrators, Enterprise Administrators, and DNS Administrators).

Potential Impact

Incorrect permission settings on the Microsoft DNS container or any of the integrated DNS zones could have very serious consequences for your organization. Permissions that are too loose could allow unauthorized users to harm your DNS servers or their zone data. Conversely, permissions that are too tight could theoretically create a DoS condition when trying to load DNS data from the directory, or when adding new dynamic updates.

Note   In all cases, ensure that SYSTEM has Full Control.

Contoso Scenario

The default permissions on the Microsoft DNS and subordinate zones in the Contoso scenario were confirmed.

To view or edit the permissions for Active Directory-integrated DNS

Configure Protection Against DNS Cache Poisoning

Vulnerability

It is possible to add unauthorized entries directly into the cache on a DNS server so that clients may be misdirected to unauthorized locations, which would be an instance of cache pollution.

Countermeasure

Configure the Secure cache against pollution option on all DNS servers to the value Enable. With this feature enabled, the server can determine whether referred names are potentially polluting or unsecured, and then discard them.

The server determines whether to cache each referral based on whether each one can be identified as part of the exact related DNS domain name tree recorded in the original query. For more information, see Microsoft Knowledge Base article 316786, "Description of the DNS Server Secure Cache Against Pollution setting," at http://support.microsoft.com/default.aspx?scid=316786.

Potential Impact

Minimal.

Contoso Scenario

The Active Directory-integrated DNS servers were secured against cache pollution in the Contoso scenario.

To enable security against DNS server cache pollution

Secure DNS Data and Log Directories

Vulnerability

Windows 2000 DNS servers that are configured for Active Directory-integrated DNS store their zone data in Active Directory. However, DNS servers configured as Primary or Secondary servers will store their zone data in a text file in %SystemRoot%\system32\dns by default.

In addition, if debug logs are configured on the DNS server, these logs are by default also stored in a text file %SystemRoot%\system32\dns.

The default permissions on both of these files allow Read and Execute access for Users and Modify access for Power Users.

This DNS server data could be compromised if the server is exposed to buffer overflow or directory traversal attacks, which can enable access to data within the system volume. A buffer overflow is a type of exploit employed by attackers to gain access to a computer.

Countermeasure

Reduce the permissions on the %SystemRoot%\system32\dns folder so that only Administrators and SYSTEM have permissions to these files.

Alternatively, you could move the data and log files to a separate disk volume or to another directory that is less well-known to attackers than the default location. Moving the files does not necessarily improve the permissions on those files however, which means they are still potentially vulnerable to attack by those who could find them (for example, by finding their location specified in the registry).

Potential Impact

Because only the Administrators and System require access to these files, the potential impact is minimal. You might delegate management of DNS services to a new group that does not have membership in the Administrators group on the DNS server. In this case, you must ensure that the new group also has permissions to access these files to fulfill their duties.

Contoso Scenario

In the Contoso scenario, all DNS data is derived from Active Directory so no file system permissions changes were necessary.

To limit the permissions on the default DNS files directory

cacls.exe %systemroot%\system32\dns 
/t /g administrators:F system:F

Note   Remember to change the directory that you specify in the cacls.exe command if you happen to move the DNS files to a new but unsecured directory.

Move DNS Data and Log Directories

Vulnerability

Windows 2000 DNS servers that are configured for Active Directory-integrated DNS store their zone data in Active Directory. However, DNS servers configured as Primary servers will store their zone data by default in a text file in %SystemRoot%\system32\dns.

In addition, if debug logs are configured on the DNS server, those logs are by default also stored in a text file in %SystemRoot%\system32\dns.

This data could be read or compromised if the server is exposed to buffer overflow or directory traversal attacks, which can enable access to data within the system volume.

Countermeasure

Move the DNS zone data files and log files to a nonsystem disk partition.

Alternatively, you could reduce the permissions level in the default directory for DNS files located in the %SystemRoot%\system32\dns folder. However, this approach does not always limit the attack potential against these files, because some attacks can occur through compromised services that run as Administrator-level accounts or as SYSTEM.

Potential Impact

If you do not notify your Storage Management team of the new location for these files, they may inadvertently get missed during scheduled backups. You can avoid a potential availability issue by ensuring that your backup software is configured to back up these files in their new location.

Contoso Scenario

In the Contoso scenario, the DNS zone data is integrated with Active Directory and thus no data files were stored on disk. No changes were necessary.

In the Contoso scenario, debug logging for the DNS servers is not enabled. However, the debug log location was preconfigured to be stored on a separate disk in anticipation of potential future use of this logging functionality.

To move the DNS zone data files

To move the DNS debug log files

Limit Zone Transfers to Authorized Systems

Vulnerability

In addition to Active Directory-integrated DNS servers, there also are DNS servers that act as primary or secondary servers. Secondary servers typically transfer the entire zone file from the primary server to synchronize its contents.

A DNS server that is not configured to limit who can request zone transfers will allow the entire DNS zone to be transferred to anyone who requests it. This transfer can be easily accomplished using tools such as nslookup.exe, and would expose the entire domain's DNS dataset, including such things as which hosts are serving as domain controllers, directory-integrated Web servers, or SQL Server 2000 databases.

Countermeasure

Configure the DNS servers to allow zone transfers only to known computers (that is, only to secondary DNS servers).

Alternatively, you may want to not allow zone transfers. However, this configuration may be difficult to justify in a large, distributed network if you have or plan to set up a hierarchy of DNS servers and configure secondary DNS servers closer to large, remote populations of computing users.

Potential Impact

This configuration could limit services that require the ability to request the entire DNS zone at once. It could also slow down the response times for DNS clients that might have to query alternative DNS servers. It could also cause some DNS queries to fail, depending on your DNS infrastructure.

Contoso Scenario

In the Contoso Scenario there are secondary DNS zones configured on the child domain's domain controllers, which cache the root domain's _msdcs.corp.contoso.com zone. The root domain’s domain controllers were configured to only allow zone transfers for this zone to the child domain's domain controllers, according to the IP addresses of the authorized DNS servers. All other Active Directory-integrated zones were left with default configurations that do not allow zone transfers.

To limit zone transfers to known servers

Blocking Ports with IPsec Filters

Vulnerability

Reducing the number of ports that are open and actively listening on the servers in your organization will greatly reduce the attack surface of each computer. The attack surface is the exposed area of the client/server computers in your environment that is vulnerable to attack.

Open ports can provide an attacker with a launching pad to attack another server in the organization—for example, a worm and Trojan horse may install applications that bind to unauthorized ports on the server, and listen for incoming commands.

Countermeasure

Configure IPsec blocking filters that allow only the network traffic specified in the following table. This countermeasure will reduce the number of unexpected and unauthorized applications that could successfully receive requests or that could be attacked.

Domain controllers require RPC traffic for several functions including client logon as shown in the traffic map. Therefore, a range of RPC ports will need to be opened as shown in the following table.

Each service is divided into client and server functionality, but does not necessarily refer to a client workstation and the server. Instead, it shows the corresponding IPsec filter that would need to be created to either use or provide the noted service.

For example, the DNS client policy should be applied on any computer that requires name services functionality. The DNS server rules would only be applied on a computer that provides DNS services. Other services, such as Simple Network Management Protocol (SNMP) may be a bit confusing, because ports for SNMP server are permitted, but not ports for the SNMP client. However, because of the nature of SNMP in which a remote station contacts individual computers for information, SNMP acts as a server service on the domain controller to provide this information to the remote station.

Before implementing IPsec filters, you must have a full understanding of the capabilities and limitations of this technology. IPsec filters are very powerful, but can greatly impact the manageability and usability of computers. For more information, see Chapter 11, "Additional Countermeasures" of the Threats and Countermeasures guide at http://go.microsoft.com/fwlink/?LinkId=15159.

Domain Controller IPsec Network Traffic Map

Table 7.5  Domain Controller IPsec Network Traffic Map

Note   It is important to note that the Kerberos filter is necessary if you have implemented the NoDefaultExempt setting that is specified in Microsoft Knowledge Base article 254728, "IPSec Does Not Secure Kerberos Traffic Between Domain Controllers" at http://support.microsoft.com/default.aspx?scid=254728.

All of the rules that are listed in the preceding table should be mirrored when they are implemented. This configuration ensures that any traffic coming in to the domain controller will also be allowed to return to the originating server.

As shown in the preceding table, there are a number of ports and services that have been opened on the domain controller. Configuring the tightest security on the domain controller would allow you to block additional ports. However, additional ports were opened because of the downstream client requirements for NetBIOS, as well as to provide additional usability for the administration of the computers.

To support the client logon process, a range of ports should be designated specifically for the use of RPC. When limiting RPC traffic in your environment to a certain number of ports, the port range chosen should include ports over 50,000. You can designate a range of ports by setting the following registry settings:

After making these changes to the Registry, the server should be restarted.

These changes could affect performance and should be tested prior to implementing in production. The exact number of ports that will be opened will depend on the use and functionality of the server.

Finally, note that Contoso has implemented a MOM server in their environment. Because of the large interaction between the MOM server and the OnePoint client—the client application that reports to the MOM console—all network traffic is allowed between the server and the MOM server.

Scripting Commands

IPSecPol is limited in the fact that it can only add ports one at a time. Because RPC will require a range of ports to be opened, the easiest way to address this limitation is through the use of a script to automatically generate a batch file with all commands necessary based on the number of ports that will be opened.

The following sample code will generate a file called C:\ipsec.bat that contains a separate listing for each port to be added into the IPsec policy. The PORT_START variable defines the first port in the RPC range and PORT_END, defines the end of the range. POLICY_NAME is the name of the IPsec Policy to which the port filters will be added. The IP_ADDR value should be modified to reflect the IP address of the server on which the policy will be implemented.

PORT_START = 57901
PORT_END = 57950
POLICY_NAME = "Packet Filter"
RULE_NAME = "RPC Ports"
BATCH_FILE = "c:\ipsec.bat"
Dim fso
Dim tf
Const ForWriting = 2
Set fso = CreateObject("Scripting.FileSystemObject")
Set tf = fso.OpenTextFile(BATCH_FILE, ForWriting, True)
tf.Write "ipsecpol -w REG -p " & chr(34) & POLICY_NAME & chr(34)
& " -r " & chr(34) & RULE_NAME & chr(34)
For i = PORT_START TO PORT_END
tf.Write " -f *+0:" & i & ":TCP"
Next
tf.WriteLine " -n PASS"
tf.Close

Similar code could be used to generate a batch file to run and establish the IPsec policies with little manual effort. The batch file will address the areas in the preceding tables marked "RPC Range." The remainder of the ports will need to be addressed with similar methods as discussed for the other server roles.

After a range of ports is decided upon and the IPSecPol statements to implement the filters are created, the combination of these and the remaining commands should be executed on the server.

This set of commands is also included in a batch file that accompanies this guide.

ipsecpol -w REG -p "Packet Filter" -r "Domain Member" 
-f 0+192.168.100.10:: -f 0+192.168.100.11:: -f 0+192.168.100.12:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server" 
-f *+0:445:TCP -f *+0:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server" 
-f *+0:135:TCP -f *+0:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server" 
-f *+0:137:TCP -f *+0:137:UDP -f *+0:139:TCP -f *+0:138:UDP -n     PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring" -f 
    0+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f 
    *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Server" 
    -f *+0:3268:TCP -f *+0:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DNS Server" 
-f *+0:53:TCP -f *+0:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Server" 
-f *+0:88:TCP -f *+0:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Server" 
-f *+0:389:TCP -f *+0:389:UDP -f *+0:636:TCP -f *+0:636:UDP -n 
PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Server" 
-f *+0:123:TCP -f *+0:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports" 
-f *+0:57901:TCP -f *+0:57902:TCP -f *+0:57903:TCP -f 
*+0:57904:TCP 
-f *+0:57905:TCP -f *+0:57906:TCP -f *+0:57907:TCP -f 
    *+0:57908:TCP 
-f *+0:57909:TCP -f *+0:57910:TCP -f *+0:57911:TCP -f 
*+0:57912:TCP 
-f *+0:57913:TCP -f *+0:57914:TCP -f *+0:57915:TCP -f 
*+0:57916:TCP 
-f *+0:57917:TCP -f *+0:57918:TCP -f *+0:57919:TCP -f 
*+0:57920:TCP 
-f *+0:57921:TCP -f *+0:57922:TCP -f *+0:57923:TCP -f 
*+0:57924:TCP 
-f *+0:57925:TCP -f *+0:57926:TCP -f *+0:57927:TCP -f 
*+0:57928:TCP 
-f *+0:57929:TCP -f *+0:57930:TCP -f *+0:57931:TCP -f 
*+0:57932:TCP 
-f *+0:57933:TCP -f *+0:57934:TCP -f *+0:57935:TCP -f 
*+0:57936:TCP 
-f *+0:57937:TCP -f *+0:57938:TCP -f *+0:57939:TCP -f 
*+0:57940:TCP 
-f *+0:57941:TCP -f *+0:57942:TCP -f *+0:57943:TCP -f 
*+0:57944:TCP 
-f *+0:57945:TCP -f *+0:57946:TCP -f *+0:57947:TCP -f 
*+0:57948:TCP 
-f *+0:57949:TCP -f *+0:57950:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f 
*+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f 
*+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x

Potential Impact

Because these settings still allow RPC traffic, this server will perform much as it would without the settings. The major benefit of these settings is that the RPC traffic is limited to a particular range. However, this limitation could cause performance problems based on the number of users connecting to the computer and the number of RPC connections that need to be established. A large amount of testing should be performed before implementing these filters in your environment. These filters could be tightened to restrict this functionality, but administration of the server may become difficult.

The implementation of this relatively small number of IPsec policies should not have a noticeable impact on the performance of the server. However, a large amount of testing should be performed before implementing these filters in your environment to verify the necessary functionality and performance. Additional rules also may need to be added to support other applications in your environment.

Contoso Scenario

In the Contoso scenario, the specified IPsec filters were implemented in the company's domain controllers. The listed IP address was substituted in the scripts and command lines as appropriate for each domain controller.

Discussion of Active Directory Security Issues

Use of Syskey

Syskey is enabled on all Windows 2000 servers in mode 1 (obfuscated key). There are many recommendations that recommend Syskey in mode 3 (floppy storage of Syskey password) or mode 2 (console password) for any domain controller that is exposed to physical security threats. You can also create a repair disk for your domain controller, and store that floppy disk in a secure location to provide an additional backup of the mode 2 Syskey password.

For example, Syskey mode 2 or mode 3 is often recommended for domain controllers in branch offices that do not offer strong physical storage security for the domain controller computer. From a security standpoint, this configuration at first appears sensible because the domain controller would be vulnerable to being restarted by an attacker with physical access to the domain controller, which in mode 1 would allow the attacker to read and alter the contents of the directory.

However, the operational requirements for ensuring that the domain controllers can be made available through restarts tend to make Syskey modes 2 or 3 difficult to support. To take advantage of the added protection provided by Syskey, you should be prepared to implement additional operational processes in your environment to meet the availability requirements for your domain controllers.

First, the logistics of Syskey password or floppy disk management can be quite complex, especially in branch offices. For example, requiring one of your branch managers or local administrative staff to come to the office at 3 A.M. to enter the passwords, or insert a floppy to enable other users to use the system is expensive and makes it very challenging to achieve high availability service line agreements (SLAs).

Alternatively, allowing your centralized IT operations personnel to provide the Syskey password remotely requires additional hardware—some hardware vendors make add-on hardware solutions available to remotely access the console of the server, which would be required.

Secondly, the loss of the Syskey password or floppy disk leaves your domain controller in a state where it cannot be restarted. There is no method for you to recover a domain controller if the Syskey password or floppy disk is lost. If loss of the Syskey password or floppy disk occurs, the domain controller must be rebuilt.

Top of page

Infrastructure Server Role

The Infrastructure Server role in the Contoso scenario is either a DHCP or WINS server.

One difference between the Infrastructure Server definition in this guide and the Infrastructure Server role presented in the Microsoft Systems Architecture Enterprise Data Center (MSA EDC) guide is that the role here does not include DNS. The reason the Contoso scenario does not include DNS in the Infrastructure Server role is because all DNS server functionality is configured as Active Directory-integrated DNS and is hosted on domain controllers.

There may be companies, however, that do not want to integrate their DNS with Active Directory, or that want to host a primary or secondary zone on a server separate from their domain controllers. If your environment fits into one of these cases, take note of the advice in the preceding section of this chapter, "Additional Security Settings—Active Directory integrated DNS," and use the alternatives and notes provided for organizations implementing nonintegrated DNS.

Infrastructure Server Incremental Policy

The Incremental Infrastructure Policy includes settings for system services that are required on the Infrastructure server.

System Services

The following table provides a summary of the prescribed system services that should be disabled or enabled on a Windows 2000 Infrastructure Server. The services are configured in the MSS Infrastructure Role.inf policy template, which is then imported into the Infrastructure Policy GPO.

Table 7.6  Infrastructure Server Incremental Policy Service Settings

Note   The DNS Server service is disabled for the Infrastructure Server role in the Contoso Scenario because it runs on the domain controllers.

Some organizations that may not use Active Directory-integrated DNS may want to run their primary and secondary DNS server on an Infrastructure server.

In this case, the Incremental Infrastructure Group Policy template has to be altered to enable the DNS Server service Startup Type to be configured to Automatic.

If this functionality is necessary in your organization, see the section "Additional Security Settings—Active Directory Integrated DNS" in this chapter for recommendations on securing a Windows 2000 DNS server.

Additional Security Settings—WINS

Blocking Ports with IPsec Filters

Vulnerability

As mentioned previously, reducing the number of ports that are open and actively listening on the servers in your organization will greatly reduce the attack surface of each computer. Open ports can provide an attacker with a launching pad to attack another server in the organization—for example, a worm and Trojan horse may install applications that bind to unauthorized ports on the server and listen for incoming commands.

Countermeasure

Configure IPsec blocking filters that allow only the specified network traffic in the following table. This countermeasure will reduce the number of unexpected and unauthorized applications that could successfully receive requests or that could be attacked.

Before implementing IPsec filters, you must have a full understanding of the capabilities and limitations of this technology. IPsec filters are very powerful, but can greatly affect the management and usability of computers. For more information, see Chapter 11, "Additional Countermeasures" of the Threats and Countermeasures guide at http://go.microsoft.com/fwlink/?LinkId=15159.

WINS Server IPsec Network Traffic Map

Table 7.7  WINS Server IPsec Network Traffic Map

Note   The Host IP destination address listed in Table 7.7 should be set to the IP address configured on your server.

All rules that are listed in the preceding table should be mirrored when they are implemented. This configuration ensures that any traffic coming in to the server will also be allowed to return to the originating server.

As seen in the preceding table, there are a small number of ports and services that have been opened on the WINS server. With this additional level of security, all WINS management and management of the servers will need to be performed through the use of Terminal Services. Also note that Contoso has implemented a MOM server in their environment. Because of the large interaction between the MOM server and the OnePoint client—the client application that reports to the MOM console—all network traffic is allowed between the server and the MOM server.

Scripting Commands

Implementation of the following commands should be executed on the server. These commands will block all network traffic except what is specifically allowed. This set of commands is also included in a batch file that accompanies this guide.

ipsecpol -w REG -p "Packet Filter" -r "Domain Member" 
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP>:: 
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring" 
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f 
*+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Resolution Server" 
-f *+0:1512:TCP -f *+0:1512:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Client" 
-f 0+<INSERT WINS Replication Partner>:42:TCP 
-f 0+<INSERT WINS Replication Partner>:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Server" 
-f <INSERT WINS Replication Partner>+0:42:TCP 
-f <INSERT WINS Replication Partner>+0:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f 
*+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f 
*+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x

Potential Impact

Because these settings do not allow network traffic through random high ports, RPC traffic will not be allowed. This configuration can make management of the server difficult. However, with the use of terminal services, a large amount of usability is regained.

The implementation of this relatively small number of IPsec policies should not have a noticeable impact on the performance of the server. However, a large amount of testing should be performed before implementing these filters in your environment to verify functionality and performance req