The ADUC Structure After the First DC Deployment

You promote your first domain controller, log in, open Active Directory Users and Computers for the first time, and stare at a small tree of folders. Some are familiar — Users, Computers. Some are obscure — ForeignSecurityPrincipals, NTDS Quotas. Toggle View > Advanced Features and even more folders appear. This post walks through every default container and OU you see at first boot, what each one is for, and the under-the-hood detail that most cheat-sheets skip.

Active Directory Users and Computers [DC.smart.local]

The top line of the tree is not a folder at all — it is the snap-in itself, displaying the name of the DC it is currently connected to. ADUC opens against the DC you are logged into by default, but you can right-click the line and choose Change Domain Controller if you want to view or edit objects on a specific DC (useful when chasing replication issues). The DC name in the title is what tells you which one you are looking at.

Saved Queries

An empty folder when you first open ADUC. It stores custom LDAP queries you author, scoped however you like — “all users that have not logged in for 90 days,” “all computers with operating system starting with Server,” “all enabled users in OU X with a manager attribute populated.” Once saved, they appear under this node and re-run on demand. Almost no one uses this feature, which is a shame because it is genuinely useful for daily AD hygiene.

The domain root (smart.local)

The next node is the actual domain root — in this lab, smart.local. Everything underneath belongs to the domain. You can right-click here to change FSMO operations masters, raise the domain functional level, or delegate domain-wide rights. It is also where every default container and the single default OU live.

The containers vs OUs distinction — the load-bearing detail

Before listing the children, the most important concept: most of what you see under smart.local is a container, not an OU. They look identical in the ADUC tree, but they behave very differently:

• Container. Holds objects. You cannot link a Group Policy Object to it. You cannot delegate control via the standard ADUC wizard. It is a built-in AD object type that the system created at domain promotion and the system manages.
• OU (Organizational Unit). Holds objects, accepts linked GPOs, and supports the Delegation of Control wizard. You create these yourself.

The difference matters because Group Policy is the primary way you enforce settings on AD-managed objects, and you can only link policies at the site, domain, and OU level — not at the container level. That is why the default Users and Computers containers cannot be the long-term home for actual users and computers in any environment with meaningful policy.

What is an OU on the default tree?

Exactly one container in the default tree is an OU: Domain Controllers. Everything else is a container. The Default Domain Controllers Policy is linked to that OU, which is how the security baseline for DCs gets applied.

Builtin

A container holding the built-in security groups that ship with AD: Administrators, Backup Operators, Account Operators, Print Operators, Server Operators, Users, Guests, Replicator, and several others. These groups have well-known SIDs — S-1-5-32-544 for Administrators, for example — that are identical in every AD forest in the world. You cannot delete them, you cannot move them out of Builtin, and you cannot change their names. You can add members.

The right pattern when delegating built-in rights: create a custom AD group, add it as a member of the relevant Builtin group, then manage memberships of your custom group. This is the AGDLP pattern (Account → Global → Domain Local → Permission) applied to OS-level rights.

Computers

A container, and the default landing place for any computer that joins the domain without first being prestaged. This is the single most common source of “why is my new server applying client policies” in poorly-organized domains. Computers in this container receive no GPO from the OU layer because the container does not accept linked GPOs — but they do receive any policy linked at the domain level or filtered to all authenticated computers.

The standard remediation is one of two things: prestage every machine into its proper OU before joining (covered in Prestaging Computer Accounts), or redirect the default Computers container to an OU you control using redircmp. The latter command takes a single argument — the DN of your replacement OU — and points the system at it permanently:

redircmp "OU=Workstations-Inbound,DC=smart,DC=local"

Domain Controllers

The one and only default OU. Every DC’s computer account lands here automatically at promotion. The Default Domain Controllers Policy is linked here at create time, providing the security baseline for DCs (audit policy, user rights assignment, password policy specific to interactive logon on DCs). You can add more GPOs to harden further (CIS DC baseline, Microsoft Security Compliance Toolkit), and you can move DC accounts out of this OU — but you should not. Microsoft assumes DC accounts live here, and some replication and authentication-time logic checks specifically for it.

ForeignSecurityPrincipals (advanced)

Visible only with View > Advanced Features on. This container holds proxy objects for security principals from other trusted domains or forests. When you add a user from fun.local to a group in smart.local across a trust, AD creates a foreign-security-principal proxy here, named after the foreign SID, that the local group can reference. Most labs and small domains have this container empty because no trusts exist.

If you ever audit a domain and find unexpected entries in here that you cannot identify, that is a finding worth investigating — it can indicate forgotten cross-forest trusts or stale principals from decommissioned domains.

Keys (advanced)

