WSA Module 02: Active Directory & Identity

Slide 1 of 19 ← Course Overview

Active Directory & Identity

Active Directory is the central identity database for a Windows network — every user, computer, and group lives in it.

What you'll learn

  • Domain vs Workgroup — the two network models
  • AD architecture — forest, domain, OU, object
  • Domain Controllers — multi-master + FSMO roles
  • Users, Groups, OUs — identity building blocks
  • Group Policy — centralized config delivery
  • AD PowerShell ★ — create, query, automate
Where this fits: Foundation #2 of WSA. AD = 25-30% of AZ-800. AD PowerShell (★) is the automation pillar of AD itself.
Module 02 — your journey 1Workgroup vs Domain 2AD Architecture 3Domain Controllers 4OUs 5Users & Groups 6Group Policy 7Install AD DS 8Mgmt Tools 9AD PowerShell ★ → next: M03 — Storage

Domain vs Workgroup

Before diving into Active Directory, understand the two network models for Windows computers.

Workgroup

  • Peer-to-peer
  • Each PC manages its own accounts
  • No central auth, no Group Policy
  • ~20 computers max (practical)
  • Best for: home, small office

Domain

  • Centralized management
  • Single sign-on across resources
  • Central auth via AD DS
  • Scales to thousands of PCs
  • Best for: enterprise
Key: Domain users log on once and access any resource they're authorized for — no per-machine accounts.
Two ways to network Windows machines Workgroup peer to peer mesh PC1 PC2 PC3 PC4 each PC has its own users Domain centralized AD DS DC01 AD DS PC1 PC2 PC3 single sign-on across all PCs

AD DS Architecture

AD DS hierarchy. Each level enforces a different kind of separation — right panel shows the visual nesting.

Level Boundary type
Forest — top container, shared schema Security
Domain — own database, replication scope Administrative
OU — container for organizing objects Group Policy
Object — users, groups, computers (leaf)
Design AD = pick where these boundaries sit.
AD DS hierarchy: forest → tree → domain → OU Forest contoso.com Tree contoso.com us.contoso eu.contoso Sales OU users + groups IT OU users + groups Second Tree acquired.com trust to contoso.com trust Forest is the security boundary, contains one or more trees of domains

Domain Controllers

A Domain Controller (DC) runs AD DS, authenticates users (Kerberos), and replicates with other DCs.

Always deploy 2+ DCs. One DC down = nobody logs on.

FSMO — 5 single-master operations

Most AD is multi-master; these 5 need ONE authoritative DC to avoid conflicts:

  • Schema Master — schema changes (1/forest)
  • Domain Naming Master — add/remove domains (1/forest)
  • RID Master — allocates RIDs for SIDs (1/domain)
  • PDC Emulator — time, passwords, legacy (1/domain)
  • Infrastructure Master — cross-domain refs (1/domain)
Domain Controllers: multi-master replication DC01 writable copy DC02 writable copy change A change B Each DC accepts writes, syncs to others. Best practice: 2+ DCs per domain for redundancy.

Organizational Units (OUs)

OUs are containers that organize objects within a domain. Three reasons they exist: delegation (assign admin rights to specific OUs), Group Policy (link GPOs to OUs for targeted settings), organization (mirror company structure).

Typical OU structure

hexworth.local ├── Domain Controllers # built-in ├── Workstations / { IT, Finance, HR } ├── Servers / { Web, Database, File } └── Users / { Employees, Contractors, ServiceAccounts }
Keep depth to ≤5 levels. Deep nesting slows Group Policy processing and complicates management.
Organizational Units: nest, inherit, delegate corp.local [ ] Sales OU delegated to sales-admins [ ] IT OU linked GPO: SecureBaseline [ ] HR OU linked GPO: KioskLockdown [ ] Helpdesk child OU [ ] Servers child OU GPO settings inherit to child OUs SecureBaseline applies to IT OU AND Servers OU

User Accounts

User accounts are the primary identity objects in AD DS — people or services that need authentication.

Four account types

