Internal Network & Active Directory · beginner · ~11 min
By the end of this lesson you will be able to: - Define **Active Directory (AD)** and explain what a *directory service* does for a Windows network. - Describe the domain model and name the role of the **domain controller (DC)**, the **NTDS.dit** database, the **forest**, and **trusts**. - Explain why holding **Domain Admin** rights or compromising a DC means "owning the kingdom." - Connect AD identities back to the local Windows users, groups, and SIDs you learned earlier. - Outline, at a high level, the legitimate *defensive* workflow used to assess an AD environment: enumerate, find misconfigurations, understand the path to escalation, then remediate and verify. - Recognise that most AD compromise comes from *misconfiguration*, not software bugs — which is exactly why defenders can prevent it.
Security objective of this lesson. The asset we are learning to protect is identity itself: the central credential store (NTDS.dit), the servers that hold it (domain controllers), and the most powerful accounts (Domain Admins). The threat is an attacker who gains any foothold in a Windows network and then pivots to control the whole environment. What you will learn to recognise is the model well enough to know what to defend first, why an ordinary user can already map much of the domain, and how a single misconfiguration becomes a path to total compromise.
Active Directory (AD) is Microsoft's directory service: the central database of identities and policy that runs almost every corporate Windows network. If you have ever logged into a work laptop with a username and password and then reached a file share, a printer, and your email without logging in again, you were using Active Directory.
A directory service is just an organised database of "who and what exists" plus "what they are allowed to do." Instead of every computer keeping its own private list of users (the local accounts you met in the prerequisite lesson Windows users, groups, and SIDs), AD keeps one shared list for the whole organisation. A new employee is created once, in AD, and can then sign in to any company machine. This is exactly where the prerequisite connects: a local SID identified an account on one machine; a domain SID, issued by the domain, identifies an account across every machine that trusts the domain.
Three pieces form the model, and the rest of this category builds on them:
corp.example.local).The big idea: in a domain you no longer trust each machine separately. You trust the DC, and every machine trusts the DC. That single point of trust is what makes AD powerful for administrators — and what makes it the number-one target in internal security work. Holding Domain Admin rights, or compromising a DC, means control over every joined machine, account, and resource at once. This is why AD is often called "the keys to the kingdom."
The rest of this overview ramps into terminology that the next lessons (starting with AD objects: users, groups, computers, and OUs) expand in detail.
AD centralises authentication and management across an entire organisation. One place to create a user, one place to reset a password, one place to push a security setting to ten thousand machines. That convenience is why AD is everywhere — and why understanding it is non-negotiable for anyone defending or testing Windows networks.
The same centralisation cuts both ways:
In authorised professional work this shapes the whole engagement. On a red team / internal penetration test, the scoped objective is usually "reach Domain Admin" or "access a DC" because that single result demonstrates worst-case business impact to the client. On the blue team / identity engineering side, the same model tells you precisely where to spend hardening budget: the DC, the Domain Admins group, the NTDS.dit database and its backups, and the trust relationships between domains. Understanding the model is therefore the difference between scattering effort and defending the few things that actually decide the outcome.
This lesson defines the foundational vocabulary. Each later lesson zooms into one of these.
Definition. A directory service is a centralised, queryable database of network objects (users, computers, groups) and their attributes.
Plain language. It is the company phonebook plus the rulebook: who exists, and what each one may do.
How it works internally. AD stores objects in a hierarchical database and exposes them over the LDAP protocol for queries and the Kerberos protocol for authentication. Each object has attributes (name, group memberships, password hashes for accounts, etc.).
When to use it / when not. Organisations use AD when many users and machines need shared identity and policy. A single home PC does not need it — it just uses local accounts.
Pitfall. Beginners assume "directory" means a folder on disk. Here it means a database of identities, not a filesystem directory.
Definition. A domain is a security and administrative boundary that groups users, computers, and groups under one authority, with a DNS-style name like corp.example.local.
Plain language. It is the "organisation" everyone and everything belongs to.
Structure. Inside a domain, accounts are domain accounts (managed centrally), as opposed to the local accounts on a single machine that you saw in Windows users, groups, and SIDs. A user has a domain SID issued by the domain, in addition to any local SIDs.
When to use / not. One domain is enough for most companies. Multiple domains appear in large or merged organisations.
Pitfall. Confusing a domain (AD) with a workgroup (no central authority — every machine is independent).
Definition. A DC is a server running AD; it authenticates every login and stores the directory database in a file called NTDS.dit.
Plain language. The DC is the gatekeeper and the vault. NTDS.dit is the vault's contents — including the password hashes of every domain account.
How it works internally. When you log in, your machine asks a DC to verify you (via Kerberos). The DC checks the credential material stored in NTDS.dit and issues tickets that let you reach resources. Domains usually run several DCs that replicate NTDS.dit to each other for reliability — which also means the secrets exist on every DC.
When to use / not. Every domain must have at least one DC. You never store anything but AD-critical roles on a DC if you can avoid it — its compromise is total.
Pitfall. Treating a DC like an ordinary server (installing extra software, browsing the web from it). Each added function widens the attack surface of the most critical box in the network.
+---------------------+
login | Domain Controller | stores
------> | (runs AD service) | -------> NTDS.dit
user | authenticates | (all domain
| issues tickets | accounts +
+---------------------+ password hashes)
^ ^
| |
+--------+ +---------+
| |
Workstation A Server B
(joined, trusts DC) (joined, trusts DC)
Knowledge check. In your own words, why does compromising NTDS.dit hand an attacker the entire domain?
Definition. A forest is the top-level boundary containing one or more domains that share a schema and a common root of trust. A trust is a configured relationship that lets users in one domain access resources in another.
Plain language. A domain is a country; a forest is the union of countries that recognise each other's passports. A trust is the treaty that makes a passport accepted across the border.
Structure. Domains in the same forest trust each other automatically; trusts can also be set up between forests, deliberately, for partners or mergers.
When to use / not. Multiple domains/forests appear in large enterprises and after acquisitions. Small organisations stay single-domain.
Pitfall. Assuming a trust is harmless. A poorly scoped trust can let a compromise in one domain reach another. The security boundary is the forest, not the domain — a Domain Admin in any domain can often endanger the whole forest.
Definition. Domain Admins is a built-in group whose members effectively control everything joined to the domain.
Plain language. A Domain Admin can reset any password, log into any machine, and read any data in the domain.
When to use / not. These accounts should be rare, tightly controlled, and never used for everyday tasks like email or browsing. Day-to-day work should use low-privilege accounts.
Pitfall. Logging in to ordinary workstations with a Domain Admin account. If that machine is compromised, the powerful credentials are exposed there.
ASSETS (what we protect) TRUST BOUNDARY ENTRY POINTS (attacker start)
------------------------------- --------------------------- ------------------------------
NTDS.dit (all account hashes) | The FOREST is the real - Phished domain user
Domain Admins credentials | boundary. DCs sit at the - Malware on a workstation
Domain Controllers (servers) | most trusted point INSIDE.- Weak service-account pwd
Kerberos ticket-granting key | A breach inside a domain - Over-broad delegation
Group Policy (mass control) | spreads OUTWARD across - Misconfigured domain trust
AD-integrated DNS | trusts, not just up. - Exposed AD backup / NTDS.dit copy
Knowledge check. What asset is the single most valuable one in this diagram, and where does it physically live?
Knowledge check. An administrator uses their Domain Admin account to log into a regular helpdesk laptop to fix a printer. The laptop already has malware on it. What insecure assumption made this dangerous, what is the worst realistic outcome, and which log event would help you detect it?
Knowledge check. A company runs a single domain with three DCs for reliability. How many copies of the domain's password hashes exist, and why must all AD queries here only be run in an authorised lab you own?
Active Directory is a concept, not a programming language, so there is no source syntax to compile. What you will see repeatedly is naming and identity structure. Reading these correctly saves a lot of confusion.
Domain DNS name: corp.example.local
NetBIOS (short) name: CORP
Logon name formats:
CORP\jdoe (down-level / NetBIOS form)
jdoe@corp.example.local (UPN / user principal name form)
Distinguished Name (DN) of an object in the directory:
CN=Jane Doe,OU=Staff,DC=corp,DC=example,DC=local
| | | | | |
| | | +--+-------+-- domain split into DC= parts
| | +-- Organizational Unit (a container, covered next lesson)
| +-- Common Name of the object
+-- attribute type
DC= parts spell out the domain (corp.example.local -> DC=corp,DC=example,DC=local). Do not confuse this DC= (Domain Component, an LDAP attribute) with DC the domain controller server — same letters, different meaning.OU= is an Organizational Unit, a container for organising objects.user@domain) and down-level (DOMAIN\user) are two ways to name the same account.S-1-5-21-<domain>-<RID>; the S-1-5-21-<domain> part is shared by every account in the domain (the DomainSID), and the trailing RID identifies the specific account — the direct extension of the local-SID idea from the prerequisite lesson.Active Directory (AD) is Microsoft's directory service. It is the central database of identities and policy that runs almost every corporate Windows network.
In a domain, you do not log in to each machine separately. AD centralises two things:
That centralisation is exactly why AD is the universal target. Domain Admin rights, or a DC compromise, mean control of every joined machine, user, and resource at once.
The usual workflow is:
This path usually relies far more on configuration abuse than on exploitation. The next lessons cover each piece.
Because this is a concept lesson, the most useful "code" is configuration and read-only enumeration you would run only in your own authorised lab. Security lessons follow an insecure -> secure -> verify shape, so below we (1) show an insecure administrative habit, (2) show the secure fix, and (3) show a read-only check that proves the fix.
Authorisation checklist (do all of these before running anything):
- The domain is one you built (or an intentionally vulnerable training VM / CTF), on an isolated network.
- You have written authorisation if the lab is not exclusively yours.
- You will run read-only queries only; you will make no changes to a directory you do not fully control.
- You know your cleanup/reset step (revert the VM snapshot) before you start.
WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.
# INSECURE HABIT (lab only): everyday admin work done as Domain Admin.
# The administrator interactively logs on to an ordinary, internet-facing
# workstation using a Domain Admin account "to fix a printer".
#
# Logged-on user: CORP\da-admin (member of Domain Admins)
# Machine: WKSTN-14 (browses web, opens email, may hold malware)
#
# Why this is dangerous: the credential material for a Domain-Admin logon is
# now present on WKSTN-14. Malware already on that host can reuse it and reach
# a DC -> the whole domain falls. Nothing was "hacked" — a trust boundary was
# crossed by a bad habit.
# SECURE (lab only): tiered administration.
# Domain Admins are used ONLY from a hardened admin workstation, never on
# ordinary user machines. Everyday tasks use a low-privilege account.
#
# Everyday work: CORP\jdoe (normal user, no admin rights)
# Admin work: CORP\da-admin (Domain Admin, used ONLY on ADMIN-PAW)
# ADMIN-PAW: a Privileged Access Workstation: no email, no web browsing
#
# Guardrail you can configure so the insecure logon is REJECTED:
# put Domain Admins in "Protected Users" and deny their interactive logon
# to Tier-1/Tier-2 machines. (Shown here as intent; configured via Group
# Policy 'Deny log on locally' + the Protected Users group.)
# VERIFY (lab only, READ-ONLY): confirm the guardrail rejects bad, accepts good.
# Requires the RSAT ActiveDirectory module; run as a normal domain user.
# 3a. Describe the domain you are in (no changes made).
Get-ADDomain |
Select-Object Name, DNSRoot, NetBIOSName, DomainSID, Forest
# 3b. Which servers are the crown jewels (DCs)?
Get-ADDomainController -Filter * |
Select-Object Name, IPv4Address, Site, IsGlobalCatalog
# 3c. PROVE the fix: Domain Admins should be a SHORT list, and each member
# should also be in Protected Users. A long list = fix not applied.
Get-ADGroupMember -Identity 'Domain Admins' |
Select-Object Name, SamAccountName
Get-ADGroupMember -Identity 'Protected Users' |
Select-Object Name, SamAccountName
# 3d. ACCEPT good / REJECT bad: after applying the deny-logon guardrail, an
# attempt to log da-admin onto WKSTN-14 is refused and generates a
# Security log event 4625 (logon failure) on that host; a legitimate
# logon on ADMIN-PAW succeeds (event 4624). You read these with:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625} -MaxEvents 20 |
Select-Object TimeCreated, Id, @{n='Account';e={$_.Properties[5].Value}}
What it does. Part 3 makes three read-only LDAP queries (describe domain, list DCs, list two privileged groups) and reads the local Security log. None of these modify the directory. The reject-bad / accept-good proof is the pair of logon events: the bad habit now produces a 4625 failure on the user workstation, while the legitimate privileged logon produces a 4624 success only on the admin workstation.
Expected output (shape, values illustrative).
Name DNSRoot NetBIOSName DomainSID Forest
---- ------- ----------- --------- ------
CORP corp.example.local CORP S-1-5-21-... corp.example.local
Name IPv4Address Site IsGlobalCatalog
---- ----------- ---- ---------------
DC01 10.0.0.10 Default-First-Site True
DC02 10.0.0.11 Default-First-Site True
Name SamAccountName
---- --------------
da-admin da-admin
TimeCreated Id Account
----------- -- -------
2026-07-07 09:14:02 4625 da-admin <- rejected on WKSTN-14 (good: fix works)
2026-07-07 09:15:20 4624 da-admin <- accepted on ADMIN-PAW (good: legit path)
Edge cases. If the AD module is not installed, PowerShell reports Get-ADDomain is not recognized — install RSAT first. If you are not joined to a domain, the cmdlets fail because there is no domain to query. A non-privileged user can usually read the group memberships; that readability is itself a defensive lesson — assume an attacker with any foothold can see it too.
Cleanup / reset. When finished, revert the lab VM to its pre-exercise snapshot so no experimental state (added members, test accounts, changed logon rights) persists.
Walking through the verification example above:
| Step | Command | What happens | Why it matters |
|---|---|---|---|
| 1 | Get-ADDomain |
PowerShell sends an LDAP query to a nearby DC asking for the domain's properties | Confirms which domain you are in and its DomainSID — the root that every domain account's SID extends, linking straight back to Windows users, groups, and SIDs |
| 2 | Select-Object Name, DNSRoot, ... |
Picks just the useful fields from the returned object | Keeps output readable; Forest reveals the top-level boundary |
| 3 | Get-ADDomainController -Filter * |
Asks AD for every DC object in the domain | Tells you where the crown jewels live — the servers running AD and holding NTDS.dit |
| 4 | IsGlobalCatalog column |
Flags which DCs also serve forest-wide lookups | Global Catalog DCs answer cross-domain queries, so they matter in multi-domain forests |
| 5 | Get-ADGroupMember 'Domain Admins' |
Returns the membership of the most powerful group | These accounts are the highest-value targets; the shorter this list, the smaller the attack surface — this is the proof the secure fix holds |
| 6 | Get-ADGroupMember 'Protected Users' |
Lists accounts hardened against credential theft | If a Domain Admin is not here, the tiering fix is incomplete |
| 7 | Get-WinEvent ... Id=4624,4625 |
Reads success/failure logon events from the Security log | The 4625 on the user workstation proves the bad logon was rejected; the 4624 on the admin workstation proves the good path was accepted |
Trace of the data flow for step 1: your shell -> LDAP request -> DC checks your read permission -> DC reads the domain object from NTDS.dit -> returns attributes -> PowerShell formats them. At no point is anything written. Notice how every answer ultimately comes from a DC reading NTDS.dit: that is the concrete reason the DC and that file are the things to defend hardest.
Trace of the reject/accept proof: attacker-controlled WKSTN-14 attempts an interactive logon as da-admin -> local security policy "Deny log on locally" matches -> logon refused -> Security event 4625 written locally. Meanwhile a real admin signs in on ADMIN-PAW -> policy permits -> event 4624 written. Reading both events is how you verify the mitigation actually changed behaviour rather than assuming it did.
Mistake 1: Confusing a domain with a workgroup.
Get-ADDomain (works only when domain-joined) or look at the logon screen's DOMAIN\user prompt.Mistake 2: Confusing DC= (Domain Component) with DC (domain controller).
DC=corp,DC=example,DC=local as "three domain controllers."DC= is an LDAP attribute spelling out the domain name, unrelated to the server.DC=corp,DC=example,DC=local = the domain corp.example.local. The servers are found with Get-ADDomainController.Mistake 3: Treating the DC (or single domain) as the security boundary.
Mistake 4: Using a Domain Admin account for everyday work.
Mistake 5: Believing enumeration is harmless or requires admin rights.
Even on a concept lesson, the read-only lab commands fail in predictable ways. Use these to diagnose.
Get-ADDomain : The term ... is not recognized — the ActiveDirectory PowerShell module is missing. Install RSAT (Remote Server Administration Tools), then re-open PowerShell so the module loads.Unable to contact the server / Unable to find a default server — the machine is not domain-joined, or no DC is reachable. Confirm domain membership and that DNS points at a DC (AD relies heavily on DNS).Insufficient access rights on a write or sensitive read — you are a normal user trying something privileged. For learning, stay on read-only queries; do not escalate to make it work.Get-WinEvent returns nothing for 4624/4625 — auditing may not be enabled, or you are reading the wrong host's log. Logon events are recorded on the machine where the logon was attempted, so read WKSTN-14's log to see the rejected attempt, not the DC's.Questions to ask when something "doesn't work":
Get-ADDomain / logon name)DC= name component?Logic-error trap: assuming the output of these commands describes "the network." It describes the directory's view of the domain — accurate for joined objects, but it will not show machines that are in a workgroup and never joined AD.
This is a security lesson, so the equivalent of "memory safety" here is operational access safety plus detection and logging. Active Directory is the highest-value asset class in a Windows estate; treat it accordingly.
Authorisation and ethics. Only ever enumerate, query, or test an Active Directory environment you own or are explicitly authorised in writing to assess. All exercises in this category assume an isolated, local lab (a small domain you built yourself, or an intentionally vulnerable training VM). Never point these techniques at an organisation's live AD without authorisation — doing so is unlawful and unethical. Keep a cleanup/reset step (a VM snapshot to revert to) so the lab returns to a known state.
Why enumeration matters defensively. Notice that an ordinary user can read much of the directory (group memberships, DC list, descriptions). That is by design, but it means defenders must assume attackers can map the domain quickly once they have any foothold. The defence is not to hide the directory but to remove the misconfigurations attackers chain together.
Detection and logging — what to LOG. For every security-relevant event capture: timestamp, source (host + account that acted), the resource/target touched (for example the Domain Admins group, a DC), the result (success/failure), the security decision (allowed/denied by which policy), and a correlation id so related events across hosts can be tied together. High-value events to record and alert on:
What to NEVER LOG. Never write credential material into logs: no passwords, no password hashes, no Kerberos keys or tickets, no session cookies, no private keys, and no unneeded PII. Log the event metadata (who did what, when, with what result) — never the secret itself. A log that contains hashes becomes a second copy of NTDS.dit's most dangerous contents.
Which events signal abuse. A Domain Admin logging onto a random workstation, a sudden addition to Domain Admins outside a change window, replication requests from a non-DC source, or a spike of 4625 failures against privileged accounts. Any of these warrants prompt investigation.
How false positives arise. Legitimate causes mimic attacks: a real admin genuinely fixing a machine, a scheduled tier change during maintenance, a monitoring tool that queries the directory heavily, or backup software performing replication-like reads. Tune alerts with maintenance windows and known-good source lists so real work is not paged on, while still catching the genuine anomaly.
Defensive practices (foundational):
Where AD actually runs. The overwhelming majority of mid-to-large organisations — corporations, universities, hospitals, governments — run Active Directory as the backbone of identity. It controls who can log into laptops and servers, who can open which file shares, which security settings every machine receives (via Group Policy), and increasingly it federates with cloud identity (for example hybrid setups syncing to Microsoft Entra ID). When you join a company and get a single sign-on that reaches email, intranet, VPN, and printers, AD (or its cloud successor) is usually behind it.
A concrete authorised use case. An internal penetration test is scoped, in writing, to "assess whether a phished standard user could reach Domain Admin." The tester works only inside the client's environment, starts from a low-privilege account the client provided, enumerates the directory read-only, documents each misconfiguration found, and stops at proof — then the report drives remediation (tighten the over-broad permission, rotate the weak service password) and a retest verifies each fix. The value delivered is not the break-in; it is the prioritised, verified list of things to fix.
Professional best-practice habits for this topic:
Beginner-level rules:
Advanced-level habits:
Work through these in order; difficulty increases. None require attacking any real system — use your own notes, diagrams, and (where stated) an isolated personal lab.
Beginner 1 — Define the model in your own words.
Beginner 2 — Domain vs workgroup table.
Central authority | Domain: yes (DC) | Workgroup: no.Intermediate 1 — Draw the trust/blast-radius diagram.
Intermediate 2 — Read-only lab recon (authorised lab only).
Challenge — Mini hardening checklist with verification.
DC= (a name component) is not a DC (a server), and ordinary users can already read much of the directory.