Storage for the AD-backed BitLocker recovery keys, and for keys deposited by other Windows features that use AD as a backing store. Empty at first; populates as you turn on BitLocker on domain-joined machines with BitLocker recovery-information backup to AD enabled. Each key object is tied to a specific computer account and contains the recovery password and the unique identifier needed to unlock that machine.

LostAndFound (advanced)

The AD equivalent of /lost+found on a Unix filesystem. If an OU is deleted while it still contains objects, and the deletion happens concurrently with a replication conflict (so one DC sees the OU gone while another DC saw new objects added to it just before), those orphaned objects end up here so they are not silently lost. Usually empty. If anything is in here, somebody made a mistake worth investigating.

Managed Service Accounts (advanced)

Holds Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs). These are the modern-era service accounts whose passwords AD rotates automatically — you never type a password into a service’s logon credentials again. New gMSAs land here by default unless you place them elsewhere. Empty at first; populates as you create gMSAs for services like SQL, IIS app pools, scheduled tasks running across servers.

Program Data (advanced)

A container for applications that extend AD and need a place to store their configuration. Rarely populated unless you have installed something that uses it — Certificate Services creates objects here, Active Directory Rights Management Services uses it, some third-party identity-bridging products write to it. Empty in fresh domains. Leave it alone.

System (advanced)

The container that holds AD’s internal configuration. The DNS-integrated zones live here. The default policies (Default Domain Policy, Default Domain Controllers Policy) are referenced from here. The Computers and Users default-container redirection (the redircmp /redirusr targets) is stored here. The RID Manager$ object — the one the RID Master writes to — lives here. The Schema Master and Domain Naming Master reference objects sit here.

You do not edit System manually. Microsoft has clear documentation on which sub-containers you should and should not touch, and the right answer for an admin is almost always “leave it alone.” The one exception is when troubleshooting AD-integrated DNS zones, where you may need to look at the zone objects under CN=MicrosoftDNS,CN=System,DC=....

Users

A container, not an OU, holding the default Administrator account, the disabled Guest account, the built-in DefaultAccount, and the well-known groups Domain Admins, Enterprise Admins, Schema Admins, Domain Users, Domain Computers, Group Policy Creator Owners, and a handful of others. By default any new user created from the command line without specifying an OU lands here, just like Computers does for new machine accounts.

Same remediation pattern as Computers: redirect with redirusr to an OU you control, then manage future user creation under that OU instead:

redirusr "OU=Users-Inbound,DC=smart,DC=local"

NTDS Quotas (advanced)

Stores per-principal quotas limiting how many objects a given user or group is allowed to create in a partition. This is rarely used. The interesting case is preventing a delegated helpdesk account from accidentally creating millions of objects through a runaway script. Most environments do not configure quotas and the container stays empty.

TPM Devices (advanced)

Stores TPM ownership information for computer accounts that have escrowed their TPM owner authorization to AD. Populated as TPM-equipped machines join the domain and the relevant Group Policy is enabled. Most environments do not bother and this stays empty.

Basic view vs Advanced view recap

Eleven default top-level items in total, of which exactly one is an OU.

Things that bite people

Trying to link a GPO to Users or Computers

You cannot. The container is not OU. There is no Group Policy tab in their properties. The right move is to create a real OU, redirect new accounts there with redirusr / redircmp, and link your GPOs to the new OU.

Moving DC accounts out of Domain Controllers

Just do not. Microsoft assumes DCs live in this OU. Several internal AD processes look up DC accounts by their location, and breaking that assumption causes hard-to-diagnose replication and authentication issues. If you want a different policy for some DCs — perhaps quieter DCs in branch offices vs the busy ones at HQ — use WMI filtering or item-level targeting inside the OU.

Deleting a custom OU with objects inside

If you have ever seen LostAndFound populated, this is usually the cause. ADUC asks for confirmation when you delete an OU containing objects, but the confirmation is easy to click past. The fix is to enable the AD Recycle Bin so deleted objects can be restored, and to delegate the “delete OU” right narrowly. (See enabling the AD Recycle Bin.)

Editing System container objects

Almost guaranteed to break something. The configuration in here is referenced by AD’s own code paths in ways that are not documented for end users. If you genuinely need to make a change — for example, fixing an orphaned DNS zone object — use ADSI Edit, take a system-state backup first, and follow a Microsoft-documented procedure.

Foreign principals you cannot identify

If ForeignSecurityPrincipals has entries that you cannot match to a current trust, the entries are usually stale — left over from a previously-removed forest trust. They are inert (no current trust = no authentication path) but they clutter and confuse audits. You can safely delete them once you confirm the relevant trust no longer exists.

What’s next

The next post in the Active Directory pathway is adding a child domain to an existing forest — the step-by-step walkthrough of building a child domain controller under an existing root, configuring DNS, and verifying the parent-child trust. That is the most common scenario where the ADUC tree you just learned suddenly has a sibling-tree to coordinate with.