TypePurposeExample
Domain UserStandard employeejsmith@hexworth.local
ServiceRun an app/servicesvc_sqlserver
Managed Service (MSA)Auto-managed passwordMSA_WebApp$
AdminElevated IT privilegesadmin_jsmith

Four key attributes

sAMAccountName = legacy short logon · userPrincipalName (UPN) = modern email-style logon · distinguishedName (DN) = full LDAP path (e.g. CN=John,OU=Employees,DC=hexworth,DC=local) · objectSID = unique security ID.

A user account is a directory object jdoe@corp.local John Doe Sales department sAMAccountName: jdoe userPrincipalName: jdoe@corp displayName: John Doe memberOf: Sales, AllUsers passwordLastSet: 14 days ago accountEnabled: True What it can do Log on to any domain PC Access shared resources Inherit Group Policy Receive email + Teams Be a group member Have audit history

Groups in Active Directory

Groups simplify permission management — assign access to many users at once. Two types, three scopes.

Two group types

Security groups grant resource permissions (via ACLs). Distribution groups are email-only.

Three group scopes

ScopeMembersResources
Domain LocalAny domainSame domain
GlobalSame domainAny in forest
UniversalAny in forestAny in forest
AGDLP: Accounts → Global → Domain Local → Permissions.
Group scopes: AGDLP order of operations Global user accounts from this domain A = Accounts Global → DL add Global groups to Domain Local G = Global, DL = Domain Local Assign Permission give DL group access to resource P = Permission AGDLP: Accounts → Global → Domain Local → Permission Universal groups span multiple domains in the forest

Group Policy Basics

GPOs deliver centralized settings across the domain — passwords, firewall, drive mappings, software install. Right panel shows a GPO linking to an OU.

Processing order — LSDOU

Local → Site → Domain → OU (parent then child).

Last-applied wins. OU-linked GPOs override Domain-linked GPOs on conflicts.
GPO link → OU → users + computers SecureBaseline GPO settings password length: 14 lockout: 5 tries link [ ] IT OU target container in corp.local applies to user at logon password rules apply at boot firewall rules apply PC

Common GPO Settings — what you actually configure

Once your GPOs are placed correctly (slide 8), here is what you typically PUT in them. Five of the most common settings categories you will configure.

Common GPO Settings

  • Password Policy - Complexity, length, expiration
  • Account Lockout - Failed attempts, lockout duration
  • Software Deployment - Install/remove applications
  • Security Settings - Firewall, audit policies
  • Drive Mappings - Network drive connections
What you actually put inside a GPO Password Policy min 14 chars · complexity · 90d expire Account Lockout 5 fails · 30min lockout · reset 15min Software Deployment push MSI installs · auto-uninstall Security Settings firewall rules · audit policy · UAC Drive Mappings + Logon Scripts net use H: \\fs01\users\%USERNAME% on logon · ps script triggers Pick the categories first, configure values second gpedit.msc tree mirrors these categories (Computer Config + User Config)

Installing AD DS

Two-step install: install the role, then promote to DC. -IncludeManagementTools installs the GUI consoles + ActiveDirectory PowerShell module.

Step 1 — Install the AD DS role

PS C:\> Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Step 2 — Promote (first DC creates the forest)

PS C:\> Install-ADDSForest -DomainName "hexworth.local" -DomainNetBIOSName "HEXWORTH"
Promoting a server to Domain Controller 1 Install the AD DS role Install-WindowsFeature AD-Domain-Services -IncludeManagementTools 2 Promote to Domain Controller Install-ADDSForest -DomainName "corp.local" -InstallDns 3 Set DSRM password, reboot Directory Services Restore Mode credentials for safe boot Verify replication + functional level Get-ADDomainController; Get-ADForest First DC creates the forest; subsequent DCs join an existing one

Adding redundancy — additional DCs

Your first DC creates the forest. Subsequent DCs join the existing domain for redundancy and load distribution. Best practice: always run at least two DCs.

Add redundancy — join existing domain as additional DC

