APP.2.2 Active Directory Domain Services

Description

Introduction

Active Directory (AD) is a collective term for various server roles developed by Microsoft for Windows Server. The server role Active Directory Domain Services (AD DS) aggregates the functionalities of a directory, authentication, and authorization service as well as a central configuration management for Windows infrastructures.

Active Directory Domain Services is mainly used in networks that are predominantly shaped by Microsoft-based operating systems. An AD DS stores and manages information about network resources (e.g., users, computers, and devices). If required, this information can, as is customary in LDAP directory services, also be extended by application-specific data. It serves users and administrators in organizing, providing, and using this information in a hierarchical structure. AD DS structures objects in namespaces referred to as forests, domains, and organizational units. A forest forms a hierarchical collection of domains, each of which can contain multiple organizational units. The first domain created in a forest — and therefore at the top of the hierarchy — assumes the role of the “forest root domain” by design and contains the administrative groups responsible for forest-wide management tasks such as adding further domains or schema changes. All domains within a forest are implicitly linked to each other by bidirectional, transitive trust relationships, so that the forest represents a logical security boundary.

As its authentication protocol, AD DS uses Kerberos v5 by default (in a Microsoft-extended implementation). Additionally, the NTLM (New Technology LAN Manager) protocol is still available. NTLM can be more easily exploited by attackers. Windows Servers with the AD DS server role are referred to as domain controllers. For availability reasons, multiple domain controllers are often deployed in a distributed manner. AD DS also offers the option of operating a domain controller in “Read-Only” mode, intended for locations with an elevated risk to physical security.

Objective

The objective of this building block is to secure Active Directory Domain Services in the regular operation of an institution that uses AD DS for the management of Windows systems (clients and servers) and for central authentication and authorization.

Scope and Modeling

The building block APP.2.2 Active Directory Domain Services is to be applied to all directory services that are based on Microsoft Active Directory Domain Services. It can additionally be used in part for modeling Active Directory Lightweight Directory Services (AD LDS), which offer a reduced range of functionality compared to AD DS.

This building block addresses the threats and requirements specific to Active Directory Domain Services. General security recommendations for directory services can be found in the building block APP.2.1 General Directory Service. The general requirements described there are specified and supplemented in this building block. This building block does not repeat the requirements for securing the operating systems of the servers and clients used for operating and managing AD DS, such as SYS.1.2.3 Windows Server or SYS.2.2.3 Clients Running Windows. This building block also does not address the requirements of the underlying network infrastructure.

Active Directory Domain Services should not be modeled independently of the building blocks ORP.4 Identity and Authorization Management, OPS.1.1.3 Patch and Change Management, CON.3 Data Backup Concept, OPS.1.2.2 Archiving, OPS.1.1.5 Logging, OPS.1.1.2 Proper IT Administration, OPS.1.2.5 Remote Maintenance, DER.1 Detection of Security-Relevant Events, DER.2 Security Incident Management, DER.4 Emergency Management, and APP.3.6 DNS Server. It should be assumed that the requirements of these building blocks mutually influence each other.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used as the basis for describing the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block APP.2.2 Active Directory Domain Services.

Insufficient Planning of Security Boundaries

In AD DS, various types of boundaries exist. These boundaries define the forest, the domain, the site topology, and the assignment of rights. An AD DS instance initially creates a forest as the highest-level container for all domains of that instance. A forest can contain one or more domain container objects that share a common logical structure, a Global Catalog, a schema, and automatic bidirectional, transitive trust relationships. This means that trust — and thus access — between domains within a forest is bidirectional. The forest thus represents the security boundary by design within which information is shared by default in AD DS. A domain forms only an administrative boundary. If security boundaries are not implemented along forest boundaries, a compromise can cause a greater extent of damage than expected, as it can lead to the compromise of all IT systems in the forest. This threat is a particular characteristic of AD DS, since the planning of partitioning in the directory service cannot be fully implemented due to the product design. A complete compromise of a forest means that attackers have control over all objects belonging to the contained domains, i.e., among other things all accounts and all IT systems. Thus, they potentially also have control over the associated IT systems and services.

Too Many or Careless Trust Relationships

Trust relationships between domains and between forests allow accounts from another domain or forest to be granted access to resources within one’s own domain or forest. If the trust relationships between forests and between domains are not initially and regularly evaluated as to whether they are needed and whether the security controls surrounding these trust relationships are adequate, permission issues can arise and information can leak. Particularly when the SID (Security Identifier) filtering that is active by default is disabled, complex, difficult-to-understand configuration errors can arise that can lead to abusive use of the trust relationship and to extensive access rights. The same applies when “Selective Authentication” is forgone in trust relationships between forests.

Missing Security Functions Due to Older Operating Systems and Domain and Forest Functional Levels

