← Go back to the Active Directory Security Glossary
A domain is the Active Directory’s basic unit of organization.
Every network built around Active Directory must have at least one domain and a domain controller which authenticates access to that domain. Each domain comprises lots of objects which represent physical entities such as users, printers and servers, and organizational entities such as folders and groups.
In the beginning, everyone assumed organizations would be happy with a single domain.
This made life easy – only one domain to manage. Then networks grew in size and organizational complexity, and 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.
As with all networking, Active Directory loves its organic analogies, starting with the idea of domains, roots, trees, and forests. In fact, there is logic in this arboreal terminology. So 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.
Why run multiple forests? Usually for security reasons where separation is advantageous. This comes at the expense of increased management workload.
Over time, successive versions of Windows Server and Active Directory have added new capabilities to domains and forests, encapsulated in what are termed functional levels. Ideally, the later the functional level of a domain controller the better, for example Windows Server 2016, a version which introduced significant upgrades.
However, where some controllers are running versions prior to 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.
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? 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.
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 of servers, or hierarchical objects such as AD domains or groups. They can also be organizational 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, group memberships, and access permissions.
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 is useful when trying to check the availability of an active directory server or where the admin is bored and wants something to do.