PS C:\> Install-ADDSDomainController -DomainName "hexworth.local"
Prerequisites: static IP · DNS pointing at itself (or an existing DC) · strong DSRM (Directory Services Restore Mode) password · Standard or Datacenter edition.
Additional DC joins existing domain → replicates DC01 (existing) corp.local FSMO roles · GC DC02 (existing) corp.local Read/Write · GC replicate DC03 (new) Install-ADDS DomainController initial sync initial sync Best practice: at least 2 DCs per domain (no single point of failure)

AD Management Tools

Five tools for managing AD objects + settings.

ToolBest for
ADUC — Users and ComputersDaily admin
ADAC — Admin Center (modern)Learning PowerShell
GPMC — Group Policy consolePolicy management
Sites & ServicesMulti-site replication
PowerShell ActiveDirectory moduleBulk + automation
Pro Tip: ADAC shows PowerShell equivalent of every GUI action.
Three primary AD management consoles ADUC Users and Computers [ ] corp.local └ Builtin └ Computers └ Sales OU ⤵ └ John Doe └ Jane Smith └ Users day-to-day user/group ops dsa.msc ADAC Admin Center Overview PS History Recycle Bin ▶ Restore deleted users Fine-grained password policies (PSO) modern admin + PS history dsac.exe Sites & Services replication topology US EU site link DC01 DC02 replication + subnets dssite.msc

Essential AD PowerShell

Load: Import-Module ActiveDirectory. Three cmdlets cover the user lifecycle:

Inspect · create · reset password

PS C:\> Get-ADUser -Identity jsmith -Properties * PS C:\> New-ADUser -Name "Jane Doe" -SamAccountName jdoe -Path "OU=Emp,DC=hexworth,DC=local" -Enabled $true PS C:\> Set-ADAccountPassword -Identity jdoe -Reset -NewPassword $sec

Params: -SamAccountName = legacy logon. -Path = OU DN. -AccountPassword needs a SecureString.

Essential ActiveDirectory module cmdlets Windows PowerShell, Import-Module ActiveDirectory PS> New-ADUser -Name "John Doe" -SamAccountName jdoe -Path "OU=Sales,DC=corp,DC=local" -Enabled $true PS> Add-ADGroupMember -Identity Sales -Members jdoe PS> Get-ADUser -Identity jdoe -Properties memberOf PS> Set-ADAccountPassword -Identity jdoe -Reset PS> Enable-ADAccount -Identity jdoe PS> New-ADGroup -Name "Sales-RW" -GroupScope DomainLocal PS> _

AD PowerShell — Groups

Group management uses the same Verb-Noun pattern. List members, add members, create new groups — all standard cmdlets from the ActiveDirectory module.

Groups

# List members · add user to group · create a new group PS C:\> Get-ADGroupMember -Identity "IT Admins" PS C:\> Add-ADGroupMember -Identity "IT Admins" -Members jdoe PS C:\> New-ADGroup -Name "ProjectX" -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=hexworth,DC=local"
Groups + their members (the relationship) IT Admins Group (DomainLocal) members jdoe amora ProjectX (nested group) PS> Get-ADGroupMember -Identity "IT Admins" jdoe User amora User ProjectX Group ← nested (use -Recursive to expand) PS> Add-ADGroupMember "IT Admins" -Members jdoe

Searching Active Directory

Filters at the server (-Filter) are much faster than client-side Where-Object. Four common patterns:

List every user in an OU

PS C:\> Get-ADUser -Filter * -SearchBase "OU=Employees,DC=hexworth,DC=local"

Find disabled or stale accounts

PS C:\> Get-ADUser -Filter {Enabled -eq $false} PS C:\> $cutoff = (Get-Date).AddDays(-90); Get-ADUser -Filter {LastLogonDate -lt $cutoff}
Get-ADUser -Filter narrows down to what you need All users 847 accounts in corp.local filter Department -eq "Sales" 42 users Sales dept only ready to act on PS> Get-ADUser -Filter {Department -eq 'Sales'} -Properties Department, Office PS> Get-ADUser -LDAPFilter "(department=Sales)" for power-users: native LDAP query syntax