Up to and including Windows Server 2016, each new generation of the Windows Server operating system brings additional security functions and enhancements relating to AD DS in the form of domain or forest functional levels. If older operating systems are used as domain controllers or outdated domain or forest functional levels are employed, current security functions cannot be utilized. This increases the risk of insecure default settings. An insecurely configured forest or domain endangers the information processed within it and facilitates attacks by third parties.

Operation of Additional Roles and Services on Domain Controllers

If additional services are operated on a domain controller in addition to AD DS, this further increases the attack surface of this central component — beyond the services already heavily accumulated by AD DS — through possible additional vulnerabilities and misconfigurations. Such services can be deliberately or inadvertently misused, e.g., to copy or modify information without authorization or, in the case of vulnerabilities or misconfigurations that lead to the compromise of the domain controller, to take over the domain or forest.

Insufficient Monitoring and Documentation of Delegated Rights

If the formation of institution-specific groups and the delegation of rights to these groups or to individual user objects are not systematically planned and implemented, the delegation can become difficult to control. It could then, for example, grant far more access than intended, which can be exploited by third parties. The lack of regular auditing of the access rights of group and individual user objects can further exacerbate the problem. Even when standard groups are used and their rights are delegated to custom groups, for example when delegating “Account Operators” to helpdesk employees, more rights are generally granted than are actually needed.

Insecure Authentication

So-called “legacy” authentication mechanisms in the AD DS area, such as LAN Manager (LM) and NT LAN Manager (NTLM) v1, are insecure and can be misused in attacks under certain conditions. Attackers can, for example, obtain and misuse rights without knowledge of the plaintext passwords, thus compromising parts of the domain, the domain itself, or even the entire forest.

Overly Powerful or Weakly Secured Accounts

Application software sometimes requires the rights of highly privileged groups (such as so-called domain administrators) for service accounts in order to test and deploy products more easily, even though far fewer rights are necessary for operation. A particular risk exists when these service accounts are secured with weak passwords. Accounts that are not members of a highly privileged group can also be assigned administrative permissions, for example on a large number of servers and clients. They thus possess similarly extensive rights as members of highly privileged groups in AD DS. The extensive rights of these accounts can be exploited by attackers to move laterally within the domain.

Use of the Same Local Administrator Password on Multiple IT Systems

Even if an IT system is joined to a domain, it is still possible to log on to that IT system with local accounts. If the same local credentials are used on multiple IT systems, a logon using these — among others, with the local built-in Administrator account — is possible on multiple IT systems. This makes it easier for attackers to move laterally and thus spread through the infrastructure. This increases the risk that attackers will find credentials of a domain account with higher privileges on one of the IT systems and be able to misuse these to compromise the domain and potentially the entire forest.

Insecure Storage of Passwords

The storage of passwords is carried out in the central AD DS database (ntds.dit) on the domain controller using, among other methods, the MD4 hash function without salt, due to the product design. This hash function does not meet the requirements of BSI Technical Guideline TR-02102-1 “Cryptographic Mechanisms: Recommendations and Key Lengths”. Unauthorized read access to the stored passwords is therefore particularly critical. Due to the widespread use of AD DS, many tools exist for extracting password hashes. The AD DS database can be decrypted offline, for example, using additional keys stored on the domain controller, enabling access to the hashes. Furthermore, the weak hash function makes it possible to determine plaintext passwords.

Insufficient Hardening of Domain Controllers

Each (Read-Write) domain controller in a domain holds a complete replica of the central AD DS database (ntds.dit), in which passwords are stored insecurely. In addition to insufficient protection against access by third parties to the domain controllers during operation, an inadequate backup procedure can also lead to the extraction of the central AD DS database and, as a consequence, to the leakage of information and the compromise of the domain and potentially the entire forest. The operation of virtualized domain controllers together with less sensitive virtual machines on a physical virtualization host can also lead to a compromise of AD DS. This also applies if the administrative accounts of the virtualization host — which have full access to AD DS by virtue of their administrative activities — are not adequately protected.

Leaving Highly Privileged Login Credentials on Domain Member Servers and Clients

If a logon or use of a service occurs with highly privileged accounts on a server or client in the domain, the associated credentials are cached on that system (e.g., in the memory of the Local Security Authority Subsystem / LSASS). In the event of a compromise, attackers can extract these there. This means that a compromise of a single server or client in the domain can lead to the entire domain and potentially the entire forest being compromised.

Adding Untrusted IT Systems to the Windows Domain

In the default configuration, all users authenticated in AD DS may add up to ten IT systems to the domain, even if they do not have administrative permissions in AD DS. This allows them to add IT systems to the domain on which they hold high privileges. These privileges can be used as a starting point for further attacks. Since adding IT systems to a domain is an administrative task that is typically embedded in an IT process, difficult-to-predict side effects can arise when IT systems join the domain without going through this process correctly.

