Active Directory — Part 11 — Active Directory Security Basics

Introduction

In Part 5, we saw how Kerberos tickets and password hashes can be stolen and replayed — Pass-the-Ticket, Kerberoasting, the Golden Ticket. Those attacks share a quiet assumption we did not examine at the time: that the attacker found privileged credentials somewhere they could reach.

Where would they find them? On whatever machines privileged accounts have logged into. Windows caches credential material in memory on every interactive logon — which means the security of your entire forest is decided not by your firewall, but by the answer to a mundane question: where do your administrators type their admin passwords?

There is a saying in this field that attackers do not break in, they log in. This part is about making that logging-in as hard as possible.

What Counts as a Privileged Account

The obvious ones are the built-in groups: Domain Admins, Enterprise Admins, Schema Admins, and the domain’s built-in Administrators group. Compromise of any member means compromise of the domain — and via the krbtgt account from Part 5, compromise that can outlive every password reset you do afterwards.

The less obvious ones are where real environments get hurt: the backup service account that can write to Domain Controllers. The helpdesk account that can reset anyone’s password. The account with delegated control over the OU containing admin accounts. The monitoring agent that runs as local Administrator on every server. None of these appear in Domain Admins, and any of them may be one step from it.

The Principle of Least Privilege

Least privilege is the oldest idea in security and still the most cost-effective: every account, human or service, gets exactly the permissions its job requires, and nothing else.

We already saw the pattern once in Part 4 — permissions granted to groups via AGDLP rather than sprinkled onto individuals. Applied to administration, it means the helpdesk gets password-reset rights over the staff OU rather than membership of Domain Admins; a service gets rights on the three servers it touches rather than local admin everywhere; and delegation is done deliberately through OU permissions rather than by handing out group memberships because it was quicker that day.

The reason is arithmetic. Every unnecessary privilege multiplies what an attacker gains from compromising that account. Least privilege does not stop the compromise — it caps the damage.

The Master Key Analogy

Think of the Domain Admin account like the master key to an entire office building — every door, every floor, the server room, the safe.

Nobody sensible carries the master key to buy coffee. It lives in a controlled place and comes out for the rare job that genuinely needs it. If you carry it everywhere, it will eventually be left on a café table — and whoever picks it up does not need to break a single window.

Logging into an ordinary workstation with Domain Admin credentials is carrying the master key to buy coffee. The workstation’s memory now holds material that unlocks the entire building, and the workstation is only as secure as its most careless email attachment.

Why Domain Admin Should Rarely Be Used

When a Domain Admin logs into a machine interactively — at the console, over RDP, even with runas — that machine’s memory receives the account’s credential material. An attacker who already owns that machine harvests it and is now a Domain Admin. This is exactly the lateral movement path the Part 5 attacks rely on.

The discipline that follows is simple to state. Domain Admin credentials touch Domain Controllers and nothing else. Day-to-day work — email, browsing, documents — happens on a normal account with no admin rights at all. Server administration happens with separate, lesser admin accounts that cannot touch AD itself. Most weeks, the Domain Admin account should not log in anywhere.

The Tier Model, Simply

The tier model is nothing more than the master-key discipline written down as three rules. Sort every system by what its compromise would cost:

Then enforce one rule: credentials never log in below their tier. Tier 0 accounts sign in only to Tier 0 systems. A Tier 1 admin account never signs in to a workstation. Administration flows downward through dedicated admin accounts per tier — never by carrying high-tier credentials onto low-tier machines.

Why this direction? Because exposure happens where you log in. A Tier 0 credential typed into a Tier 2 workstation hands Tier 0 to whoever owns that workstation. A Tier 2 credential used on a Tier 2 machine loses only Tier 2. The rule keeps the blast radius of any single compromised machine inside its own tier.

The Practical Basics

Beyond accounts and tiers, a handful of controls deliver most of the value in ordinary environments.

LAPS — the Local Administrator Password Solution, now built into Windows — gives every machine a unique, automatically rotated local admin password stored in AD. Without it, one shared local admin password turns a single compromised workstation into all of them.

Group Managed Service Accounts replace service accounts with human-set, never-changed passwords — the same accounts Kerberoasting from Part 5 preys on — with accounts whose long random passwords AD rotates automatically.

The Protected Users group applies extra hardening to its members: no NTLM, no weak Kerberos encryption, no credential caching or delegation. It suits privileged human accounts — but never service or computer accounts, and add admins gradually, because the same restrictions that block attackers can lock you out of older systems.

And watch the privileged groups. Membership changes to Domain Admins should be rare, planned events — an unexplained addition is one of the highest-signal alerts an environment can raise.

Scripts / Commands

Use the commands below to take stock of privileged access in your domain. All of them are read-only — this is an audit, not a change.

# Who is actually in Domain Admins - including via nested groups?
Get-ADGroupMember "Domain Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Enterprise and Schema Admins should usually be empty or near-empty
Get-ADGroupMember "Enterprise Admins" -Recursive
Get-ADGroupMember "Schema Admins" -Recursive

# Accounts marked as protected admins, past or present
Get-ADUser -Filter 'adminCount -eq 1' -Properties adminCount |
    Select-Object Name, SamAccountName

# Privileged accounts whose passwords never expire
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object Name, PasswordNeverExpires, PasswordLastSet

# Who is in Protected Users so far?
Get-ADGroupMember "Protected Users"

# Service-account risk: user accounts carrying SPNs (Kerberoasting targets)
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName |
    Select-Object Name, SamAccountName

# When did each Domain Admin account last log on?
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties LastLogonDate |
    Sort-Object LastLogonDate |
    Select-Object Name, LastLogonDate

Common Mistakes Cheat Sheet

Quick Reference Summary

Final Thoughts

Active Directory security has an unusual property: the most effective controls are organisational habits, not products. Separate accounts, tiered logons, unique local passwords, small privileged groups — none of it is glamorous, and together it removes the paths that real intrusions actually take.

The tier model can be built up gradually. Start with the two changes that pay immediately: get daily work off admin accounts, and get Domain Admin logons off everything that is not a Domain Controller. Everything else in this part is a refinement of those two moves.