Searching AD — wildcards, recursion, LDAP

Beyond exact matches: wildcards for naming conventions, recursive enumeration for nested groups, and native LDAP syntax for advanced queries.

Wildcard match on names

PS C:\> Get-ADComputer -Filter {Name -like "WKS-*"}

Recursive group membership (nested groups too)

PS C:\> Get-ADGroupMember -Identity "Domain Admins" -Recursive
-Filter vs -LDAPFilter: same speed. -Filter {Dept -eq 'Sales'} = PowerShell-style (default). -LDAPFilter "(department=Sales)" = native LDAP, for docs queries.
Three advanced search shapes Wildcard Name -like "WKS-*" WKS-001 WKS-042 WKS-187 ... name patterns Recursive -Recursive Domain Admins └ IT Mgrs (group) └ jsmith (user) LDAP native -LDAPFilter "(department =Sales)" for ops Filter doesn't support PS> Get-ADComputer -Filter {Name -like "WKS-*"} PS> Get-ADGroupMember -Identity "Domain Admins" -Recursive PS> Get-ADUser -LDAPFilter "(department=Sales)" Wildcard = pattern · Recursive = walks nested groups · LDAP = native query

Common Admin Tasks

Four everyday admin tasks. Each uses cmdlets you already know.

Unlock a locked-out user

PS C:\> Unlock-ADAccount -Identity jsmith

Move a user to a different OU

PS C:\> Move-ADObject -Identity "CN=John Smith,OU=Contractors,DC=hexworth,DC=local" -TargetPath "OU=Employees,DC=hexworth,DC=local"
A day in the life of an AD admin Onboard new hire (user + groups) Reset locked-out passwords Add/remove group memberships Disable accounts (offboarding) Audit stale accounts (90+ days) Verify DC replication health Automate the repeating CSV onboarding Import-Csv hires.csv | ForEach { New-ADUser ... } Find stale users Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 Replication report repadmin /replsummary

Common Admin Tasks — bulk operations

Two patterns scale admin work from one-at-a-time to one-command-for-many: CSV-driven user creation and pipeline-chained group operations.

Bulk create users from CSV

PS C:\> Import-Csv "C:\newusers.csv" | ForEach-Object { New-ADUser -Name $_.Name -SamAccountName $_.Username -Path "OU=Employees,DC=hexworth,DC=local" }

Pipeline-chain a group operation

PS C:\> Get-ADUser -Filter * -SearchBase "OU=IT,DC=hexworth,DC=local" | Add-ADGroupMember -Identity "IT Staff"
Always test first! Add -WhatIf to any bulk command to preview the changes without applying them.
One pipeline → many users hires.csv Name,User,Dept Mora,fmora,IT Smith,jsmith,HR Reyes,mreyes,Sales | ForEach-Object { New-ADUser -Name $_.Name ... } fmora @ IT jsmith @ HR mreyes @ Sales Pipeline-chain alternative Get-ADUser -Filter * -SearchBase "OU=IT" | Add-ADGroupMember "IT Staff" walks query result, applies op to each — no for-loop Always preview with -WhatIf first | ForEach { New-ADUser ... -WhatIf } → see what WOULD happen, no writes

Module Summary — what you're carrying forward

You can now do

  • Stand up an AD forest + add redundancy DCs
  • Create users/groups/OUs by hand and in bulk
  • Search AD with server-side filters

In your toolkit

  • Get/New/Set-ADUser · Add-ADGroupMember
  • Install-ADDSForest · Install-ADDSDomainController
  • forest · domain · OU · DC · FSMO · GPO · UPN · SID

Up next — m03 Storage

GUI Lab → PowerShell Lab → Take Quiz Back to Course
What you carry forward — four feelings Empowered You can stand up an AD forest from scratch Confident You know WHY a domain beats a workgroup at scale Equipped ActiveDirectory PS module · ADUC · Filter syntax Curious m03 stores it; m08 names it; m10 controls it Carry these forward into m03 (Storage) and beyond
GUI Lab PS Lab Quiz