Entanglement of Administrative Privileges Through Integration of Additional Applications

If applications with AD DS integration are used (e.g., Microsoft Exchange), administrative permissions in AD DS may be assigned to the AD DS accounts created by these applications. This can mean that security vulnerabilities in these applications allow attackers to obtain extensive administrative rights on IT systems within the forest. An example of this is the security vulnerability CVE-2019-0686 (PrivExchange) in Microsoft Exchange.

Requirements

The following are the specific requirements of the building block APP.2.2 Active Directory Domain Services. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These SHOULD be filled insofar as this is meaningful and appropriate.

Exactly one role SHOULD be Primarily responsible. There may also be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people SHOULD fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

APP.2.2.A1 Planning of Active Directory Domain Services (B) [Fachverantwortliche]

A functional level of at least Windows Server 2016 MUST be chosen for the domain(s) and the forest. A needs-based authorization concept for the domain(s) and the forest MUST be designed. In doing so, it MUST be taken into account that by design there are no security boundaries between the individual domains of a forest, and therefore no secure limitation of administrative areas within a forest is possible. Administrative delegations MUST be equipped with restrictive and needs-based permissions. The planned structure including any schema changes MUST be documented in a comprehensible manner.

APP.2.2.A2 DISCONTINUED (B)

This requirement has been discontinued.

APP.2.2.A3 Planning Group Policies Under Windows (B)

A concept for setting up Group Policy Objects MUST be in place. Multiple overlapping coverages MUST be avoided as far as possible in the Group Policy concept. In the documentation of the Group Policy concept, exception rules MUST be identifiable. All Group Policy Objects MUST be protected by restrictive access rights. Secure defaults MUST be specified for the parameters in all Group Policy Objects.

APP.2.2.A4 DISCONTINUED (B)

This requirement has been discontinued.

APP.2.2.A5 Hardening of the Domain Controller (B)

Due to the central role of AD DS and the impact of a compromise on the infrastructure, a risk assessment SHOULD be carried out. Emergency access to the domain controller with the local restore account DSRM (Directory Services Restore Mode) MUST be planned as part of emergency management.

On the domain controller, a sufficient size for the security log MUST be set based on the time period established in DER.1 Detection of Security-Relevant Events. Due to the central importance of the domain controller, no additional services SHOULD be operated on this server unless they are strictly required on the same server for operating AD DS.

APP.2.2.A6 Secure Configuration of Trust Relationships (B)

All trust relationships between domains and between forests MUST be regularly evaluated for their necessity and security measures. In doing so, it MUST be checked whether a bidirectional trust relationship is necessary. If a domain does not require a bidirectional trust relationship with other domains in the forest, this domain SHOULD be moved to its own forest, since by design no adaptation of the trust relationships within a forest is possible.

The SID (Security Identifier) filtering for trust relationships between forests MUST NOT be disabled. The preconfigured SIDs MUST NOT be removed. If the information domain represented in the forest that is being trusted does not have an adequate security level, “Selective Authentication” MUST be used for the trust relationship with this forest.

APP.2.2.A7 Implementation of Secure Administration Methods for Active Directory (B) [Fachverantwortliche]

It MUST be ensured that accounts of service administrators are managed exclusively by members of the group of service administrators. Before accounts are added to predefined AD DS groups, it SHOULD be checked whether all rights belonging to the group are required for the activities associated with the accounts. The groups “Schema Admins”, “Enterprise Admins”, and “Domain Admins” SHOULD, in addition to the AD DS built-in administrator account, only be temporarily assigned additional administrative accounts for the period during which they need these permissions.

APP.2.2.A16 Hardening of AD DS Accounts (B)

Built-in AD DS accounts MUST be provided with complex passwords. They MUST ONLY serve as emergency accounts. The built-in “Guest” account MUST be disabled. The permissions for the “Everyone” group MUST be restricted. Privileged accounts MUST be members of the “Protected Users” group. (Group) Managed Service Accounts MUST be used for service accounts. Before unused accounts are deleted, it MUST be checked after what retention period they can be deleted. In doing so, the implications for detection and legal retention and deletion periods MUST be taken into account. Access to the AdminSDHolder object SHOULD be specially protected to safeguard the permissions.

APP.2.2.A17 Logon Restrictions for Highly Privileged Forest Accounts on Clients and Servers (B)

The logon of highly privileged domain and forest accounts and groups MUST be technically restricted to the minimum necessary IT systems. In particular, the logon of members of the groups “Schema Admins”, “Enterprise Admins”, and “Domain Admins” SHOULD be technically restricted to the domain controller; logon on other IT systems is thus to be prevented for these groups.

