The object model: users, computers, OUs

Goal

By the end of this session you'll know the common object types that populate an AD directory — users, computers, groups, and Organizational Units — and, most importantly, what an OU is genuinely for. The single idea to walk away with: an OU is an administrative and structural tool for delegation and Group Policy, not a way to grant access. Getting the OU-versus-group distinction straight now saves you from one of the most common beginner mistakes. Still early Tier 1 — you're organizing the directory you built in Session 2, not mastering it.

Concepts

Objects and attributes, made concrete

In Session 1 the directory store was abstract; now you have a live one in lab.local and can fill it. Everything in it is an object, and every object is an instance of a class that dictates which attributes it may hold (recall the directory-store pillar — the ntds.dit database on your DC). The classes you'll touch daily:

• user — a person's account: attributes like sAMAccountName, givenName, mail, memberOf.
• computer — a machine account (more below).
• group — a collection used to grant access to resources (the types and scopes are Session 4).
• organizationalUnit (OU) — a container you create to organize the objects above.

An object is its attributes. "Creating a user" is really "instantiating a user object and setting its attributes" — the GUI just hides that behind a wizard.

User and computer objects

A user object represents a security principal — a person (or a service identity) that can authenticate and be granted access. A computer object represents a machine that has joined the domain: it's a first-class security principal too, with its own account and password that the machine rotates automatically.

You don't create computer objects by hand in the normal case. When a Windows machine is joined to the domain (that's Session 6 — don't do it now), AD creates a computer object for it, by default in the built-in Computers container. For now, just hold the idea: a domain-joined machine gets a computer object, and you can decide where that object lands.

Containers are not OUs

Open ADUC and you'll see Users and Computers already present. These look like folders, but they are containers (object class container), not OUs. That is not a cosmetic difference — it has two concrete consequences:

• You cannot link a Group Policy Object to a default container. GPOs link to OUs (and sites and the domain), not to CN=Users or CN=Computers.
• Delegation of control is designed around OUs.

An OU (organizationalUnit) is a distinct object type that you create. Because the built-in containers can't be GPO-linked or cleanly delegated, real environments almost never leave users and computers sitting in the defaults — they build an OU structure and put objects there instead. That's exactly what tonight's lab does.

What an OU is FOR — two real purposes

An OU exists to serve two administrative jobs, and only these two are worth building your structure around:

1. Delegation of administration — you can grant a team rights over just one OU. Give the helpdesk "reset passwords on the Sales OU" without making them Domain Admins. (The deep delegation model, AGDLP, is Tier 2 — Session 13.)
2. Targeting Group Policy — you link a GPO to an OU and it applies to the objects inside it. Put all sales laptops in an OU, link a policy, done. (Group Policy itself is Session 7.)

That's it. OUs are for structure, delegation, and policy scope — an administrative filing system with teeth. Design your OU tree around how you administer and apply policy, not around the org chart for its own sake.

Structure maps straight onto naming (LDAP)

OUs aren't just a UI convenience — they're part of every object's Distinguished Name, the right-to-left path you met in Session 1. Where an object lives in the OU tree is its DN. Create a user "John Smith" directly in the domain and its DN might be:

CN=John Smith,CN=Users,DC=lab,DC=local

Move that same user into the Sales OU and the DN changes to reflect the new location:

CN=John Smith,OU=Sales,DC=lab,DC=local

Same object, same objectGUID, new path. This is why "moving" an object in ADUC is really an LDAP modify-DN operation — the directory-store and LDAP pillars showing through the GUI.

You'll do all of this in ADUC

Everything in this session happens in Active Directory Users and Computers — it's the tool to see the structure take shape, and it's where you'll work. Creating an OU is a right-click on the domain (or a parent OU) → New → Organizational Unit; creating a user is right-click on the target OU → New → User and filling the wizard; moving an object is drag-and-drop, or right-click → Move… and picking the destination OU (that's the modify-DN that rewrites the DN). Every one of these actions also has a cmdlet, but heavy bulk scripting waits for Session 8 — for now, click through it in ADUC and watch the tree.

Lab

Goal: build a small, real OU structure in lab.local and populate it, then watch an object's DN change as you move it. Everything here is done in ADUC so you can see the tree take shape; use obviously-fake names — lab.local, sample people, P@ssw0rd-lab. Never use real credentials.

Work top-down: right-click the lab.local domain → New → Organizational Unit to make Sales, IT, and Servers; then right-click each OU → New → User to add people inside it; then drag a user (or right-click → Move…) from Sales into IT and watch its Distinguished Name change.

How you know it worked: in ADUC, lab.local shows your three OUs — Sales, IT, Servers — with users sitting inside Sales and IT, and the user you moved now appears under its new OU (its DN changed accordingly). That's a directory you've organized — the structure you'll link policy to and delegate over in later sessions.

New-ADOrganizationalUnit -Name "Sales"   -Path "DC=lab,DC=local"
New-ADOrganizationalUnit -Name "IT"      -Path "DC=lab,DC=local"
New-ADOrganizationalUnit -Name "Servers" -Path "DC=lab,DC=local"
Get-ADOrganizationalUnit -Filter * | Select-Object Name, DistinguishedName