S 4.313 Provision of secure domain controllers

Initiation responsibility: Specialists Responsible, IT Security Officer, Head of IT

Implementation responsibility: Administrator

Since the Active Directory infrastructure is stored on the domain controllers, these must be configured correspondingly securely. The following security recommendations are intended to help minimise the risk when providing domain controllers.

Secure operation of domain controllers

As a matter of principle, domain controllers should be installed in a secure environment, e.g. in a computer centre or in rooms that can only be accessed by trusted personnel. Furthermore, they should also be protected by a secure infrastructure, for example with routers, switches, etc.

The modules in the IT-Grundschutz Catalogues in layer 3 for the corresponding Windows Server operating systems should be taken into consideration when installing the operating system.

Predictable and repeatable provision of domain controllers

In order to avoid possible configuration errors and to obtain a uniform level of security, the domain controllers should be configured using an image of the configuration of a reference installation. Furthermore, the security settings should also be specified uniformly in the basic setup of the domain controller. The implementation of a predictable and easy-to-repeat provision procedure helps to achieve these goals. This procedure should include the following tasks:

• Regular installation of the latest hotfixes and service packs
  
  Current hotfixes and service packs should be installed at regular intervals. The effects of the hotfixes and service packs should be thoroughly tested in advance on an image of the reference domain controller.
• Assignment of adequately strong passwords
  
  Adequately strong passwords must be assigned to the user accounts in the Active Directory. It should be guaranteed in this case that it is impossible to obtain access without authorisation. Information regarding sufficiently strong passwords can be found in safeguard S 2.11 Provisions governing the use of passwords. In addition to creating complex passwords, it is also necessary to ensure that the passwords are given to the corresponding people using a trusted path of communication. User accounts should also be assigned their own passwords, especially the first time they are set up.
• Disabling the automatic generation of so-called 8.3 file names in NTFS.
  
  The automatic generation of 8.3 file names (i.e. file names with eight characters for the name of the file and three characters for the file extension) should be disabled to prevent viruses and attacks that target file names compatible with the 8.3 format in particular. This functionality is not needed any more particularly if there are no 16-bit applications used any more. Furthermore, this also significantly increases the performance when listing directories. The following entry must be specified for this purpose in the registry key HKLM\SYSTEM\CurrentControlSet\Control\FileSystem:
  
  Name of Key = NtfsDisable8dot3NameCreation
  
  Data Type = REG_DWORD
  
  Value = 1
  
  Changes to the registry keys should be tested first in a test environment in terms of their compatibility and their effects.
• Disabling the pre-Windows-2000-compatibility:
  
  if there are no servers under Windows NT 4.0 within or outside of the overall structure and no Windows 2000 servers in a trusted domain outside of the overall structure, the pre-Windows-2000-compatibility functionality cannot be used. Otherwise, access authorisations would be granted that would allow anonymous access to Active Directory information.
• Ensuring the integrity of the installation
  
  If the domain controllers are installed at a different target site, signatures should be used for transport in order to ensure the integrity of the installations in this way

Restriction to required services only

In order too keep the number of potential points of attack on the domain controllers as low as possible, the number of services provided should be restricted to the minimum number required for operation.

Authorisations for executable files

In order to protect the master folders of the data media against storage space attacks after promoting the domain controllers, the authorisations for the "Everyone" group should be restricted to "read and execute". Only administrators should be granted full access rights.

Preventing the start of other operating systems

Starting a different operating system on a domain controller may allow the NTFS access restrictions to be bypassed and therefore allow access to critical data. For this reason, organisational precautions also must be taken in addition to physically securing the server as mentioned above.

Disabling remote network boots and therefore also the option of remote network installation using remote installation services (RIS) or the bootstrap protocol (BOOTP), for example, should be planned, as should be the use of BIOS password when booting the system.

Reboot protection using SYSKEY

The use of the system keys (SYSKEY) protects the security information in Windows against offline attacks. The passwords in the Active Directory database and the local security authority (LSA) are stored in encrypted form on the domain controller for this purpose. When the domain controller is rebooted after the SYSKEY has been enabled, users either must enter the password or the data media with the system key or they will not be able to boot the computer. It is always necessary, though, to remove the data media with the system key from the domain controller after use and to store it at a secure location. It should also be ensured that a working copy of this data medium is also available.

Review questions:

• Are the domain controllers operated in a secure environment?
• Is the underlying Windows Server operating system installed and configured securely on all domain controllers?
• Has an image of every domain controller been created?
• Are sufficiently strong passwords assigned to the user accounts?
• Has the generation of 8.3 file names been disabled?
• Has the pre-Windows-2000-compatibility been disabled?
• Have the authorisations for the "Everyone" group been restricted?
• Are the domain controllers protected against unauthorised restarts?