Orientation & the mental model

Goal

By the end of this session you'll carry a precise mental model of what a directory service is and the four distinct layers Active Directory is built from — plus the naming vocabulary (objects, attributes, schema, domain, and Distinguished Names) you'll lean on for the rest of the course. You'll do all of that before installing a single role. Tonight's lab only builds the VM foundation; AD itself begins in Session 2. This is the first step of Tier 1 (Competent Admin) — a foundation, not mastery.

Concepts

What a directory service is

A directory service is a specialized database optimized for read-heavy lookups of relatively static objects — users, computers, groups, printers — together with the plumbing to authenticate those identities and authorize their access to resources. Unlike a transactional RDBMS, it's hierarchical, attribute-rich, schema-governed, replicated to multiple servers, and tuned so that reads vastly outnumber writes.

It exists to solve one problem: centralized identity and resource management. Without it, every machine keeps its own local accounts and you manage identity N times. With it, there's a single authoritative source of truth — one account, one logon, central policy, and administration you can delegate. Active Directory Domain Services (AD DS) is Microsoft's implementation of that idea. It's a product, and it bundles several distinct protocols and services together — which is exactly where the mental model matters.

The four pillars — keep them separate

Beginners collapse everything into the phrase "Active Directory." The single most useful thing you can do early is keep these four concerns mentally distinct. They are different layers that people blur together:

1. Directory store — the object database itself. The actual data (users, groups, OUs and their attributes) lives here, physically in the ntds.dit database on each domain controller, organized into partitions. This is what is stored.
2. LDAP — the Lightweight Directory Access Protocol, the wire protocol used to read and write the store (search, bind, add, modify). It's a query/update protocol defined by open standards (RFC 4511), not something Microsoft invented and not unique to AD. This is how you talk to the store.
3. Authentication — proving who a principal is. In AD that's Kerberos (the primary protocol) with NTLM as a legacy fallback. Authentication is its own machinery, separate from LDAP: a successful LDAP bind may ride on top of it, but Kerberos ticketing is a different protocol with its own flow.
4. DNS — how clients find a domain controller in the first place. AD publishes the DCs and services as SRV records in DNS; a client that can't resolve those records can't locate a DC, and therefore can't bind or authenticate. AD is utterly dependent on DNS.

Why drill on this now? Because when something breaks later, the fastest triage is naming the pillar at fault: can't find a DC → DNS; bind or search fails → LDAP or permissions; can't get a ticket / repeated password prompts → Kerberos/NTLM; the object or attribute is wrong → the directory store itself. Half of AD troubleshooting is knowing which of the four you're actually looking at.

Core vocabulary

Four terms you'll use constantly:

• Object — a single entry in the directory store (a user, computer, group, or organizational unit). Every object belongs to a class that determines what it is and which attributes it may hold.
• Attribute — a named, typed property on an object: sAMAccountName, mail, memberOf, and so on. Attributes are single- or multi-valued.
• Schema — the definition of every object class and attribute that is allowed to exist, plus their rules and types. It's the "table definitions" of the directory: forest-wide, authoritative, and extensible. Nothing can exist in the store that the schema doesn't define.
• Domain — an administrative and replication boundary: a partition of the directory with its own account and security policy, holding a set of objects and served by one or more domain controllers (DCs). (Multiple domains that share a schema form a forest — that's Session 9; just park the term for now.)

Naming: Distinguished Names and CN / OU / DC

The directory is a tree, and every object has a Distinguished Name (DN) — a globally unique path from the object all the way up to the root of the tree. A DN is built from Relative Distinguished Names (RDNs) joined by commas, and it reads right-to-left: rightmost is the root, leftmost is the object itself.

Three RDN prefixes cover almost everything you'll see:

• DC= — domainComponent. Each label of the domain's DNS name becomes one DC= component. The domain lab.local becomes DC=lab,DC=local. This is the root of the tree, and it's literally where the directory ties back to DNS.
• OU= — organizationalUnit. A container you create to organize objects for structure, delegation, and policy. (You'll build these in Session 3.)
• CN= — commonName. Typically the leaf object's name — and also used for several built-in containers such as CN=Users.

Worked example — the DN for a user "John Smith" in a Sales OU of the lab.local domain:

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

Read it right-to-left to trace the path down the tree:

• DC=lab,DC=local → start at the root, the domain lab.local
• OU=Sales → descend into the Sales organizational unit
• CN=John Smith → arrive at the user object, the leaf

With the model in hand, the rest of the course is mostly making these abstractions concrete. Tonight you only build the ground to stand on: a clean Windows Server VM, no roles yet.

Lab

Goal: stand up the single Windows Server VM that carries you through Session 10 — hypervisor, evaluation ISO, install, first boot. No AD role is installed in this session. You're deliberately ending on a plain server so that in Session 2 you can watch a bare OS become a domain controller.

A couple of commands you'll run after first boot to confirm the state of the machine. Verifying the ISO hash after download (optional but good hygiene):

Get-FileHash .\WindowsServer.iso -Algorithm SHA256

Confirm which build you're on once you reach the desktop:

Get-ComputerInfo -Property WindowsProductName, OsVersion, OsHardwareAbstractionLayer

Prove the box is still a plain server — the AD DS role should report Available, not Installed:

Get-WindowsFeature -Name AD-Domain-Services

What you should see / how you know it worked: you land on the Windows Server desktop and Server Manager opens automatically; Get-ComputerInfo reports a Windows Server … Evaluation product name; and Get-WindowsFeature -Name AD-Domain-Services shows an Install State of Available. That combination is exactly the clean, role-free starting point Session 2 expects.