APP.2.2.A18 Restricting the Addition of New Computer Objects to the Domain (B)

The authorization to add new computer objects to the domain MUST be restricted to the necessary administrative accounts.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be met.

APP.2.2.A8 Securing the “Secure Channel” (S)

The “Secure Channel” SHOULD be configured so that all transmitted data is always encrypted and signed.

APP.2.2.A9 Protection of Authentication When Using AD DS (S)

The Kerberos authentication protocol SHOULD be used consistently throughout the forest. For securing this, AES128_HMAC_SHA1 or AES256_HMAC_SHA1 SHOULD be used. If NTLMv2 is used transitionally for compatibility reasons, migration to Kerberos SHOULD be planned and scheduled. LM authentication and NTLMv1 MUST be disabled. SMB traffic MUST be signed. SMBv1 MUST be disabled. Anonymous access to domain controllers SHOULD be prevented. LDAP sessions SHOULD only occur with signing and configured Channel Binding Token (CBT).

APP.2.2.A10 DISCONTINUED (S)

This requirement has been discontinued.

APP.2.2.A11 DISCONTINUED (S)

This requirement has been discontinued.

APP.2.2.A12 Data Backup for Domain Controllers (S)

Due to the particular threat posed by insecurely stored passwords, access to backups of the domain controller SHOULD be secured comparable to access to the domain controller itself.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. These proposals SHOULD be considered when there is a high protection need. The specific determination takes place in the context of an individual risk analysis.

APP.2.2.A13 DISCONTINUED (H)

This requirement has been discontinued.

APP.2.2.A14 DISCONTINUED (H)

This requirement has been discontinued.

APP.2.2.A15 Outsourcing Administration to a Dedicated Forest (H)

Particularly critical IT systems and accounts for administering the domains or the forest SHOULD be moved to a dedicated forest (often referred to as a “Red Forest”), to which a one-way trust relationship exists from the managed forest. This SHOULD be given particular consideration in the context of emergency management when creating the emergency manual.

APP.2.2.A19 Operation of Virtualized Domain Controllers (H)

Virtualized domain controllers SHOULD NOT be operated together with other virtualized IT systems on the same physical host. When securing the administrative accounts for access via the virtualization layer, it SHOULD be taken into account that these accounts have full access to the domain controller, which is then comparable to membership in the “Domain Admins” group. The virtualization host, the IT systems involved in virtualization management, and the administration accounts for the virtualization layer SHOULD NOT belong to the forest to which the virtualized domain controller belongs.

APP.2.2.A20 Separation of Organizational Units (H)

Organizational units that must ensure independence from each other for IT security reasons or other reasons SHOULD NOT be in the same forest.

APP.2.2.A21 Configuration of a Tier Model (H)

The authorization structure within the forest SHOULD be designed in tiers oriented toward the protection needs of the accounts, IT systems, and applications. In this structuring, all accounts, IT systems, and applications within a forest SHOULD be unambiguously assignable to a tier. Accounts from a higher tier SHOULD NOT be able to log on to resources of a lower tier. Accounts from a lower tier SHOULD NOT have the ability to control accounts and resources of higher tiers.

APP.2.2.A22 Time-Limited Permissions for Administration (H)

Accounts used for administration SHOULD only be assigned the permissions necessary for the administrative task, limited to the required time window, on a needs basis.

APP.2.2.A23 Regular Analysis of Permissions and Resulting Attack Paths (H)

Due to the complexity of permissions that are not always immediately apparent, a regular analysis of the permission structures in AD DS SHOULD be carried out. In particular, permissions that arise from the integration of applications into AD DS (e.g., Microsoft Exchange) SHOULD be critically checked for their necessity and reduced to the minimum necessary permissions. Updates can also change permission structures in AD DS; therefore, the analysis SHOULD also be carried out after such updates. Possible attack paths via the permissions of AD DS accounts that could lead, for example in the event of account compromise, to the compromise of the domain or the entire forest SHOULD be minimized as far as possible. The activities of the remaining accounts identified as critical SHOULD be monitored with particular attention.

Additional Information

Good to Know

The website “Active Directory Security” (https://adsecurity.org) contains many further pieces of information on AD security.

The manufacturer Microsoft provides further information on Active Directory and its security aspects:

• Entry point for Active Directory Domain Services https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-domain-services
• Documentation on “Implementing Least-Privilege Administrative Models” https://docs.microsoft.com/de-de/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
• Overview of domains and forests https://docs.microsoft.com/de-de/previous-versions/windows/it-pro/windows-server-2003/cc759073(v=ws.10)
• Security aspects of trust relationships https://docs.microsoft.com/de-de/previous-versions/windows/it-pro/windows-server-2003/cc755321(v=ws.10)
• Documentation on the tier model https://web.archive.org/web/20171205072455/https:/docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material