Contact Us

Kevin Vaccaro
Phone: 773-702-6198
vac1@uchicago.edu

Home > Documentation > UCAD > Support for Administrators > Best Practices for UCAD Forest

University of Chicago Active Directory

UCAD Home | Glossary | Policies | Diagram | Support for Administrators | Governance

Best Practices for UCAD Forest

Each domain within the forest should have at a minimum of two domain controllers in order to provide some level of recovery in the event of a domain controller failure. However, in the UCAD forest, NSIT installed three domain controllers in each domain. This was done in order to provide an even greater level of security in the event of a machine(s) failure, and to make it easier to patch domain controllers without disrupting normal business processes.

This page contains best practices for the following areas:

Domain Controller Flexible Single Master Operation (FSMO) Role Placement

When configuring domain controller FSMO role placement, follow these general guidelines:

  • Each domain requires at least one Global Catalog Server to support UCAD design.
  • Global Catalog Server and Infrastructure Master should not reside on same machine unless the machine is the last domain controller for the domain.
  • PDC Emulator, Infrastructure Master and RID Master should reside on separate machines if possible (during patching or system failure/replacement, this may not be possible).
  • Each site within the forest requires at least one domain controller. A Global Catalog Server is also required if there are more than 50 users, presence of Exchange, or a slow WAN link.
  • The PDC Emulator and RID Master roles should be on the same machine because the PDC Emulator is a large consumer of RIDs.
  • For easier administration, the Schema Master and Domain Naming Master should be on the same machine. This machine should also be a Global Catalog Server. (The Global Catalog Server recommendation goes away at Windows 2003 forest functional level. There should be a direct connection from this machine to a Global Catalog Server in the same site, however.)

Physical Security

Physical security of domain controllers is the first line of defense against an attack. NSIT assumes that all domain controllers will be housed in a secure location with a locked door of some type. Physical access should be allowed only for personnel who have a need to access the machines.

File/Share Access and Permissions

  • Keep System and Administrators accounts with enough access to the file/share. If these two accounts are denied necessary access, the system could be adversely affected.
  • The default access on shares is for "everyone" to have full control. If the disk permissions are set properly, there is no need to change the share permissions. However, for the most secure environment, share permissions should map to disk permissions.
  • Be careful how you use block inheritance when setting permissions. The system default is to have permissions propagate down to the files/folders below the root folder. If block inheritance is used and permissions are removed, this could have an adverse affect on the system.

Machine specific Security and Configuration

  • All drives on domain controllers must be formatted with NTFS.
  • Each domain controller should meet the following minimum standards:
    CPU: Dual CPU, 1GHZ minimum
    Memory: 1GB minimum, 2GB if Global Catalog Server
    System Drive: 16GB minimum
    AD database/logs/sysvol drive: 16GB minimum
    Power Supplies: Dual power supplies, if possible
    Fans: Dual fans, if possible
    Network Cards: Two 100MB/sec cards with IPSEC support
    Raid Level (hardware raid): Raid 1 for system; Raid 1/5 for AD drive
  • All domain controllers must be sole purpose machines. No other applications, anti-virus, IDS and monitoring client not withstanding, should exist on the machines.
  • Login access to the domain controller console should be limited to Domain Administrators.
  • Terminal service access should be limited to Domain Administrators.
  • Rename the Guest and Administrator accounts in the domain and change their descriptions.

TCP/IP stack hardening

Set the following settings under HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\Tcpip\Parameters\:

  • SynAttackProtect
    Value name: SynAttackProtect
    Key: Tcpip\Parameters
    Value Type: REG_DWORD
    Valid Range: 0,1
    Default: 0

    This registry value causes Transmission Control Protocol (TCP) to adjust retransmission of SYN-ACKS. When you configure this value, the connection responses time out more quickly during a SYN attack (a type of denial of service attack).

    The following parameters can be used with this registry value:

    • 0 (default value): Set "SynAttackProtect" to "0" for typical protection against SYN attacks.
    • 1: Set "SynAttackProtect" to "1" for better protection against SYN attacks. This parameter causes TCP to adjust the retransmission of SYN-ACKS. When you set SynAttackProtect to 1, connection responses time out more quickly if the system detects that a SYN attack is in progress. Windows uses the following values to determine whether an attack is in progress:
      • TcpMaxPortsExhausted
      • TCPMaxHalfOpen
      • TCPMaxHalfOpenRetried

  • EnableDeadGWDetect
    Value name: EnableDeadGWDetect
    Key: Tcpip\Parameters
    Value Type: REG_DWORD
    Valid Range: 0, 1 (False, True)
    Default: 1 (True)

    The following list explains the parameters that you can use with this registry value:

    • 1 (default value): When you set "EnableDeadGWDetect" to "1", TCP is permitted to perform dead-gateway detection. When dead-gateway detection is enabled, TCP may ask the Internet Protocol (IP) to change to a backup gateway if a number of connections are experiencing difficulty. Backup gateways are defined in the Advanced section of the TCP/IP configuration dialog box in the Network tool in Control Panel.
    • 0: Microsoft recommends that you set the "EnableDeadGWDetect" value to "0". If you do not set this value to 0, an attack may force the server to switch gateways and cause it to switch to an unintended gateway.

  • EnablePMTUDiscovery
    Value name: EnablePMTUDiscovery
    Key: Tcpip\Parameters
    Value Type: REG_DWORD
    Valid Range: 0, 1 (False, True)
    Default: 1 (True)

    The following list explains the parameters that you can use with this registry value:

    • 1 (default value): When you set "EnablePMTUDiscovery" to "1", TCP tries to discover either the maximum transmission unit (MTU) or the largest packet size over the path to a remote host. TCP can remove fragmentation at routers along the path that connect networks with different MTUs by discovering the path MTU and limiting TCP segments to this size. Fragmentation adversely affects TCP throughput.
    • 0: Microsoft recommends that you set "EnablePMTUDiscovery" to "0". When you do so, an MTU of 576 bytes is used for all connections that are not hosts on the local subnet. If you do not set this value to 0, an attacker may force the MTU value to a very small value and overwork the stack.

  • KeepAliveTime
    Value name: KeepAliveTime
    Key: Tcpip\Parameters
    Value Type: REG_DWORD-Time in milliseconds
    Valid Range: 1-0xFFFFFFFF
    Default: 7,200,000 (two hours)

    This value controls how frequently TCP tries to verify that an idle connection is still intact by sending a keep-alive packet. If the remote computer is still reachable, it acknowledges the keep-alive packet. Keep-alive packets are not sent by default. You can use a program to configure this value on a connection. The recommended value setting is "300,000" (5 minutes).


  • NoNameReleaseOnDemand
    Value name: NoNameReleaseOnDemand
    Key: Netbt\Parameters
    Value Type: REG_DWORD
    Valid Range: 0, 1 (False, True)
    Default: 0 (False)

    This value determines whether the computer releases its NetBIOS name when it receives a name-release request. This value was added to permit the administrator to protect the computer against malicious name-release attacks. Microsoft recommends that you set the "NoNameReleaseOnDemand" value to "1".

Additional Links

 

Return to Support for System Administrators

Last updated: 6/6/07