Episode 28 — Windows Domain Basics: AD Structure and Trusts
At its core, Active Directory organizes identity into forests, domains, and organizational units, known as O Us. A forest represents the ultimate security boundary—a collection of domains that share a schema, configuration, and global catalog. Within that forest, each domain maintains its own policies, users, and computers but trusts the others through transitive relationships. Organizational units act as administrative subdivisions within a domain, letting administrators delegate control or apply Group Policy Objects to specific subsets. Properly scoped O Us simplify management by separating duties and preventing accidental policy inheritance across unrelated teams. The hierarchy, when drawn out, resembles a branching tree whose strength lies in both the structure and the consistency of how it grows.
Every forest depends on domain controllers, or D Cs, which are servers that hold and replicate the directory database. Each D C authenticates logins, enforces policy, and distributes directory updates to its peers. Some controllers also host the Global Catalog, a partial replica that allows searches across the entire forest. Without these servers, logons would fail and trust would fragment, making redundancy vital. Windows promotes certain controllers to carry extra responsibilities, such as catalog maintenance or schema updates, but all of them together form the backbone of A D availability. When designed with sufficient redundancy, even the loss of one controller does not halt authentication.
The Sites and Services component of Active Directory translates network topology into replication logic. A D Sites map to physical or logical locations, typically defined by subnets, and determine how data replicates between domain controllers. Within a site, replication is frequent and efficient; between sites, it follows scheduled, compressed patterns to conserve bandwidth. Proper site design ensures that authentication requests travel to nearby controllers rather than across slow links. When configured well, the directory mirrors the organization’s physical layout, achieving both speed and resilience. Poor topology planning, by contrast, can leave remote offices authenticating over fragile connections or relying on outdated data.
Tightly intertwined with Active Directory is the Domain Name System, or D N S. Every domain controller registers service, or S R V, records that advertise its capabilities—such as hosting Kerberos authentication or global catalog services. Clients query D N S to locate these controllers, which means directory reliability depends on accurate, healthy name resolution. In many environments, D N S and A D share the same infrastructure, with zones integrated directly into the directory for automatic updates. Monitoring these records ensures that stale entries are removed and new controllers appear promptly, preventing misdirection or delays in authentication. A D without dependable D N S is like a city with missing street signs—functional but frustratingly slow to navigate.
Functional levels define which modern features a forest or domain can use. They correspond to the version of Windows Server that introduced new directory capabilities. Raising functional levels unlocks improved security, replication efficiency, and management options but requires that all controllers run compatible versions. Administrators often postpone this upgrade out of caution, yet remaining on older levels leaves advanced protections—like fine-grained password policies or advanced Kerberos encryption—untapped. Functional level planning should therefore be part of routine lifecycle management, ensuring the environment evolves safely without freezing innovation.
Kerberos authentication serves as the heart of modern domain trust. When a user logs in, a ticket-granting process replaces passwords with time-bound cryptographic proofs. The Key Distribution Center, housed within each domain controller, issues a Ticket Granting Ticket (T G T) that can then request service tickets for specific resources. Service Principal Names, or S P Ns, identify these resources so tickets can map securely to services. Delegation allows one service to act on a user’s behalf under controlled circumstances, a feature that must be tightly scoped to prevent privilege escalation. The beauty of Kerberos lies in its mutual authentication and its ability to keep credentials out of transit. When it works correctly, both client and server trust the ticket, not the network.
Despite Kerberos being the modern default, the legacy N T L M protocol still persists. It survives mainly in environments with older applications, standalone systems, or cross-forest situations where Kerberos is unavailable. N T L M relies on challenge-response mechanisms that have long been vulnerable to replay and relay attacks. Administrators should identify where it remains, restrict its use to unavoidable scenarios, and monitor for signs of misuse. Gradual deprecation is the goal, moving all feasible authentication paths to Kerberos or newer models like certificate-based logon. N T L M is a reminder of Windows’ long history and the trade-offs made to maintain backward compatibility.
Active Directory’s concept of trust extends beyond a single domain. Trusts define whether one domain or forest recognizes the authentication authority of another. External trusts link separate organizations, forest trusts connect entire collections, and realm trusts integrate with non-Windows environments such as Kerberos realms in Unix systems. These relationships determine whether users from one domain can access resources in another and under what conditions. Each trust carries implications for replication scope, authentication flow, and attack surface. Designing them requires not only technical setup but also policy clarity about why such trust is necessary and how it will be reviewed over time.
Direction matters in trust relationships. A one-way trust allows Domain A to trust Domain B without granting the reverse, while a two-way trust enables mutual recognition. The distinction is crucial when isolating sensitive environments such as production and testing domains. By controlling trust direction, administrators control the flow of authentication and limit potential lateral movement during breaches. This is not just a matter of design elegance but of containment—who can issue tokens that other systems will accept defines how far an attacker can roam if compromise occurs. The rule of thumb is to grant only the trust required and nothing beyond.
Selective authentication and S I D filtering further refine these boundaries. Selective authentication restricts which users from a trusted domain can authenticate to resources in the trusting domain, adding precision to broad trust relationships. S I D filtering prevents injected or forged identifiers from crossing trust boundaries, reducing the risk of privilege escalation through manipulated group memberships. Both features act as circuit breakers, ensuring that even trusted connections operate under strict scrutiny. Without them, large enterprises with complex forests can unknowingly extend excessive rights far beyond their intended scope.
Delegation models and administrative units define how control is distributed across people and systems within A D. Delegation allows administrators to grant limited authority—such as resetting passwords or managing specific O Us—without handing over full domain control. Administrative units, a more recent addition in hybrid environments, provide granular control aligned with cloud-integrated identity management. Together, they embody the principle of least privilege, allowing operational teams to perform their duties without jeopardizing the integrity of the directory as a whole. When delegation boundaries are clear, accountability becomes visible, and mistakes stay contained.
A well-structured Active Directory environment supports security by design rather than by reaction. Forests set the boundaries of trust, domains define administrative scope, and O Us organize the daily rhythm of control. Proper configuration of replication, D N S, functional levels, and authentication protocols keeps that structure alive and reliable. Trust relationships, both internal and external, extend identity safely when governed with precision. In the end, A D architecture reflects organizational discipline—each object, role, and boundary telling a story about how the enterprise values control, transparency, and resilience in the face of inevitable change.
