Active Directory

Imagine a company with 500 employees and 500 computers. Without Active Directory, every time someone new joins, IT would have to physically visit every machine to create their account. When someone leaves, visit every machine again to remove it. Passwords couldn't be enforced centrally. It would be unmanageable.

Think of it like a building's badge system. Instead of every room having its own lock and key, one central security system controls every door. Your badge determines exactly which doors open for you.

Active Directory lives on a server called a Domain Controller (DC). When you type your password at a work computer, the computer doesn't check its own records — it asks the Domain Controller, which says "yes, this person is valid" or "no, they're not."

Everything belongs to a domain — like company.com or school.local. All computers, users, and printers are registered in that domain.

Active Directory organizes everything hierarchically. From the bottom up:

OBJECTS — the individual things AD manages An object is any single "thing" in AD: a user account, a computer account, a printer, a security group. Each has attributes (properties). A user object has: first name, last name, email, department, manager, and a hashed password.

ORGANIZATIONAL UNITS (OUs) — folders for objects OUs are containers that hold objects — like folders on your desktop. You might create an OU called "Sales" holding all Sales user accounts, and another called "Engineering" for that department. OUs can contain other OUs.

Why OUs matter: Group Policy Objects (GPOs) attach to OUs. When you link a policy to an OU, every user and computer inside that OU gets that policy automatically. This is the connection between Active Directory and Group Policy.

DOMAIN — the whole organization The domain is the top-level container. Everything — all OUs, all objects — lives inside it. The domain has a name like "company.com" or "corp.local."

FOREST — multiple connected domains Large organizations sometimes connect multiple domains into a "forest." Most small-to-medium companies have just one domain. As a beginner, focus on the single-domain scenario.

Example structure: acme.local (domain) Employees (OU) Engineering (OU) jsmith (user object) DESKTOP-001 (computer object) Sales (OU) mjones (user object)

When you sit down at a work computer and type your password, a specific process happens. Understanding it helps you troubleshoot when logins fail.

Step 1: The computer asks DNS "where is the Domain Controller?" Before anything else, your computer needs to find the server running AD. It does this through DNS. This is why DNS is so critical — if DNS is wrong or broken, login fails before it even starts. This is the number one cause of domain-join failures and login problems.

Step 2: Credentials are sent to the Domain Controller Your computer sends your username and password hash to the DC using Kerberos — the authentication protocol AD uses.

Step 3: The DC checks Active Directory Is the account enabled? Is the password correct? Is it locked out? Is it expired?

Step 4: The DC issues a "ticket" If valid, the DC gives your computer a Kerberos Ticket Granting Ticket (TGT). Think of it like a wristband at an event — it proves you paid, so you can access things without showing your payment again.

Step 5: Your desktop loads Group Policies apply. Drive mappings connect. Your profile loads. You see your desktop.

Troubleshooting logic: if login fails, trace the chain. DNS broken? Can't find DC. Account locked? DC rejects login. Computer not joined to domain? No DC communication possible.

USER ACCOUNTS Every person gets a unique User Account with a username, password, and Security Identifier (SID). The SID is what Windows actually uses internally — even if you rename an account, the SID stays the same forever.

GROUPS — managing permissions at scale Problem: 200 Sales people all need access to the Sales file server. Assigning each person individually means 200 entries to manage.

Solution: create one Security Group called "Sales-Staff." Give that group access to the file server. Now just manage group membership — add someone to the group, they get access. Remove them, access gone.

