FFoundationalActive Directory
Active Directory Objects and Schema
Every user, computer, and group in Active Directory is an object defined by a shared blueprint called the schema. This lesson explains what objects and attributes actually are, how the schema and global catalog make the directory searchable forest-wide, and how replication keeps every domain controller in sync.
Why it matters
Almost every technique you will explain in an AD assessment ultimately touches an object: a user account gets compromised, a computer account gets abused for delegation, a group gets added to for persistence. If you cannot explain what an AD object actually is, you cannot precisely describe what an attacker changed or accessed. The schema and global catalog also explain two things people take for granted without understanding: why every domain controller seems to know about every object, and why a query against one domain controller can return results that live in a completely different domain. Getting this right is what separates "I found some accounts" from a defensible technical explanation of what was queried, modified, or exposed.
Key Concepts
- Object — a single entry in the AD database, such as a user, computer, or group; every object has a unique distinguishedName, a globally unique objectGUID, and a set of attributes defined by its object class
- Schema — the forest-wide blueprint that defines every object class and every attribute that can exist in the directory; changing it requires Schema Admin rights and affects every domain in the forest
- Object class — a schema definition that specifies what an object of that type is and which attributes it must or may hold, for example the user class requires sAMAccountName and allows attributes like memberOf
- Attribute — a single named property on an object, such as sAMAccountName or pwdLastSet; the schema defines each attribute's syntax (string, integer, timestamp) and whether it holds one value or many
- Global catalog (GC) — a forest-wide, partial-attribute index held on designated domain controllers that lets a query find an object anywhere in the forest without knowing which domain it lives in
- Multi-master replication — the process by which every domain controller in a domain holds a full, writable copy of the directory and propagates changes to the others, so there is no single point of write failure
Theory
Core idea
Active Directory does not store loose files or free-form records. Every user, computer, group, printer, and Group Policy Object is stored as an object, and every object is an instance of an object class defined in the schema. The schema is the rulebook: it says what classes of objects can exist (user, computer, group, organizationalUnit, and dozens more) and what attributes each class can or must carry. A user object, for example, must have a sAMAccountName and can optionally hold attributes like mail, memberOf, or pwdLastSet.
Two other pieces make this system usable at scale. The global catalog is a partial, forest-wide index: designated domain controllers hold a subset of attributes for every object in every domain in the forest, so a search does not need to know in advance which domain holds the answer. Replication is what keeps every domain controller's copy of the directory current: any domain controller can accept a write, and that change propagates to every other domain controller in the domain through a multi-master replication process.
Mental model
Think of the schema as a database table definition that happens to apply across an entire forest at once. If "user" is a table, the schema says which columns exist (attributes) and what type of data each column holds (syntax: text, number, timestamp, binary). Every actual user account is a row in that table, which is exactly what an object is: a specific instance with real values filled into the attributes the schema allows.
Now picture that table definition being identical on every domain controller in every domain of the forest, because the schema is a forest-wide singleton, not a per-domain setting. Each domain controller keeps its own full copy of the objects that belong to its domain (the "rows" for its table), and replication is the mechanism that keeps every domain controller's copy of those rows consistent with every other domain controller's copy. When an administrator changes a password or adds a group member on one domain controller, that write has to travel outward until every other domain controller has the same value.
The global catalog solves a different problem: search across domains. Without it, finding "which domain has a user named jsmith" would mean asking every domain individually. The global catalog keeps a thin, read-only index (a handful of commonly searched attributes, not the full object) covering every object in the whole forest, hosted on specific domain controllers designated as global catalog servers. A search against the global catalog can answer "does this object exist and roughly what does it look like" forest-wide, even though the full, writable copy of that object still lives on domain controllers in its own domain.
Common misunderstandings
- Treating the schema as a per-domain setting. The schema is defined once for the entire forest. A single set of Schema Admins controls it, and a schema change (adding a new attribute, for instance) applies everywhere, not just in the domain where the change was made. This is exactly why schema modification rights are so tightly guarded.
- Confusing the global catalog with "the whole directory." The global catalog only holds a subset of attributes for each object, chosen because they are commonly searched (like email address or SAM account name), not the complete object. To read or modify the full object, including sensitive attributes not replicated to the GC, you still need to reach a domain controller that is authoritative for that object's domain.
- Assuming one domain controller is "the" source of truth. AD uses multi-master replication: any domain controller can accept a write. There is no single controller whose copy is more authoritative than another's for domain data (this is different from operations-master roles, which handle a small set of forest-wide or domain-wide operations that must not happen in two places at once). Ordinary object changes replicate outward from wherever the write happened.
- Assuming attributes are all plain text. The schema assigns a strict syntax to every attribute: some are strings, some are integers, some are timestamps, some are binary security descriptors. This is why tools that query AD parse specific attributes in specific ways; the schema, not the query tool, defines the data type.
Real-world context
During enumeration, almost every piece of information you pull back is shaped by the schema. When you see pwdLastSet, lastLogonTimestamp, or servicePrincipalName on a user object, those are schema-defined attributes with specific meanings and specific syntaxes, not arbitrary metadata. Knowing that a service account is identified by having a populated servicePrincipalName attribute, for instance, is what makes Kerberoasting-style enumeration precise rather than guesswork.
Global catalog awareness also matters operationally. A query aimed at a global catalog port (3268/3269) versus a standard LDAP port (389/636) can return very different results in a multi-domain forest, because one searches forest-wide with a partial attribute set and the other searches a single domain with the full attribute set. Understanding which one a tool is using explains why a search might miss an attribute you expected to see, or why it finds an object a domain-scoped query would have missed entirely.
Replication matters when timing questions come up. If you observe a change (a new group membership, a modified attribute) on one domain controller, that change may take a short time to appear on every other domain controller. This replication lag is a normal, expected property of the system, not a sign that something is broken or hidden, and it is worth being able to explain that distinction clearly when a client asks why two domain controllers briefly disagreed.
Communication
Interview answer
Active Directory stores everything, users, computers, groups, as objects, and every object is an instance of an object class defined by the schema. The schema is a forest-wide blueprint: it defines what classes of objects can exist and what attributes each class can hold, including each attribute's data type. Because the schema is forest-wide, a schema change made anywhere affects every domain in the forest, which is why schema modification is tightly restricted.
Two supporting pieces make the directory usable at scale. The global catalog holds a partial set of attributes for every object across the entire forest, so searches do not need to know in advance which domain an object lives in. Replication is the multi-master process that keeps every domain controller's copy of the directory synchronized; any domain controller can accept a write, and that change propagates outward to the rest of the domain. Together, these three pieces (objects, schema, global catalog, replication) are what let a directory with millions of objects stay consistent and searchable across an entire enterprise network.
Follow-up questions
- What is the difference between an object's full attribute set and what the global catalog stores for that object?
- Why does a schema change require forest-wide caution instead of being scoped to one domain?
- If a domain has multiple domain controllers, which one holds the "real" copy of an object?
- How would you explain replication lag to a stakeholder who is worried two domain controllers show different data?
- What does it mean for an attribute to have a defined syntax, and why does that matter when parsing AD data?
