Learn Active Directory - Active Directory Security Best Practices

#Introduction

In the previous episode 11 we built finer password defenses with Fine-Grained Password Policies — now it's time to pull the camera further back and see Active Directory as one complete security system. This episode is the roadmap for production-level AD security: not just "make a strong password", but how to ensure who is allowed to hold which keys, how those keys are protected, and how we know when someone abuses them.

Imagine AD as a bank. There are three layers: the vault room where all money and valuables are stored, the back office where tellers process transactions, and the customer service area where clients meet staff. Giving customer service staff the vault key is a disaster waiting to happen. Giving tellers access to customer systems is also not a good idea. The same principle applies to AD — and this is what we'll lay out in this episode.

#Least Privilege: The Key Principle of All Security

Least privilege means every account only holds the minimum permissions needed to do its job — no more. This isn't just an ethical principle, it's a risk calculation: every excess right is an attack surface that can be exploited.

Why is this fundamental? Because AD compromise almost always starts with a single account that happens to have more rights than it needs. A service account used to run a web application never needs membership in Domain Admins. A helpdesk user whose job is only password resets never needs full control over all OUs.

In practice, least privilege in AD means:

• Human accounts are granted access based on role, not on position or seniority.
• Service accounts are created per application, with permissions only on the resources they need.
• Separation of duties ensures no single person can perform two dangerous steps at once. For example, the person who approves a change isn't the same person who implements it.

#Tiered Administration: The Layered Admin Model

Least privilege requires structure. Microsoft provides an official model called Tiered Administration or the Tier 0/1/2 model. Its goal: ensure a compromise in one layer doesn't automatically become a compromise of the entire domain.

The logic behind it is simple: administrators must not log on to devices from a lower tier. A Tier 0 admin logging into a user workstation is a golden bridge for attackers — from a single user computer, an attacker can steal Tier 0 admin credentials. That's why this model demands separating admin accounts from daily accounts, and ideally using PAWs (Privileged Access Workstations) — dedicated computers used only for administration.

The golden rules for implementation:

• Never use an admin account for everyday things like email or browsing.
• Separate accounts per tier: one Tier 2 account for daily work, one Tier 0 account used only for domain tasks.
• Restrict where admin accounts can log on — ideally only from PAWs.

#Protected Users: Armor for Privileged Accounts

Once the tier model is in place, the next step is putting privileged accounts into the Protected Users group. This group (available since Windows Server 2012 R2) enforces a series of automatic restrictions that make an attacker's life harder:

• NTLM disabled — these accounts can't authenticate via NTLM, blocking pass-the-hash and relay.
• Kerberos encryption restricted — only AES is allowed; weak DES and RC4 are rejected.
• No Kerberos delegation — credentials can't be "borrowed" by other services.
• Credential caching restricted — credentials aren't stored in memory or cache, making them harder to dump from LSASS.
• Ticket lifetime shortened — Kerberos tickets expire faster, cutting the attack window.

Why does all this matter? Because modern attacker techniques — Mimikatz, credential dumping, pass-the-hash — almost all depend on credentials that can be stolen and reused. Protected Users cuts that path at its source.

Add-ADGroupMember -Identity "Protected Users" -Members "adm.sysadmin","adm.dcadmin"

Verify membership with Get-ADGroupMember:

Get-ADGroupMember -Identity "Protected Users" | Select-Object SamAccountName, Name

#Fine-Grained Password: Per-Group Policy Layer

AD's built-in password policy is one for the entire domain — rigid and often breeds compromise (a strong policy everywhere makes users rebel and write passwords on sticky notes). From episode 11 you already know the solution: PSOs (Password Settings Objects) that allow different policies for different groups.

In a security context, this isn't just convenience — it's a strategic tool. Service and admin accounts get the strictest PSO, regular employee accounts get a balanced policy, and machine service accounts get the exceptions they genuinely need. One domain, many strength levels.

#Disable NTLM: Reduce the Attack Surface

NTLM is a legacy authentication protocol designed in the Windows NT era — long before pass-the-hash and relay attacks became the norm. Every time a system still uses NTLM, your credentials travel a path that can be abused. We'll dissect the full details in episode 14, but one principle applies from now: NTLM should only live if it's genuinely needed, and should preferably be audited before being disabled.

#LAPS: Rotating Local Administrator Passwords

Ask yourself: does every computer on the network use the same local admin password? If yes, you're sitting on a time bomb — one compromised computer means the local admin password leaks, and that same password opens the door to every other computer.

LAPS (Local Administrator Password Solution) is Microsoft's answer to this problem: each computer gets a unique, random local admin password, rotated periodically, and stored encrypted in an AD attribute. Admins only retrieve it when they truly need it.

Get-LapsADPassword -Identity "SRV-WEB01" -AsPlainText

Note the principle: passwords are no longer emailed to all employees — they live in AD, are only retrieved when needed, and every retrieval can be audited.

#Security Auditing: The Ever-Watchful Eye

Security without auditing is a claim without evidence. Auditing is the ability to record important events in the domain so you know what happened, when, and by whom. This isn't just for investigation — the mere existence of auditing is a deterrent: people think twice before cheating when they know everything is recorded.

Audit categories that must be enabled in production environments:

• Account logon events — who logged in, success or failure.
• Account management — account/group creation, deletion, and changes.
• Directory service access — access to specific AD objects (to monitor sensitive objects).
• Policy change — security policy and GPO changes.
• Privilege use — use of privileges like SeDebugPrivilege.

One quick way to enable the main audit categories is via auditpol /set, for example:

auditpol /set /subcategory:"Logon/Logoff" /success:enable /failure:enable
auditpol /get /subcategory:"Logon/Logoff"

The gold-standard source is Advanced Audit Policy, which is far more granular than basic audit policy and can be managed via GPO. The events recorded here become the raw material for SIEM and security monitoring in episode 23.

#Credential Guard: Protect Credentials in Memory

The most dangerous attacks against AD happen at the endpoint level: an attacker who has already gotten into one computer tries to steal credentials from the LSASS process (Local Security Authority Subsystem Service) — where Windows stores login credentials. This is the technique Mimikatz uses to extract hashes and tickets.

Windows Defender Credential Guard thwarts it by hiding the sensitive part of LSASS inside an isolated, virtualization-based environment (Virtualization-Based Security). Stored credentials can no longer be read by normal processes — not even by a local admin.

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Practical requirements: modern hardware with virtualization support and locked firmware, Windows 10/11 Enterprise or the latest Windows Server. As a trade-off, some legacy scenarios like NTLMv2 on certain machines or third-party drivers can be affected — test in a staging environment before wide rollout.

#Conclusion

In this episode we've assembled layered AD defenses: least privilege as the foundational principle, the Tier 0/1/2 model to separate authority levels, Protected Users to restrict privileged accounts, PSOs for granular password policy, disabling NTLM to close legacy authentication paths, LAPS to break shared local passwords, auditing for oversight, and Credential Guard to protect credentials in memory.

The takeaway: AD security isn't a single feature, but a stack of layers — and every missing layer increases the odds of an attacker finding a gap. Start with the highest impact: separate admin accounts, add them to Protected Users, and turn on auditing.

In the next episode 13, we enter the heart of AD authentication: Kerberos — the ticket protocol that is the backbone of every domain logon. We'll dissect how the KDC issues TGTs, how service tickets work, and why this ticket system is far more secure than NTLM. Keep the momentum going!