The AGDLP pattern (you'll see this referenced constantly): Accounts go into Global groups → Global groups go into Domain Local groups → Domain Local groups get Permissions assigned to them. This keeps large environments clean and scalable.

These are the things you'll do constantly. Learn these first.

CREATING A USER ACCOUNT Open Active Directory Users and Computers (ADUC): Start > Windows Administrative Tools > Active Directory Users and Computers. Right-click the correct OU > New > User. Fill in: First name, Last name, User logon name. Set a temporary password. Check "User must change password at next logon." Click Finish. Then right-click the new account > Add to a Group > add relevant security groups.

RESETTING A PASSWORD Right-click the user in ADUC > Reset Password. Enter a temporary password. Check "User must change password at next logon." This is one of the most common help desk tasks you will do.

UNLOCKING AN ACCOUNT When someone enters their password wrong too many times, the account locks out. Right-click user > Properties > Account tab. Check "Unlock account." Or via PowerShell: Unlock-ADAccount -Identity username

DISABLING vs DELETING When someone leaves: DISABLE first, never delete immediately. A deleted account loses its group memberships and all associated data. Legal may require records preserved. Disable, wait until clearance is given, then delete. Right-click user > Disable Account.

It's Monday morning. A new employee, Sarah Johnson, starts in the Marketing department. She needs to log in and access the Marketing file share.

Step 1 — Open ADUC Start > Windows Administrative Tools > Active Directory Users and Computers

Step 2 — Navigate to the right OU Expand your domain in the left panel. Find the OU for Marketing (Employees > Marketing). This ensures Sarah automatically gets the Marketing Group Policies.

Step 3 — Create the account Right-click the Marketing OU > New > User First name: Sarah, Last name: Johnson, Logon name: sjohnson Click Next. Set a temporary password. Check "User must change password at next logon." Click Next > Finish.

Step 4 — Add to groups Right-click sjohnson > Add to a group > type "Marketing-Staff" > Check Names > OK This grants her access to the Marketing file share (the group already has those permissions configured).

Step 5 — Verify Double-click her account > Properties. Check: Account tab: no expiration, not disabled Member Of tab: Marketing-Staff is listed General tab: name is correct

When Sarah sits down, logs in with her temporary password, and changes it — Active Directory handles the rest automatically.

A user calls saying they can't log in. Work through this checklist — never guess.

Question 1: What error are they seeing? "The username or password is incorrect" → wrong password OR locked account "Your account has been disabled" → account is disabled in AD Spinning logo, no error → might be a computer/network problem, not an AD problem

Question 2: Check the account in ADUC Find the user. Right-click > Properties > Account tab. Is "Account is locked out" checked? → unlock it Has the account expired? → extend expiration Are there logon hour restrictions?

Is the account disabled? (downward arrow on the icon) Right-click > Enable Account.

Question 3: If ADUC looks fine, check Event Viewer on the DC Windows Logs > Security > filter for Event ID 4625 (failed logon). The event includes a Failure Reason code: 0xC000006A = wrong password 0xC0000234 = account locked out 0xC0000072 = account disabled 0xC000006F = outside allowed logon hours

Understanding the hierarchical structure of Active Directory at depth is what separates administrators who can work in it from those who can design and troubleshoot it.

THE FOREST — THE TOP OF EVERYTHING The forest is the complete Active Directory instance. It contains all domains, shares a common schema (the definition of every possible object and attribute), and has a single global catalog. Every object in the entire forest shares one schema — you cannot have different attribute definitions for users in different domains in the same forest.

The forest root domain should typically be a "placeholder" domain not used for everyday user accounts. This isolates these all-powerful groups from the daily operational activity.

FOREST FUNCTIONAL LEVEL Determines which Active Directory features are available across the entire forest. Governed by the oldest Domain Controller version in any domain in the forest. To use Windows Server 2016 forest features, every DC in every domain must be at least Windows Server 2016. You cannot raise the functional level above the oldest DC.

Modern twist: Starting from Windows Server 2019, there are NO new forest or domain functional levels. The Windows Server 2016 functional level is the latest and applies to 2019 and 2022 as well.

TRUST RELATIONSHIPS By default, all domains within the same forest automatically have two-way transitive trusts between them. This means any user in any domain can potentially access resources in any other domain (subject to permissions). You don't configure this — it's automatic.

Transitive: if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A also trusts Domain C — without an explicit trust.

Cross-forest trusts: between separate forests, trusts must be manually created. They can be one-way or two-way, and by default are NOT transitive.

External trusts: with older pre-2000 Windows NT domains or with specific non-forest domains.

Active Directory uses a multi-master model — any Domain Controller can accept changes to the AD database and they replicate to each other. But five specific operations are too sensitive for multi-master mode. These are handled by exactly one DC at a time, called FSMO (Flexible Single Master Operation) roles.

WHY FSMO ROLES EXIST: Some operations must happen in one place only. If two DCs simultaneously assigned the same unique ID to different objects, you'd have a collision. If two DCs simultaneously modified the schema, you'd have conflicts. FSMO roles solve this by designating one DC as the authority for each critical operation.

THE FIVE FSMO ROLES:

FOREST-LEVEL ROLES (one per forest):

DOMAIN-LEVEL ROLES (one per domain):

CHECKING ALL FSMO ROLES AT ONCE: netdom query fsmo

TRANSFERRING vs SEIZING: Transfer = graceful move when both DCs are online. Use: Move-ADDirectoryServerOperationMasterRole Seize = forceful takeover when the original holder is dead and can't be recovered. Use: Move-ADDirectoryServerOperationMasterRole ... -Force After seizing, NEVER bring the old DC back online — you'd have two DCs claiming the same role.

Of all the technologies that underpin Active Directory, DNS is the most critical. Active Directory is built on DNS. Without a healthy DNS infrastructure, Active Directory fails.

WHY AD IS COMPLETELY DEPENDENT ON DNS: When a domain-joined computer starts up and needs to find a Domain Controller, it doesn't have a static list of DC addresses. Instead, it queries DNS for special service records (SRV records) that Active Directory publishes. These records tell clients exactly which servers are Domain Controllers and which services they offer.

The query looks like: _ldap._tcp.company.com The DNS answer points to the DC's IP address.

If these records are missing or wrong, specific AD functions break. This is why "check DNS" is the first step in almost every AD troubleshooting scenario.

Primary/Secondary Zones: Traditional DNS zones where one server holds the master copy and others hold read-only copies. Less optimal for AD environments but sometimes needed for integration with non-Microsoft DNS.

COMMON DNS PROBLEMS IN AD: Problem: Machine gets APIPA address (169.254.x.x) → No DHCP → Machine has no valid IP → Can't find DC → DNS irrelevant, fix DHCP first.

Problem: Machine has valid IP but can't join domain → Run: nslookup domain.com → If this fails, DNS is pointing to the wrong server. The DNS server on a domain-joined machine MUST be the DC's IP, not the internet router.

Problem: Machine joined domain but GPOs not applying → DNS might be returning stale records → Run: ipconfig /flushdns → Force re-lookup.

SPLIT DNS (SPLIT BRAIN DNS): When your AD domain name matches your public internet domain (company.com), you need different DNS answers depending on who's asking. Internal computers should resolve company.com to the internal DC. Internet users should resolve company.com to the public web server. Split DNS maintains two separate zones with the same name — one internal (authoritative for internal resources), one external (authoritative for public resources). Setup mistake here causes login failures or inability to browse your own website from inside.

Active Directory is the most critical system in most organizations. If an attacker gains Domain Admin access, they effectively own the entire organization. Understanding how attacks happen — and what controls prevent them — is essential knowledge.

THE AD TIER MODEL — DEFENSE IN DEPTH FOR IDENTITY: The biggest AD security mistake is using the same admin account for everything. If an admin uses their Domain Admin credentials to fix a user's computer (which might be compromised), those credentials can be stolen from memory.

The tier model creates isolation:

Tier 0 — Domain Controllers, Schema, Enterprise Admin Only Tier 0 accounts should ever touch Tier 0 systems. A compromised Tier 0 account means full domain compromise.

Tier 1 — Servers and Applications Server admins use Tier 1 accounts to manage servers. Tier 1 accounts should NEVER be used on workstations. If a workstation is compromised, Tier 1 credentials shouldn't be there to steal.

Tier 2 — Workstations and End Users Helpdesk and desktop support use Tier 2 accounts. These accounts should never have any server or DC access.

The rule: accounts only flow downward (an admin can use higher-tier credentials on lower-tier systems) but never upward (you should never put domain admin credentials on a workstation).

COMMON ATTACKS ON ACTIVE DIRECTORY:

Pass-the-Hash (PTH) Windows caches NTLM password hashes in memory (in the LSASS process). If an attacker gets code running on a machine as admin, they can extract these hashes and use them to authenticate as the user on other systems — without knowing the actual password. The hash IS the password for NTLM. Defense: Protected Users security group (disables NTLM for members), Credential Guard (virtualizes LSASS), tiered admin model.

Golden Ticket Attack If an attacker steals the KRBTGT account's password hash (the special account that signs all Kerberos tickets), they can forge any Kerberos ticket for any user, for any service, for as long as they want. This is called a Golden Ticket — self-signed, completely valid, grants any access. Defense: Rotate the KRBTGT password twice (immediately and again 10 hours later), monitor for unusual Kerberos ticket lifetimes.

DCSync Attack AD Domain Controllers sync their AD database by requesting changes from each other using the Directory Replication Service (DRS) protocol. If an attacker has accounts with replication rights, they can impersonate a DC and request a copy of the entire AD database — including all password hashes. All credentials in the entire domain are now compromised. Defense: Limit who has replication rights. Monitor for accounts attempting DRS requests that aren't actual DCs (Microsoft Defender for Identity detects this).

Kerberoasting Any domain user can request a Kerberos service ticket for any service in the domain. Service tickets are encrypted with the service account's password hash. Offline, an attacker can brute-force that encrypted ticket to recover the password. Only service accounts registered with SPNs are vulnerable. Defense: Use complex, long (25+ character) passwords for service accounts. Better: use Managed Service Accounts (MSA) or Group Managed Service Accounts (gMSA) which have 240-character auto-rotating passwords that can't be Kerberoasted.

AS-REP Roasting Kerberos pre-authentication requires users to prove they know their password before the DC will issue them a TGT. Some accounts have "do not require Kerberos preauthentication" enabled. For these accounts, anyone can request a TGT encrypted with the user's password hash and crack it offline. Defense: Never disable Kerberos pre-authentication unless absolutely required.

LAPS — LOCAL ADMINISTRATOR PASSWORD SOLUTION: By default, if you image computers from the same golden image, they all have the same local administrator password. If an attacker compromises one machine and knows the local admin password, they can use it on every machine in the organization (lateral movement).

LAPS solves this by automatically generating a unique, random password for each computer's local Administrator account, storing it securely in Active Directory, and rotating it on a schedule. IT admins can retrieve a specific machine's local admin password from AD when needed, but there's no single password that works everywhere.

MDI provides the "Assume Breach" capability that the Zero Trust model requires — even if an attacker is inside, MDI detects their behavior and alerts.

PowerShell is the primary management tool for Active Directory in enterprise environments. The GUI tools are useful for single operations, but PowerShell is how you manage AD at scale, automate tasks, and troubleshoot quickly.

GETTING STARTED — THE AD MODULE: The Active Directory PowerShell module is installed automatically with the RSAT tools or with the AD DS role. Import it with: Import-Module ActiveDirectory Or just run any AD cmdlet — it auto-imports in modern PowerShell.

ESSENTIAL USER MANAGEMENT COMMANDS:

Finding users: Get-ADUser -Identity jsmith Get-ADUser -Filter {Department -eq "Finance"} -Properties Department,Manager Get-ADUser -Filter * -SearchBase "OU=Sales,DC=company,DC=com" Get-ADUser -Filter {PasswordExpired -eq $true} | Select Name,SamAccountName

Creating users: New-ADUser -Name "Jane Smith" -GivenName "Jane" -Surname "Smith" -SamAccountName "jsmith" -UserPrincipalName "jsmith@company.com" -Path "OU=Marketing,DC=company,DC=com" -AccountPassword (Read-Host -AsSecureString "Password") -Enabled $true

Modifying users: Set-ADUser -Identity jsmith -Department "Marketing" -Manager "mmanager" Enable-ADAccount -Identity jsmith Disable-ADAccount -Identity jsmith Unlock-ADAccount -Identity jsmith Set-ADAccountPassword -Identity jsmith -NewPassword (Read-Host -AsSecureString "New password") -Reset

Finding locked accounts (essential for help desk): Search-ADAccount -LockedOut | Select Name, SamAccountName, LockedOut

Finding accounts that will expire soon: Search-ADAccount -AccountExpiring -TimeSpan 7.00:00:00 | Select Name, AccountExpirationDate

ESSENTIAL GROUP MANAGEMENT:

Get-ADGroupMember -Identity "IT-Admins" | Select Name Add-ADGroupMember -Identity "Marketing-Staff" -Members jsmith,bwilson Remove-ADGroupMember -Identity "Sales-Staff" -Members jsmith -Confirm:$false Get-ADPrincipalGroupMembership -Identity jsmith | Select Name

ESSENTIAL COMPUTER MANAGEMENT:

Get-ADComputer -Filter * -Properties OperatingSystem | Where-Object {$_.OperatingSystem -like "*Windows 10*"} | Select Name, OperatingSystem Get-ADComputer -Filter {LastLogonDate -lt (Get-Date).AddDays(-90)} | Select Name, LastLogonDate

FSMO ROLE COMMANDS: Get-ADDomain | Select PDCEmulator, RIDMaster, InfrastructureMaster Get-ADForest | Select SchemaMaster, DomainNamingMaster netdom query fsmo (command prompt) Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator, RIDMaster

CHECKING REPLICATION HEALTH: repadmin /replsummary — Summary of replication status across all DCs repadmin /showrepl — Detailed replication status dcdiag /test:replications — Comprehensive DC health check including replication

BULK OPERATIONS — WHERE POWERSHELL SHINES: # Disable all users in the Terminated OU Get-ADUser -Filter * -SearchBase "OU=Terminated,DC=company,DC=com" | Disable-ADAccount

# Export all users and their group memberships to CSV Get-ADUser -Filter * -Properties MemberOf | Select Name, SamAccountName, @{Name='Groups';Expression={($_.MemberOf | Get-ADGroup | Select -ExpandProperty Name) -join ";"}} | Export-Csv "ADExport.csv" -NoTypeInformation

# Find all users whose passwords never expire (security risk) Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires | Select Name, SamAccountName

In a multi-location organization, Active Directory needs to understand your organization's actual physical network layout to make smart decisions about authentication and replication — that's what Sites and Subnets are for.

WHY AD NEEDS TO KNOW ABOUT YOUR PHYSICAL NETWORK: Without site awareness, a user at a branch office could end up authenticating against a Domain Controller located across a slow WAN link at headquarters, when a local DC sitting right down the hall would have handled the request instantly. Sites tell AD which Domain Controllers are physically close to which subnets, so clients preferentially authenticate against the nearest one.

SITES — REPRESENTING PHYSICAL LOCATIONS: An AD Site is a logical object representing a physical location — typically one office, one data center, or one well-connected group of locations. Sites don't need to match your domain or OU structure at all; a single domain can span many sites, and a single site can host DCs from multiple domains in a multi-domain forest.

SUBNETS — LINKING IP RANGES TO SITES: Subnet objects associate specific IP address ranges with a specific Site — when a client authenticates, AD checks which subnet the client's IP falls into, determines which Site that maps to, and directs the client toward a Domain Controller in that same Site whenever one is available.

SITE LINKS — DEFINING HOW SITES CONNECT AND REPLICATE: A Site Link represents the actual network connection between two Sites, and carries a configured cost value and replication schedule. Cost lets you tell AD "prefer this path over that one" when multiple routes exist between sites — a direct link between two sites might have a low cost, while a path routing through a third site would have a higher cumulative cost, so AD prefers the more direct connection.

WHY REPLICATION SCHEDULING MATTERS FOR SITE LINKS: Replicating every single AD change instantly across a slow, expensive WAN link to a remote site can consume meaningful bandwidth. Site Links let you configure how frequently replication happens between specific sites — potentially less frequently for a distant branch office on a limited connection, versus near-continuous replication between two well-connected sites in the same metro area.

THE KNOWLEDGE CONSISTENCY CHECKER (KCC): AD doesn't require you to manually wire up every single replication path between every DC — a built-in process called the Knowledge Consistency Checker automatically generates and maintains an efficient replication topology based on your defined sites, subnets, and site links, adjusting automatically as DCs are added, removed, or as connectivity changes.

WHY POORLY CONFIGURED SITES CAUSE REAL, CONFUSING PROBLEMS: A branch office subnet that was never associated with a Site object will fall back to essentially random DC selection, potentially routing every single login attempt across a slow WAN link — producing exactly the kind of confusing, inconsistent "login is slow sometimes" complaints that are genuinely hard to diagnose unless you specifically think to check site/subnet configuration.

DFS NAMESPACE AND SITE AWARENESS: Beyond authentication, site configuration also influences how site-aware services like DFS Namespaces (covered in this platform's Networking topic) route users toward the nearest available file server replica, rather than potentially routing them to a distant server purely by chance.

THE PRACTICAL TAKEAWAY: Getting Sites and Subnets configured correctly is one of those foundational pieces of AD infrastructure that's invisible when it's working correctly, and a genuine source of confusing, hard-to-diagnose performance complaints when it's not — worth verifying early whenever a new office location or subnet gets added to the network.

Unlike some directory services with a single authoritative master, Active Directory uses multi-master replication — every Domain Controller can accept writes, and changes propagate outward to every other DC. Understanding how this actually works helps you troubleshoot replication problems and understand AD's genuine resilience.

WHY MULTI-MASTER, RATHER THAN A SINGLE MASTER DC: A single-master design would mean if that one master DC went down, no changes could be made anywhere in the domain until it was restored — a serious single point of failure. Multi-master lets any DC accept a write (a password change, a new user, a group membership update), genuinely improving both resilience and performance, since users aren't forced to reach one specific DC for every write operation.

USN — UPDATE SEQUENCE NUMBERS: Each DC maintains its own Update Sequence Number, incrementing with every local change. When DCs replicate, they compare USNs to determine exactly which changes the other DC hasn't seen yet, replicating only the genuinely new changes rather than re-sending the entire directory database every single time.

HIGH-WATERMARK VECTORS AND UP-TO-DATENESS VECTORS: DCs track high-watermark values (the highest USN received from a specific replication partner) and up-to-dateness vectors (tracking the highest USN originated by every DC in the domain, not just direct replication partners) — together, these let a DC know precisely what it's missing without needing to compare its entire database against every other DC's entire database on every single replication cycle.

CONFLICT RESOLUTION — WHAT HAPPENS WHEN THE SAME OBJECT CHANGES ON TWO DCs SIMULTANEOUSLY: Since any DC can accept writes, it's genuinely possible for the same object to be modified on two different DCs before they've had a chance to replicate with each other. AD resolves this using a combination of timestamp comparison and a deterministic tie-breaking mechanism — the change with the later timestamp generally wins, with a consistent tie-breaker (based on the originating DC's unique identifier) for the rare case of a genuine simultaneous, identically-timestamped conflict.

LINGERING OBJECTS — A GENUINE, IF RARE, REPLICATION HAZARD: If a DC is disconnected from the network for longer than the tombstone lifetime (the period during which deleted objects are retained before permanent removal, 180 days by default in modern AD), and an object was deleted domain-wide during that disconnection, that DC can reintroduce a "lingering object" once reconnected — an object that should have been deleted, resurrected because the deleting DC's disconnected partner never received the deletion notification in time.

REPAIRING LINGERING OBJECTS: Modern AD includes built-in strict replication consistency checking that can detect and prevent lingering object reintroduction automatically, though understanding the underlying mechanism helps explain why extended DC outages genuinely warrant real concern beyond simple availability, and why the tombstone lifetime setting matters as a genuine operational parameter, not just an obscure technical detail.

REPADMIN — THE PRIMARY REPLICATION DIAGNOSTIC TOOL: repadmin /replsummary provides a quick overview of replication health across every DC in the domain. repadmin /showrepl shows detailed replication partner and status information for a specific DC. These commands are genuinely the first tools to reach for when replication-related problems are suspected — objects not appearing consistently across DCs, or DCs reporting stale directory information.

WHY UNDERSTANDING REPLICATION MECHANICS MATTERS PRACTICALLY: When a genuinely confusing symptom appears — a user created on one DC isn't visible when querying a different DC, a group membership change hasn't taken effect everywhere — understanding USNs, replication partners, and normal replication latency helps you correctly distinguish "this is just normal replication delay, wait a few minutes" from "something is genuinely broken and needs real troubleshooting."

Not every AD administrative task requires full Domain Admin rights — Delegation of Control lets you grant specific, narrowly-scoped permissions over specific OUs to specific users or groups, directly applying the least-privilege principle covered throughout this platform to AD's own permission structure.

WHY DELEGATION MATTERS BEYOND JUST CONVENIENCE: Without delegation, any task requiring elevated AD permissions — resetting a password, creating a new user account, managing group membership for one specific department — would require either a full Domain Admin's involvement, or granting Domain Admin rights far more broadly than genuinely necessary. Neither option is genuinely appropriate: the first doesn't scale, and the second creates real, unnecessary security risk from over-privileged accounts.

THE DELEGATION OF CONTROL WIZARD: Active Directory Users and Computers provides a built-in wizard for delegating specific, common administrative tasks to a specific user or group, scoped to a specific OU — reset passwords, create/delete user accounts, manage group membership, modify specific object attributes — without needing to manually configure the underlying Access Control Lists by hand.

COMMON DELEGATION SCENARIOS IN REAL ORGANIZATIONS: A help desk team delegated password reset rights, scoped to just the OUs containing the specific users they actually support — genuinely useful for the extremely common "user forgot their password" ticket, without granting help desk staff any broader administrative capability. A department's own IT liaison delegated rights to manage group membership for that specific department's own security groups — letting genuinely routine, department-specific administrative work happen without central IT's direct involvement for every single request. A specific application team delegated rights to create and manage service accounts within a designated OU, supporting their own application's specific needs without broader domain-wide access.

UNDERSTANDING THE UNDERLYING ACCESS CONTROL LISTS: Behind the wizard's friendly interface, delegation ultimately configures Access Control Entries on the target OU (or specific objects within it), defining exactly which security principal can perform exactly which specific actions. Understanding this underlying mechanism helps when troubleshooting a delegation that doesn't seem to be working as expected, or when you need genuinely custom delegation beyond what the standard wizard's predefined common tasks cover.

INHERITANCE AND DELEGATION SCOPE: Delegated permissions typically apply to the OU they're configured on AND any child OUs beneath it by default (through standard AD permission inheritance), meaning careful OU structure design directly affects how cleanly delegation can actually be scoped — a well-organized OU hierarchy makes delegation genuinely clean and precise; a poorly organized one can force overly broad delegation just to reach the specific objects that actually need it.

AUDITING DELEGATED PERMISSIONS OVER TIME: Delegation, once granted, doesn't automatically expire or get reviewed — a genuinely mature AD administration practice includes periodically auditing exactly what's currently delegated to whom, confirming those grants still genuinely match current actual job responsibilities, directly connecting to the periodic access review concepts covered in this platform's OpCon and Security Fundamentals topics.

WHY OVER-DELEGATION IS A REAL, GENUINE RISK: Just as with any other access grant, delegating overly broad rights "just to be safe" or "to avoid future tickets" creates real risk — a compromised help desk account with delegated rights scoped tightly to password resets for one specific department is a meaningfully smaller security incident than the same compromised account holding broader, poorly-scoped delegated rights across the entire domain.

THE PRACTICAL TAKEAWAY: Delegation of Control is what makes it genuinely practical to run AD administration at real organizational scale without either bottlenecking every single routine task through a small central admin team, or handing out excessive Domain Admin rights purely for convenience — the same fundamental tradeoff between operational efficiency and least-privilege security that shows up throughout every system covered on this platform.

Active Directory holds an organization's entire identity infrastructure — losing it without a proper recovery path would mean rebuilding every single user account, group, and permission structure from scratch. Understanding AD-specific backup and recovery mechanisms is genuinely critical operational knowledge.

SYSTEM STATE BACKUP — WHAT ACTUALLY NEEDS TO BE BACKED UP: A standard file-level backup of a Domain Controller doesn't properly capture Active Directory's actual database and related components — a proper AD backup requires a System State backup specifically, which captures the AD database (NTDS.dit), the SYSVOL folder (containing Group Policy templates and scripts), the Registry, and several other genuinely critical system components together as one coherent, consistent unit.

WHY A CONSISTENT SYSTEM STATE BACKUP MATTERS SO MUCH: Simply copying the NTDS.dit database file directly while AD is actively running risks capturing it in a genuinely inconsistent state, mid-write — a proper System State backup uses the Volume Shadow Copy Service to capture a consistent, coherent snapshot of all these interrelated components together, avoiding this genuine data integrity risk.

THE AD RECYCLE BIN — RECOVERING DELETED OBJECTS WITHOUT A FULL RESTORE: Modern AD includes a built-in AD Recycle Bin feature (which needs to be explicitly enabled, since it's off by default) that lets administrators recover an accidentally deleted user, group, or other object — along with its original attributes and group memberships — directly, without needing to perform a full, disruptive authoritative restore from backup for what might be a single accidentally deleted account.

TOMBSTONE LIFETIME AND THE RECYCLE BIN'S RECOVERY WINDOW: Even with the Recycle Bin enabled, recovery is only possible within the tombstone lifetime window (180 days by default) — beyond that window, the deleted object's data is permanently purged and can only be recovered from an actual backup, if a sufficiently old backup genuinely exists.

AUTHORITATIVE VS. NON-AUTHORITATIVE RESTORE — A GENUINELY IMPORTANT DISTINCTION: A non-authoritative restore brings a specific DC back from backup, then lets normal replication catch it up with changes from other DCs since that backup was taken — appropriate when you're simply recovering a failed DC, and other healthy DCs still hold the current, correct directory state. An authoritative restore instead marks specific restored objects as authoritative, forcing that restored version to REPLACE the current version across every other DC during replication — necessary specifically when the actual object itself (not just one DC) needs to be reverted, like recovering an entire deleted OU that's already been removed from every DC.

WHY GETTING THIS DISTINCTION WRONG CAUSES REAL PROBLEMS: Performing a non-authoritative restore when you actually needed an authoritative one means the restored DC simply gets updated by replication to match the same (still-wrong) state as every other DC — the recovery effectively accomplishes nothing, since normal replication just overwrites your restored data with the same problematic state you were trying to fix in the first place.

NTDSUTIL — THE COMMAND-LINE TOOL FOR AUTHORITATIVE RESTORE OPERATIONS: Performing an authoritative restore requires booting into Directory Services Restore Mode and using the ntdsutil command-line tool to explicitly mark specific objects (or an entire subtree) as authoritative before allowing normal replication to resume — a genuinely deliberate, careful process, not something to improvise for the first time during an actual live crisis.

TESTING AD RESTORE PROCEDURES — THE SAME PRINCIPLE APPLIED HERE: As emphasized throughout this platform regarding backup testing generally, an AD backup that's never actually been test-restored provides meaningfully less real confidence than one that's been periodically, deliberately verified — given how central AD is to virtually every other system depending on it, this testing discipline matters especially acutely here.

WHY MULTIPLE DCs DON'T ELIMINATE THE NEED FOR PROPER BACKUPS: Having multiple Domain Controllers protects against a single DC hardware failure through normal replication — but it doesn't protect against a genuine logical corruption or accidental deletion that replicates OUT to every DC before anyone notices, or against a genuinely catastrophic event affecting every DC simultaneously. Proper System State backups remain essential even in a multi-DC environment, specifically for these scenarios that simple DC redundancy alone doesn't address.

For branch offices or other locations with limited physical security or IT oversight, a standard writable Domain Controller can represent genuine risk if physically compromised — Read-Only Domain Controllers provide a meaningfully safer alternative for exactly these scenarios.

WHY A STANDARD DC AT A LOW-SECURITY LOCATION IS A GENUINE RISK: A standard Domain Controller holds a full, writable copy of the AD database, including password hashes for every user in the domain (or at least the relevant portion, depending on configuration). If that DC is physically stolen or compromised at a branch office with genuinely limited physical security oversight — no dedicated server room, less rigorous access control — an attacker with sufficient time and technical skill could potentially extract genuinely sensitive credential information.

WHAT MAKES AN RODC GENUINELY DIFFERENT: An RODC holds a read-only copy of the AD database — no changes can be made directly on an RODC itself; all writes must go to a writable DC elsewhere and replicate down to the RODC afterward. This significantly limits what an attacker who compromises an RODC could actually accomplish, since they can't use it to push malicious changes out to the rest of the domain.

PASSWORD REPLICATION POLICY — CONTROLLING WHICH CREDENTIALS ACTUALLY CACHE LOCALLY: By default, an RODC doesn't cache any user's password hash at all — it forwards every authentication request back to a writable DC. Administrators can configure a Password Replication Policy defining specifically which users' credentials are permitted to actually cache locally on that specific RODC (typically limited to just the users who actually, regularly work at that specific branch location), meaningfully limiting the genuine impact if that specific RODC is ever compromised, since only a defined, limited subset of credentials were ever cached there in the first place.

ADMINISTRATOR ROLE SEPARATION: RODCs support delegating local administrative rights over just that specific RODC to a local, non-domain-admin staff member at the branch location — letting them handle routine local maintenance (patching, basic troubleshooting) without that local admin actually holding genuine domain-wide administrative rights at all.

WHY RODCs SUIT BRANCH OFFICES SPECIFICALLY: A branch office genuinely benefits from having local authentication available (rather than every login needing to cross a WAN link to a distant writable DC), while the RODC's inherent limitations meaningfully reduce the real security exposure if that specific location's physical security genuinely can't match a proper, centrally-managed data center's standards.

RODCS AND GROUP POLICY: Since Group Policy templates live in SYSVOL, and RODCs hold a read-only replica of SYSVOL too, Group Policy application works normally for clients authenticating against an RODC — the read-only limitation specifically affects the AD database itself, not a branch location's ability to receive and apply normal Group Policy settings.

DEPLOYMENT CONSIDERATIONS — RODCs AREN'T APPROPRIATE EVERYWHERE: RODCs genuinely make sense specifically for locations with real physical security concerns and limited local IT oversight — deploying one at a well-secured primary data center, where a standard writable DC's full capability is both needed and appropriately protected, wouldn't provide any genuine meaningful benefit and would just add unnecessary complexity.

MONITORING RODC PASSWORD CACHING: Periodically reviewing which specific credentials have actually cached on a given RODC (using tools like Active Directory Users and Computers' built-in reporting, or dedicated PowerShell cmdlets) helps confirm the Password Replication Policy is genuinely working as intended, and hasn't inadvertently cached credentials for users who don't actually, regularly work at that specific branch location.

THE PRACTICAL TAKEAWAY: RODCs represent a genuinely thoughtful, deliberate security tradeoff specifically designed for a real, common scenario — local authentication performance at a location where full DC capability and full credential exposure risk genuinely isn't appropriate or justified.

ADFS extends an organization's on-premise Active Directory identity out to external applications and services, directly connecting to the broader federation and SSO concepts covered in this platform's Security+ topic — this lesson focuses specifically on ADFS as Microsoft's own on-premise implementation of these concepts.

WHY ADFS EXISTS — THE PROBLEM IT SOLVES: An organization's employees have their identity managed in on-premise Active Directory, but increasingly need to access external, cloud-hosted applications (SaaS tools, partner portals) that AD alone can't directly authenticate against, since these external services genuinely aren't part of the organization's own internal network or domain.

HOW ADFS ACTUALLY WORKS, CONCEPTUALLY: When a user attempts to access a federated external application, they're redirected to their organization's own ADFS server for authentication (since ADFS trusts on-premise AD as its identity source). Once ADFS confirms the user's identity, it issues a signed security token (commonly using SAML, covered in this platform's Security+ topic) that the external application trusts, based on a pre-established federation trust relationship between the organization and that external service.

THE CLAIMS-BASED IDENTITY MODEL: Rather than an external application needing direct access to query AD itself, ADFS issues "claims" — specific pieces of verified information about the authenticated user (their email address, their group memberships, their department) — that the external application can trust and use to make its own authorization decisions, without ever needing direct access to the organization's actual internal AD infrastructure at all.

RELYING PARTY TRUSTS: Each external application or service that trusts ADFS for authentication is configured as a "Relying Party Trust," defining exactly what claims ADFS will send that specific application, and under what specific conditions. This lets an organization precisely control exactly what identity information gets shared with each individual external service, rather than exposing broad, undifferentiated AD access to everything uniformly.

CLAIM RULES — TRANSFORMING AD ATTRIBUTES INTO OUTBOUND CLAIMS: Claim rules define specifically how AD attributes get transformed into the actual claims sent to a relying party — perhaps mapping AD's group membership into a specific role claim a particular application actually expects and understands, since different external applications often expect identity information in slightly different specific formats.

ADFS PROXY SERVERS — HANDLING EXTERNAL, INTERNET-FACING AUTHENTICATION REQUESTS: Since ADFS needs to be reachable by users authenticating from outside the organization's internal network, but the actual ADFS server itself typically shouldn't be directly exposed to the internet, an ADFS proxy (or Web Application Proxy) sits in a DMZ, forwarding legitimate authentication requests through to the actual internal ADFS server — directly applying the DMZ/screened subnet architecture concepts covered in this platform's Network+ topic.

WHY ORGANIZATIONS INCREASINGLY MOVE FROM ADFS TOWARD AZURE AD: While ADFS remains genuinely deployed in many existing environments, many organizations have increasingly migrated toward Azure AD (Entra ID) as their primary federation and identity provider instead, since it eliminates the need to maintain and secure on-premise ADFS infrastructure directly — though understanding ADFS concepts remains genuinely valuable, both for organizations still running it and because the underlying claims-based federation concepts transfer directly to understanding cloud-based identity providers as well.

ADFS HIGH AVAILABILITY: Given ADFS becomes a genuinely critical piece of infrastructure once external applications depend on it for authentication, deploying multiple ADFS servers behind a load balancer (directly connecting to the high availability and load balancing concepts covered in this platform's Network+ topic) is standard practice for any genuinely production ADFS deployment, avoiding a single ADFS server becoming a critical single point of failure for external application access.

WHY THIS MATTERS FOR AN AD-FOCUSED CAREER: Even organizations still primarily on-premise increasingly need at least some federated access to external services, and understanding how ADFS extends AD's identity outward — rather than AD existing purely as an isolated internal system — reflects the genuine, ongoing reality of how most real organizations' identity infrastructure actually works today.

Service accounts — accounts used by applications and services rather than human users — need careful handling, and Active Directory's Managed Service Account features solve real, longstanding problems with how service account credentials have traditionally been managed.

WHY TRADITIONAL SERVICE ACCOUNTS CAUSE GENUINE, RECURRING PROBLEMS: A traditional service account is just a regular user account, with a password that needs to be manually set, manually remembered, and manually rotated periodically — in practice, service account passwords are notoriously often set once and then never actually changed again, since rotating them requires updating the password in every single place the service account is configured, a genuinely tedious, error-prone, easily-forgotten manual process.

STANDALONE MANAGED SERVICE ACCOUNTS (sMSA) — THE FIRST GENERATION SOLUTION: Introduced to solve the password rotation problem, a standalone Managed Service Account has AD automatically manage and periodically rotate its own password, with genuinely no human ever needing to know or manually handle that password at all. The significant limitation: an sMSA can only be used on a single specific computer, genuinely limiting its usefulness for services running across multiple servers.

GROUP MANAGED SERVICE ACCOUNTS (gMSA) — THE MODERN, PREFERRED SOLUTION: A gMSA solves the sMSA's single-computer limitation, supporting use across multiple servers simultaneously — genuinely appropriate for a service running on a cluster or server farm, where the exact same managed identity needs to be usable consistently across several different machines.

HOW gMSA PASSWORD MANAGEMENT ACTUALLY WORKS: AD automatically generates and periodically rotates a genuinely complex password for the gMSA (by default, every 30 days), and any authorized computer account can retrieve the current password directly and automatically when needed — no human ever manually handles, types, or even necessarily knows this password at all, eliminating the entire category of "someone wrote the service account password in a sticky note or an unencrypted text file" risk that plagued traditional service account management.

CONFIGURING WHICH COMPUTERS CAN ACTUALLY USE A gMSA: A gMSA is explicitly configured with a defined list of computer accounts (or a security group containing them) that are authorized to retrieve and use its managed password — directly applying least-privilege principles to service account usage, ensuring only the genuinely intended servers can actually use a given gMSA's identity.

KDS ROOT KEY — THE UNDERLYING CRYPTOGRAPHIC FOUNDATION: gMSA password generation relies on a Key Distribution Services root key, which needs to be created once per forest before gMSAs can actually be deployed — a one-time setup step genuinely worth knowing about, since attempting to create a gMSA without this prerequisite in place will simply fail with an error that isn't always immediately obvious about the actual underlying cause.

WHY MIGRATING FROM TRADITIONAL SERVICE ACCOUNTS TO gMSA IS GENUINELY WORTHWHILE: Beyond eliminating manual password rotation entirely, gMSAs also can't be used interactively (someone can't accidentally, or maliciously, log in directly using a gMSA's identity the way they genuinely could with a traditional service account that has a known, static password) — a meaningful additional security improvement beyond just the password management convenience alone.

APPLICATION COMPATIBILITY CONSIDERATIONS: Not every application genuinely supports gMSA authentication cleanly — some older or more specialized applications may still require a traditional service account with a manually managed, static password. Understanding gMSA's genuine benefits helps make the case for migrating supported applications toward this modern approach, while recognizing some legacy applications may genuinely require traditional service account management to remain in place for the foreseeable future.

THE PRACTICAL TAKEAWAY: Service account password rotation was a genuinely persistent, real operational and security gap in traditional AD environments for years — gMSA represents a meaningful, concrete improvement worth actively pursuing wherever the applications involved genuinely support it, directly connecting to the broader credential management and least-privilege themes covered throughout this platform.

Beyond reactive troubleshooting when something's already visibly broken, proactive AD health monitoring catches developing problems before they cause a genuine, disruptive outage — Active Directory provides several dedicated diagnostic tools specifically for this purpose.

DCDIAG — THE PRIMARY OVERALL DC HEALTH CHECK TOOL: dcdiag runs a comprehensive suite of tests against a Domain Controller, checking connectivity, replication, DNS registration, the various FSMO roles, SYSVOL health, and several other critical components — genuinely the first tool to reach for when you want a broad, general health assessment of a specific DC, or when troubleshooting a DC that's exhibiting genuinely unclear, non-specific symptoms.

RUNNING DCDIAG EFFECTIVELY: dcdiag /v provides verbose output with meaningfully more diagnostic detail than the default summary view. dcdiag /test:dns specifically focuses testing on DNS-related health, genuinely useful given how critically AD depends on properly functioning DNS (covered in this platform's dedicated AD-DNS lesson). Running dcdiag periodically, proactively, rather than purely reactively only after a problem is already reported, helps catch developing issues before they cause a genuine, visible outage.

REPADMIN — REPLICATION-SPECIFIC DIAGNOSTICS: As introduced in this topic's multi-master replication lesson, repadmin focuses specifically on replication health — repadmin /replsummary provides a genuinely quick, useful overview across every DC, immediately highlighting any DCs with replication errors or unusually high replication latency needing further, deeper investigation.

EVENT VIEWER — DIRECTORY SERVICE AND DNS SERVER LOGS: Beyond the general System and Application logs covered elsewhere on this platform, Domain Controllers maintain a dedicated Directory Service log specifically for AD-related events, and a separate DNS Server log if that specific DC is also running the DNS Server role — genuinely worth actively, periodically monitoring rather than only checking reactively after a problem has already surfaced elsewhere.

MONITORING SYSVOL REPLICATION HEALTH SPECIFICALLY: Since Group Policy templates and scripts live in SYSVOL, genuine SYSVOL replication problems can cause Group Policy to apply inconsistently across different DCs — dcdiag's SYSVOL-related tests, combined with directly checking File Replication Service or DFS Replication event logs (depending on which specific underlying replication technology your particular AD environment uses), help catch this specific class of problem.

MONITORING FSMO ROLE HOLDER AVAILABILITY: As covered in this topic's dedicated FSMO Roles lesson, certain critical AD operations genuinely depend on specific FSMO role holders being reachable and healthy — proactive monitoring should specifically confirm each FSMO role holder is genuinely online and responsive, not simply assume this remains true indefinitely without any active verification.

THIRD-PARTY AND ENTERPRISE MONITORING SOLUTIONS: Beyond these built-in Microsoft tools, many organizations deploy dedicated enterprise monitoring solutions (some purpose-built specifically for AD health, others more general-purpose infrastructure monitoring platforms configured with AD-specific checks) providing centralized dashboards, automated alerting, and genuine historical trending — directly connecting to the fleet-wide monitoring and reporting concepts covered in this platform's Endpoint Management and OpCon topics, just applied here specifically to AD infrastructure health.

WHY PROACTIVE MONITORING GENUINELY MATTERS MORE FOR AD THAN FOR MANY OTHER SYSTEMS: Given how many other systems and services genuinely depend on AD functioning correctly — every domain login, Group Policy application, DNS resolution for domain-joined machines, and often broader application authentication too — a developing AD health problem that goes unnoticed can eventually cascade into a genuinely widespread, organization-affecting outage, making proactive monitoring here especially valuable compared to a more isolated, narrowly-scoped system.

BUILDING A REGULAR AD HEALTH CHECK ROUTINE: A genuinely mature AD administration practice includes a regular, deliberate cadence of running dcdiag and repadmin across every DC (whether manually on a defined schedule, or automated through a scheduled task or a dedicated monitoring platform), rather than these diagnostic tools only ever being reached for reactively, after a problem has already become visible and disruptive to actual users.

Traditionally, AD supported only a single password policy per domain — but Fine-Grained Password Policies let different groups of users have genuinely different password requirements within the exact same domain, addressing a real, common organizational need.

WHY A SINGLE DOMAIN-WIDE PASSWORD POLICY OFTEN GENUINELY FALLS SHORT: Different user populations often have genuinely different, legitimate security requirements — IT administrators and executives handling especially sensitive information might reasonably warrant stricter password requirements than general staff, while service accounts might need entirely different rules altogether (like exemption from interactive lockout policies, since a locked-out service account can cause a genuinely disruptive application outage rather than simply inconveniencing one individual user).

HOW FINE-GRAINED PASSWORD POLICIES ACTUALLY WORK: Rather than modifying the single domain-wide Default Domain Policy, Fine-Grained Password Policies are defined as separate Password Settings Objects (PSOs), each with their own specific password and lockout settings, and then explicitly applied to specific users or, more commonly, specific security groups.

PRECEDENCE — WHAT HAPPENS WHEN MULTIPLE PSOs COULD APPLY TO THE SAME USER: If a user happens to be a member of multiple groups that each have a different PSO applied, AD uses a precedence value (a lower number wins) to determine which single PSO actually, genuinely takes effect for that specific user — only ever one PSO applies at a time per user, never a blended combination of multiple PSOs' individual settings.

WHAT A PSO CAN ACTUALLY CONTROL: Minimum password length, password complexity requirements, password history (how many previous passwords are remembered and blocked from reuse), maximum and minimum password age, and account lockout threshold and duration — genuinely the same broad category of settings covered by the standard Default Domain Policy, just scoped to apply differently to different specific defined groups.

COMMON REAL-WORLD USE CASES: A stricter policy applied specifically to a Domain Admins or IT Staff security group, reflecting the genuinely higher stakes if one of these especially privileged accounts were compromised. A more relaxed lockout policy (or genuine lockout exemption entirely) applied to service accounts, since a locked-out service account typically causes a disruptive application or automation failure, rather than simply, harmlessly inconveniencing one individual human user who can just try again. A policy specifically for external contractors or temporary staff, perhaps with a shorter maximum password age reflecting their genuinely temporary access duration.

MANAGING PSOs — THE MODERN, PREFERRED APPROACH: While PSOs can technically be created and managed through ADSI Edit (a low-level, genuinely riskier direct AD editing tool), the Active Directory Administrative Center provides a meaningfully friendlier, safer graphical interface specifically for creating and managing Fine-Grained Password Policies, genuinely the recommended approach for most day-to-day administrative work rather than direct low-level editing.

WHY FINE-GRAINED PASSWORD POLICIES CONNECT TO BROADER SECURITY THINKING: This feature directly reflects the same risk-based, differentiated security thinking covered in this platform's Security Fundamentals and Security+ topics — recognizing that different user populations and different account types genuinely warrant different levels of security control, rather than applying one uniform policy indiscriminately across an entire organization regardless of each specific account's genuinely different actual risk profile.

TROUBLESHOOTING A USER'S PASSWORD REQUIREMENTS THAT SEEM DIFFERENT FROM EXPECTED: When a specific user's actual password requirements don't seem to genuinely match what the Default Domain Policy would suggest, checking whether a Fine-Grained Password Policy is actually being applied to them (through group membership) — and, if multiple PSOs could genuinely apply, checking precedence to determine which one is actually winning — is exactly the kind of troubleshooting step worth knowing to specifically check for.

THE PRACTICAL TAKEAWAY: Fine-Grained Password Policies solve a genuine, common real-world limitation of AD's original single-domain-wide-policy design, letting organizations apply meaningfully differentiated, risk-appropriate password requirements without needing to split genuinely different user populations into entirely separate domains just to achieve different password rules.

While a single domain suits many organizations perfectly well, some genuinely need multiple domains or even multiple forests — understanding when this added complexity is actually justified, versus when it's genuinely unnecessary overhead, is important architectural judgment.

WHY MOST ORGANIZATIONS SHOULD GENUINELY START WITH A SINGLE DOMAIN: A single domain is meaningfully simpler to administer, troubleshoot, and understand than a multi-domain structure — Microsoft's own long-standing general guidance has consistently been to avoid unnecessary domain complexity unless there's a genuinely specific, well-justified reason requiring it, since additional domains add real, ongoing administrative overhead without necessarily providing proportional genuine benefit.

LEGITIMATE REASONS FOR MULTIPLE DOMAINS WITHIN THE SAME FOREST: Genuinely distinct, legally separate business units requiring administratively separate boundaries, even while still sharing common forest-wide resources. Significantly different password or security policy requirements at the domain level that genuinely can't be adequately addressed through Fine-Grained Password Policies alone (covered in the previous lesson). Extremely large user populations where domain-level partitioning genuinely provides meaningful, real operational or performance benefit. Distinct geographic or regulatory boundaries requiring genuinely separate administrative control, even while remaining part of the same overall organizational forest.

THE FOREST AS THE ULTIMATE SECURITY BOUNDARY: As covered in this platform's existing AD Architecture lesson, the forest — not the individual domain — represents AD's actual ultimate security boundary. Domains within the same forest share the forest-wide schema and Global Catalog, and by default trust each other automatically through transitive trust relationships. If you genuinely need a hard, uncompromising security boundary between two organizational units, a separate forest (not merely a separate domain within the same shared forest) is what actually provides that genuine level of isolation.

WHEN MULTIPLE FORESTS ARE GENUINELY JUSTIFIED: Mergers and acquisitions, where two genuinely separate organizations with their own pre-existing AD infrastructure need to coexist, at least temporarily, before any full consolidation. Extranet scenarios requiring genuinely strict isolation from a business partner's own separate AD infrastructure. Highly regulated environments requiring absolute, uncompromising administrative and security separation between genuinely distinct organizational units, where even domain-level separation within a shared forest wouldn't provide sufficiently strong isolation.

FOREST TRUSTS — CONNECTING SEPARATE FORESTS WHEN NEEDED: When two genuinely separate forests need users to access resources across that forest boundary, a forest trust can be established — but unlike the automatic, transitive trust between domains within the same forest, a forest trust is a deliberate, explicit configuration decision, and can be scoped (through selective authentication) to control precisely which specific users are actually permitted to access which specific resources across that forest boundary, rather than blanket, unrestricted cross-forest access.

THE GENUINE ADMINISTRATIVE COST OF ADDITIONAL COMPLEXITY: Every additional domain or forest genuinely means more Domain Controllers to maintain, more replication topology to design and monitor, more trust relationships to understand and secure, and genuinely more opportunity for misconfiguration. This real administrative cost is precisely why the general guidance leans toward simplicity unless a specific, well-justified business or technical requirement genuinely demands additional complexity.

CONSOLIDATION — WHY ORGANIZATIONS SOMETIMES MOVE FROM MULTIPLE DOMAINS BACK TO ONE: Organizations that historically built out unnecessarily complex multi-domain structures (sometimes for reasons that genuinely made sense at the time, but that no longer apply, or that were simply never well-justified in the first place) sometimes undertake domain consolidation projects, migrating toward a genuinely simpler single-domain structure — recognizing accumulated unnecessary complexity as real, ongoing administrative burden worth actively reducing.

THE PRACTICAL TAKEAWAY: Multi-domain and multi-forest AD design decisions should be driven by genuine, specific business or security requirements — not by default habit, and not purely out of an abstract desire for extra isolation "just in case," since every additional domain or forest boundary adds genuine, ongoing administrative complexity that needs to be actively, continuously justified against the real benefit it actually provides.

Most organizations today run in a hybrid identity model — on-premise Active Directory continuing to manage traditional internal resources, while Azure AD (Entra ID) extends that same identity out to Microsoft 365 and other cloud services. Understanding how these two systems actually connect is genuinely essential modern AD knowledge.

WHY HYBRID IDENTITY, RATHER THAN A CLEAN CUTOVER TO PURELY CLOUD-BASED IDENTITY: Most established organizations have genuinely significant existing investment in on-premise AD-integrated infrastructure — file servers, printers, legacy line-of-business applications — that would be genuinely disruptive and costly to migrate away from entirely. Hybrid identity lets organizations adopt cloud services like Microsoft 365 while continuing to leverage their existing on-premise AD investment, rather than forcing an all-or-nothing choice between the two.

ENTRA CONNECT (FORMERLY AZURE AD CONNECT) — THE SYNCHRONIZATION ENGINE: Entra Connect is the tool that actually synchronizes identity information from on-premise AD up to Azure AD, keeping user accounts, group memberships, and various other attributes consistent between the two genuinely separate directory systems. This is the same tool referenced throughout this platform's M365 topic in the context of hybrid provisioning — this lesson covers it specifically from the AD-administration side of that relationship.

PASSWORD HASH SYNCHRONIZATION — THE MOST COMMON AUTHENTICATION METHOD: With password hash sync, a securely hashed version of each user's on-premise AD password syncs up to Azure AD, letting users authenticate directly against Azure AD using the exact same password they use on-premise, without their actual plaintext password ever leaving the on-premise environment at any point in the process.

PASS-THROUGH AUTHENTICATION — AN ALTERNATIVE APPROACH: Rather than syncing password hashes, Pass-Through Authentication instead validates each individual login attempt directly against on-premise AD in real time, through a lightweight connector agent — meaning a disabled or locked on-premise account genuinely, immediately reflects in cloud authentication too, without waiting for the next scheduled synchronization cycle to catch up.

FEDERATION WITH ADFS — THE MOST COMPLEX, MOST CONTROL-RETAINING OPTION: As covered in this topic's dedicated ADFS lesson, some organizations instead federate authentication entirely through their own on-premise ADFS infrastructure, giving genuinely maximum control over the authentication process itself, at the cost of needing to maintain and secure that additional on-premise ADFS infrastructure directly.

WHAT ACTUALLY SYNCHRONIZES, AND WHAT GENUINELY DOESN'T: Entra Connect synchronizes user accounts, security groups, and contacts by default, but doesn't automatically sync every single AD attribute, and critically, Group Policy itself doesn't sync to the cloud at all — cloud-based device and configuration management uses entirely separate cloud-native tools (Intune, covered in this platform's Endpoint Management topic) rather than traditional on-premise Group Policy.

SYNCHRONIZATION SCOPE — NOT EVERY OU NEEDS TO SYNC: Entra Connect can be configured to synchronize only specific OUs rather than the entire domain, letting an organization deliberately exclude certain accounts (like highly privileged on-premise-only service accounts that genuinely have no legitimate reason to ever need cloud access) from ever synchronizing to Azure AD at all.

DIRECTORY SYNCHRONIZATION ERRORS — A GENUINELY COMMON, PRACTICAL TROUBLESHOOTING AREA: Sync errors commonly arise from duplicate attribute values (two on-premise accounts with the same email address, for instance) or attributes that don't meet Azure AD's specific formatting requirements — Entra Connect Health (a monitoring companion tool) provides visibility into these specific sync errors, genuinely essential for maintaining healthy, reliable ongoing hybrid identity synchronization.

WHY HYBRID IDENTITY KNOWLEDGE IS INCREASINGLY CORE, NOT OPTIONAL, AD EXPERTISE: Given how thoroughly Microsoft 365 has become standard business infrastructure for most organizations, genuine AD administration expertise today essentially requires understanding the hybrid identity relationship — treating on-premise AD as somehow isolated and disconnected from cloud identity considerations no longer genuinely reflects how most real organizations' actual identity infrastructure operates in practice.

Your primary Domain Controller (DC01) hosting all five FSMO roles has suffered a hardware failure. DC01 cannot be brought back online. DC02 exists as a secondary DC. Here's what to do.

If DC01 is completely unreachable and hardware failure is confirmed, proceed to seize.

CHECK WHAT IMPACT IS ALREADY OCCURRING: Some roles fail immediately; some have grace periods: • PDC Emulator failure: IMMEDIATE impact — time sync issues, lockout processing may fail, GPO editing fails • RID Master failure: Silent until DCs exhaust their RID pools (takes time with many objects) • Schema/Naming Master failure: Only matters when you try to make schema changes or add/remove domains • Infrastructure Master failure: Only matters for cross-domain reference updates

SEIZE THE FSMO ROLES ON DC02: Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

This command will take a few minutes — it first tries to contact DC01, times out, then seizes.

VERIFY THE SEIZURE WAS SUCCESSFUL: netdom query fsmo

All five roles should now show DC02.

CRITICAL: NEVER BRING DC01 BACK ONLINE IN THE SAME STATE Once a role has been seized on DC02, DO NOT bring DC01 back online without first either: • Completely wiping/reformatting it and re-promoting it fresh • Demoting it properly before bringing it online

Two DCs claiming the same FSMO role simultaneously would cause serious AD corruption.

You've received an alert that multiple failed authentication attempts have been occurring overnight, and you suspect an account has been compromised. Here's how to investigate using AD tools.

STEP 1 — CHECK FOR ACCOUNT LOCKOUTS Find which accounts are currently locked: Search-ADAccount -LockedOut | Select Name, SamAccountName, LastLogonDate

If many accounts are locked, this suggests a credential stuffing or brute force attack.

STEP 2 — CHECK RECENT AUTHENTICATION FAILURES ON THE DC On the Domain Controller, open Event Viewer > Windows Logs > Security. Filter for Event ID 4625 (failed logon). Look for: • Many failures for the same account from different source IPs (brute force targeting one account) • Many failures for different accounts from the same source IP (password spraying) • Failures at unusual hours (overnight, weekends) • Source IPs from unexpected locations (foreign countries)

Also check Event ID 4771 for Kerberos authentication failures — often more detailed than 4625.

STEP 3 — CHECK FOR SUSPICIOUS SUCCESSFUL LOGINS Filter for Event ID 4624 (successful logon). Look for successful logins immediately following multiple failures — the attacker may have succeeded. Look for Logon Type 3 (network logon) or Logon Type 10 (remote interactive/RDP) from unexpected IPs.

STEP 4 — IF A SPECIFIC ACCOUNT IS SUSPECTED COMPROMISED Immediately reset the password: Set-ADAccountPassword -Identity suspected_user -NewPassword (Read-Host -AsSecureString) -Reset

Force them to change it at next logon: Set-ADUser -Identity suspected_user -ChangePasswordAtLogon $true

If the account has elevated privileges, temporarily disable it: Disable-ADAccount -Identity suspected_user

STEP 5 — CHECK FOR NEW ACCOUNTS OR PRIVILEGE ESCALATION Filter Security log for Event ID 4720 (account created) and Event ID 4732 (added to security group). Any account creation or group additions not initiated by known admins is suspicious.

STEP 7 — DOCUMENT AND ESCALATE Write down exactly what you found: which accounts, which source IPs, which times, what actions were taken. This is required for any incident report and may be required for regulatory notifications.