Active Directory structure

Domain

A domain is Active Directory’s basic unit of organization.

Every network built around Active Directory must have at least one domain and a domain controller that authenticates access to that domain. Each domain is made up of lots of objects which represent physical entities such as users, printers and servers, and organizational entities such as folders and groups.

One structural point worth understanding: a domain controller is the domain. Any administrator with control over a domain controller controls the entire domain (thus the name!). This shapes how privileged access in AD must be designed, and why the security of domain controllers is often treated as separate from ordinary server management.

Default Domain Policy and the Default Domain Controllers Policy are often more permissive than many AD administrators realize. The default state is designed for the directory to function as, well, a directory. Think of the old yellow pages, where you flip through to find the contact you need. Seen through a security lens, there's obvious risk when that same visibility can be turned towards reconnaissance. It's important to examine the default settings and adjust them appropriately. What "appropriate" is, is the question. The answer is more complex than we'll cover here, but much ink has been spilled on the topic by worthy Microsoft MVPs.

Domain Tree

In the beginning, there was one domain. And everyone assumed organizations would be happy with that single domain.

This made life easy: only one domain to manage. But then networks grew in size and organizational complexity. It made sense to divide employees into multiple smaller domains in the same namespace (i.e., xyzcompany.com).

Doing this created a domain “tree,” namely a group of Active Directory domains comprising a root domain and one or more child domains. To avoid management complexity, domains within a tree have an automatic trust relationship.

These trusts go both ways. Smart people would say they're bidirectional and transitive. A parent domain trusts its child, and that trust flows through the entire hierarchy.

Active Directory authentication can pass across domains without administrators having to manually configure anything between them. But there is a security implication most introductions to AD leave out: the domain is not itself a security boundary in Active Directory. That distinction belongs to the forest. This means that all domains within the same tree share, logically, a common attack surface.

Through a series of privilege escalations (depending on whether your privileged group configurations are left at default), a Domain Admin in one domain can escalate to Enterprise Admin. A compromise in any domain in the tree can impact all.

Forest

As with all networking, Active Directory loves its organic analogies. It starts with the idea of domains, roots, trees, and forests. In fact, there is logic in this arboreal terminology. Active Directory domains are collections of objects such as users, trees are collections of domains in a hierarchical structure, and forests are collections of multiple trees that share a trust relationship.

The forest is the true security boundary in Active Directory. Not the domain. All domains within a forest share a common attack surface, as AD pros know all too well.

Why run multiple forests? Usually for security reasons, where separation is an advantage. But be warned: this comes at the expense of a bigger management workload. There are, of course, many situations that legitimately justify multiple forests. But for most scenarios, modern guidance points to a single-domain forest as simpler to manage and secure.

FQDN – Fully Qualified Domain Name

The fully qualified domain name (FQDN) is the full address of a server or website on a network. In this case, one based on Active Directory. This address is useful when trying to check the availability of an Active Directory server or when the admin is bored and wants something to do.

In an Active Directory environment, the FQDN matters because two of AD's critical functions, DNS resolution and Kerberos authentication, both depend on it.

DNS health is impossible to separate from AD health. Ask any AD admin, they will tell you all about their DNS problems.

There are a lot of opinions on naming domains, which include: please, please avoid reusing the organization's public website FQDN as the internal domain name.

Functional Levels

Over time, successive versions of Windows Server and Active Directory have added new capabilities to domains and forests. These are encapsulated in what are termed functional levels. Ideally, the higher the functional level of a domain controller, the better. For example, Windows Server 2016: a version that introduced significant upgrades.

However, where some controllers are running versions before Server 2016, the functional level is set by the earliest version.

Anxiety about functional levels, including when and how to raise them, is an occasional anxiety every Active Directory admin must lose sleep over at some point. If you do raise functional levels, do not forget to test in a non-production environment first.

Network

A computer network used to be a way to connect individual computers, servers and resources to one another through a LAN. For operating systems like Windows NT this model worked well enough with small numbers of computers and even provided a degree of centralization for client management.

So how did Active Directory improve on this? For one, by addressing the scalability limits with a structured directory service capable of growing with organizations of any size. After all, directory services based on x.500 weren’t even a new idea. But those older directory services weren’t serving a rapidly growing operating system that was now appearing on and under desks across the globe.

Active Directory tamed this awkward young upstart, giving it the directory service it needed to grow up. Suddenly Windows networks could scale to any size through a logical structure of domains. Active Directory did this.

Objects

Arranged as a hierarchy, objects are the building blocks or entities from which Active Directory is built. They come in a variety of types. For example, simple objects such as user accounts, printers or servers, or hierarchical objects such as AD domains or groups. They can also be organizational objects in which any combination of the above is grouped.

The point of an object is to store the mandatory and optional attributes of a resource. For example, a user object stores a username, password hash, group memberships, and access permissions.

A particularly important object type in Active Directory is the Organizational Unit (OU), which has several key roles.

On a practical note: AD admins know to check the default access controls on AD objects. As is often the case, they're more open than most practitioners might expect. Attackers take full advantage of this if left the opportunity.