AD 101
Components
Active Directory (AD) is Microsoft’s centralized identity and access management system, used to govern users, machines, groups, and permissions across enterprise Windows networks. It structures these objects hierarchically to enable scalable delegation and fine-grained access control.
Forest → the top of this hierarchy, defines the ultimate trust and security boundary
Domains → forests can contain multiple domains, each acting as an independent administrative unit with its own objects and policies, but capable of establishing trust with other domains
Organizational Units (OUs) → domains can have multiple OUs which provide logical grouping to streamline delegation and Group Policy enforcement without breaking domain boundaries
Some crucial parts of an AD environment are:
Domain Controller
The backbone of AD, responsible for authenticating users, authorizing access, and maintaining a synchronized copy of the domain’s directory data.
DNS
AD relies heavily on DNS for name resolution and service location; without it, core functions like locating DCs or processing logons will fail.
Schema
Defines the structure and rules for all directory objects, specifying what attributes they have and how they relate.
Global Catalog
Hosted on selected DCs, stores a partial, searchable view of all objects across the forest, supporting cross-domain queries and universal group resolution.
Replication Service
Keeps directory data consistent across DCs, making any change quickly available throughout the environment.
GPOs & OUs
Group Policy settings are managed through Group Policy Objects (GPOs), which can be linked to sites, domains, or, most commonly, OUs. OUs represent the lowest level in AD to which GPOs can be directly applied, making them a key target for both administrators and attackers seeking to influence system behavior at scale.
Two common GPO-based mechanisms for managing local group membership are Restricted Groups and Group Policy Preferences (GPP):
Restricted Groups, located under Security Settings in a GPO, enforce strict membership by explicitly defining who should (or shouldn't) be in a given local group, typically the local Administrators group. Any accounts not listed are removed, making this a rigid but reliable enforcement tool.
In contrast,
groups.xml, used in GPP, provides more granular control, allowing additions, removals, or replacements without purging existing members unless explicitly instructed. This flexibility makes it a frequent choice for incremental changes, though its looser controls can leave openings for misconfiguration or abuse.
Trusts
A forest trust establishes a trust relationship between two distinct AD forests, allowing cross-forest authentication and resource access. Trusts can be one-way, where users from Forest A can access Forest B but not vice versa, or two-way, where mutual access is permitted. The default intra-forest trusts (tree-root, parent-child) between domains are transitive two-way trusts. The direction of access is always opposite to the direction of trust: if Forest A trusts Forest B, then users in B can access resources in A.
Forest trusts must be manually configured by administrators and require both forests to be at Windows Server 2003 functional level or higher. These trusts can be transitive, allowing access to other trusted domains within the forests, or non-transitive, restricting access to just the explicitly defined trust partner. For example, if Forest 2 holds two-way transitive trusts with both Forest 1 and Forest 3, users in Forests 1 and 3 can access resources in Forest 2, but not directly between each other. A direct two-way transitive trust between Forests 1 and 3 would be required for full access in both directions.
Forest trust transitivity does not extend beyond the two forests involved in a trust:
Forest 1 ⇄ Forest 2 ⇄ Forest 3 ≠ Forest 1 ⇄ Forest 3
In contrast, an external trust is a non-transitive relationship between two specific domains in separate forests. It’s typically used when a full forest trust isn’t feasible. If Domain B and Domain E are connected via an external trust, users in one can access resources in the other but cannot traverse further. For example, Domain B cannot access Domain D through Domain E unless Domain E itself is compromised.
From a red team perspective, this highlights a pivot potential: compromising a trusted domain (e.g. Domain E) can enable lateral movement across otherwise untrusted domains or forests.
NT Authority\SYSTEM
The NT AUTHORITY\SYSTEM account is a built-in Windows account used by the Service Control Manager to run operating system services. It has significantly more privileges than a standard local administrator account, as it operates with extensive control over the local system. Most core Windows services run under this account because it has the required permissions to interact with system components, hardware, and security mechanisms.
On domain-joined hosts, access to a SYSTEM context can be particularly valuable. Because the machine itself is joined to Active Directory, the SYSTEM account can authenticate as the computer account (for example, HOSTNAME$). This allows an attacker or administrator with SYSTEM-level access to enumerate domain resources and perform certain authentication or directory operations as the machine.
In many scenarios, having SYSTEM privileges is functionally similar to possessing valid domain computer account credentials. However, this access cannot be used for cross-domain trust Kerberos attacks, as those operations often require a user account with appropriate trust or delegation privileges.
Last updated