Radioactive Directory

The core insight behind AD tiering is simple: a credential that has ever touched a compromised machine is a compromised credential. If a Domain Admin logs into a regular workstation, and that workstation gets owned, game over. Tiering creates hard boundaries so that a low-level compromise can never directly expose high-privilege credentials.

The Legacy Tier Model (Still Widely Deployed)

Microsoft's original tier model for partitioning administrative privileges divides the environment into three tiers, each with dedicated accounts and strict logon restrictions:

Microsoft's Enterprise Access Model (EAM) — The Modern Replacement

Microsoft replaced the legacy tier model with the Enterprise Access Model to address hybrid and cloud environments. The ESAE (Red Forest) architecture was formally retired. The EAM expands three tiers into five planes:

The Reality: Full Tiering is Hard. Where to Start.

Most organisations can't implement full tiering overnight. Legacy applications break, service accounts span tiers, and institutional resistance is real. The practical approach is to prioritise ruthlessly:

The Protected Users security group (introduced in Server 2012 R2 / Windows 8.1) is one of the most powerful and underused controls in Active Directory. Adding an account to this group forces a strict set of non-configurable protections at both the client and DC level. Unlike most AD settings, these protections cannot be overridden by GPO — they are enforced by the OS and KDC.

Requirements: Domain functional level must be Windows Server 2012 R2 or higher. Client-side protections require Windows 8.1 / Server 2012 R2 or later. The PDCe must run Server 2012 R2 or later for DC-side protections to activate.

What Protected Users Actually Does

"Account is sensitive and cannot be delegated" — Only Needed When Protected Users Isn't Used

If an account is already a member of Protected Users, the "Account is sensitive and cannot be delegated" flag is completely redundant — Protected Users already blocks both constrained and unconstrained Kerberos delegation at the DC level. The TGT simply will not be forwarded regardless of the individual flag. There is no value in setting both.

The flag exists as a targeted, lighter alternative for accounts that cannot join Protected Users — typically service accounts that need NTLM authentication, require DES/RC4 Kerberos, rely on delegation themselves, or need TGT lifetimes longer than 4 hours. For those accounts, setting NOT_DELEGATED (userAccountControl bit 0x100000) blocks their TGT from being forwarded in delegation scenarios without breaking the other authentication features they depend on.

Specifically: if an attacker compromises a server with unconstrained delegation and captures forwarded TGTs, accounts with this flag set will not have their TGTs forwarded — the token cannot be used for delegation-based lateral movement. It does not prevent NTLM usage, credential caching, or Pass-the-Hash. Think of it as a targeted defence against delegation abuse specifically.

# Find all privileged accounts NOT in Protected Users
$protected = (Get-ADGroup "Protected Users" -Properties Members).Members
$privGroups = @("Domain Admins","Enterprise Admins","Schema Admins","Administrators")
foreach ($group in $privGroups) {
    Get-ADGroupMember $group -Recursive | Where-Object {
        $_.objectClass -eq 'user' -and $_.DistinguishedName -notin $protected
    } | Select-Object Name, SamAccountName
}

# Find accounts with Kerberos pre-auth disabled (AS-REP roastable)
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth |
    Select-Object Name, SamAccountName, DistinguishedName

# Set "Account is sensitive and cannot be delegated" on a user
Set-ADUser "admin_jsmith" -AccountNotDelegated $true

# Find all accounts that can be delegated (remove from privileged accounts)
Get-ADUser -Filter {AccountNotDelegated -eq $false -and AdminCount -eq 1} |
    Select-Object Name, SamAccountName

What "Cannot Be Delegated" Protects Against

If a server with unconstrained delegation is compromised (see Delegation Abuse), the attacker can harvest any TGT that gets forwarded to that server — including from privileged accounts that authenticate to it. Accounts with NOT_DELEGATED set or in Protected Users will not forward their TGT, so even if the server is owned, those credentials cannot be abused for further delegation-based movement.

# List all members of Protected Users
Get-ADGroupMember "Protected Users" -Recursive | Select-Object Name, objectClass

# Check a specific user's delegation settings
Get-ADUser "admin_jsmith" -Properties AccountNotDelegated, MemberOf |
    Select-Object Name, AccountNotDelegated,
        @{N="InProtectedUsers";E={$_.MemberOf -match "Protected Users"}}

# Find accounts configured for unconstrained delegation (high risk)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
    Select-Object Name, DNSHostName
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
    Select-Object Name, SamAccountName

A Privileged Access Workstation is a dedicated, hardened device used exclusively for administrative tasks. The principle is clean source: you only administer sensitive systems from a device that is itself as secure as, or more secure than, those systems. Administering a DC from a workstation that a user also uses for email defeats the entire point.

PAW Hardening Requirements

A PAW is only effective if it is significantly harder to compromise than standard workstations. Key hardening controls:

• Windows Credential Guard — virtualises LSASS in a hypervisor-protected container; extracted hashes and tickets from LSASS become computationally infeasible. Requires UEFI firmware with Secure Boot and VBS (Virtualization Based Security).
• Windows Defender Application Control (WDAC) / AppLocker — only signed, pre-approved applications can execute. Attackers cannot run tools even if they gain access.
• Bitlocker with TPM + PIN — full disk encryption with pre-boot authentication.
• No local admin for the daily-use persona — the admin's daily computer and the PAW are strictly separate. On the PAW itself, the Tier 0 account is used; it never touches the daily workstation.
• Host-based firewall restricting outbound — PAW should only communicate with specific AD management systems, not the internet.
• Separate physical device is ideal. A VM PAW provides weaker isolation — if the hypervisor host is compromised, the PAW is also at risk. Cloud-based PAWs (Azure Virtual Desktop) are increasingly viable and easier to manage at scale.

Physical vs Virtual PAWs — Microsoft's Guidance and Practical Reality

Microsoft's privileged access device guidance distinguishes between physical and virtual PAW deployments. The right choice depends on the tier being administered:

LAPS solves one of the most common lateral movement enablers: shared local administrator passwords. If every workstation has the same local admin password (the classic "image password"), compromising one workstation gives an attacker local admin on every workstation. LAPS rotates each machine's local admin password independently and stores it in AD, readable only by authorised principals.

Legacy LAPS vs Windows LAPS

Security Risks with LAPS

# Find machines WITHOUT LAPS configured (ms-Mcs-AdmPwd not set)
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd |
    Where-Object { $_.'ms-Mcs-AdmPwd' -eq $null } |
    Select-Object Name, DistinguishedName

# Find who has read access to LAPS passwords (legacy LAPS)
# Run on each OU - look for unexpected principals with ReadProperty on ms-Mcs-AdmPwd
Import-Module ActiveDirectory
$ou = "OU=Workstations,DC=domain,DC=com"
(Get-ACL "AD:\$ou").Access |
    Where-Object { $_.ActiveDirectoryRights -match "ReadProperty" -and
                   $_.ObjectType -eq "ms-Mcs-AdmPwd" } |
    Select-Object IdentityReference, ActiveDirectoryRights

# Windows LAPS: Check expiry and force rotation
Get-LapsADPassword -Identity "WORKSTATION01" -AsPlainText
Reset-LapsPassword -Identity "WORKSTATION01"

Monitor Event ID 4662 (Operation performed on object) on AD for read access to the ms-Mcs-AdmPwd attribute — this fires when someone reads a LAPS password. Unexpected reads (from non-helpdesk accounts, after hours, in bulk) are a strong indicator of lateral movement recon.

Just-in-Time (JIT) access means no standing privileged access. Instead of being a permanent member of Domain Admins, a privileged user requests elevation for a specific time window, performs their task, and the access is automatically revoked. This dramatically limits the window of exposure: even if an account is compromised, the attacker only has elevated access during the active window, not permanently.

JIT Options for Active Directory

Windows Credential Guard — Deep Dive

Credential Guard uses Virtualization Based Security (VBS) to isolate the LSASS process in a hypervisor-protected container. The isolated LSA process (LSAIso.exe) stores NTLM hashes, Kerberos TGTs, and domain credentials separately from the regular OS. Even a process running at SYSTEM or kernel level cannot read from this isolated container — it communicates only via RPC, and only with binaries signed by certificates trusted by VBS.

When Is Credential Guard Enabled by Default?

Default enablement status varies significantly by OS version — this is important to understand because many organisations assume it's on when it isn't:

Hardware Requirements

• 64-bit CPU with hardware virtualisation support (Intel VT-x / AMD-V) and Second Level Address Translation (SLAT / EPT / RVI)
• UEFI firmware with Secure Boot enabled
• TPM (version 1.2 or 2.0) — required for UEFI lock and binding keys to hardware
• VBS-capable — the Windows hypervisor must be able to run; this excludes some virtualisation environments unless nested virtualisation is enabled

# Method 1: Check via WMI (0=Disabled, 1=Enabled but not running, 2=Enabled and running)
(Get-WmiObject -Namespace root\Microsoft\Windows\DeviceGuard -Class Win32_DeviceGuard).SecurityServicesRunning
# Value 1 in the array = Credential Guard is running

# Method 2: Via registry
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\LSA" -Name LsaCfgFlags -ErrorAction SilentlyContinue
# 0 = disabled, 1 = enabled with UEFI lock, 2 = enabled without lock

# Method 3: System Information tool
# Run msinfo32.exe → System Summary → "Virtualization-based Security Services Running"
# Should show "Credential Guard" if active

# Fleet audit via PowerShell Remoting
Invoke-Command -ComputerName (Get-ADComputer -Filter * | Select -Expand Name) -ScriptBlock {
    $dg = Get-WmiObject -Namespace root\Microsoft\Windows\DeviceGuard -Class Win32_DeviceGuard -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        Computer = $env:COMPUTERNAME
        CredentialGuardRunning = ($dg.SecurityServicesRunning -contains 1)
        VBSRunning = ($dg.VirtualizationBasedSecurityStatus -eq 2)
    }
}

Enable Credential Guard via GPO (Required for Pre-Windows 11 22H2)

Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security. Set to Enabled; set Select Platform Security Level to "Secure Boot and DMA Protection" (strongest); set Credential Guard Configuration to either:

• "Enabled with UEFI lock" — prevents remote/GPO disabling; requires physical presence to turn off. Use this for PAWs and high-value systems.
• "Enabled without lock" — allows remote disable via GPO; easier to roll back if compatibility issues arise. Use this initially during phased rollout.

Detection must be tied to the specific attacks covered throughout this site. Each technique leaves different artefacts; this section maps each attack to its observable signals, relevant Event IDs, and practical detection logic. For all Windows Security Event IDs, Advanced Audit Policy Configuration must be enabled — the legacy "Audit Policy" settings are insufficient. Configure via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration.

SecurityEvent
| where EventID == 4769
| extend TicketEncryptionType = tostring(EventData.TicketEncryptionType)
| where TicketEncryptionType == "0x17"  // RC4-HMAC
| where ServiceName !endswith "$"       // Exclude machine accounts
| summarize RequestCount = count() by IpAddress, Account, bin(TimeGenerated, 1h)
| where RequestCount > 5               // Adjust threshold
| order by RequestCount desc

# Find all accounts with Kerberos pre-authentication disabled
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} `
    -Properties DoesNotRequirePreAuth, LastLogonDate, PasswordLastSet |
    Select-Object Name, SamAccountName, LastLogonDate, PasswordLastSet

# This should return 0 results in a well-managed environment

# Machines with UNCONSTRAINED delegation (TRUSTED_FOR_DELEGATION)
Get-ADComputer -Filter {TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516} `
    -Properties TrustedForDelegation, DNSHostName |
    Select-Object Name, DNSHostName
# PrimaryGroupID 516 = Domain Controllers - they legitimately have this

# Users with unconstrained delegation (should be 0)
Get-ADUser -Filter {TrustedForDelegation -eq $true} |
    Select-Object Name, SamAccountName

# Accounts with CONSTRAINED delegation - review what they can delegate to
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} `
    -Properties msDS-AllowedToDelegateTo, ServicePrincipalName |
    Select-Object Name, "msDS-AllowedToDelegateTo"

Deception-based detection creates high-confidence, low-noise alerts. Because honey accounts and honey tokens have no legitimate use, any interaction with them is definitively malicious — no tuning, no false positives. These are some of the most effective early warning mechanisms in AD environments.

Honey Accounts

Honey Credentials in Common Locations

Attackers running automated tooling often harvest credentials from common locations. Placing fake credentials in these locations creates additional tripwires:

• SYSVOL / GPP-style XML files — place a decoy Groups.xml with an obviously fake but plausible cpassword value. Alert on any authentication attempt using the decoy account.
• Web shares / file servers — credentials.txt, passwords_backup.xlsx, config.ini with fake credentials. Use Canarytokens to get alerts when the file is opened.
• LSASS memory canaries — Microsoft Defender for Identity and some EDR solutions can place dummy credentials in LSASS memory that alert when harvested

Honey SPNs for Kerberoasting Detection

BloodHound doesn't just help attackers find paths to Domain Admin — it's one of the most powerful defensive tools available for identifying and eliminating attack paths before attackers exploit them. Running BloodHound from a defensive perspective and fixing what it finds is among the highest-value hardening activities you can do.

Defensive BloodHound Workflow

# Full collection (run as a domain user from a domain-joined machine)
.\SharpHound.exe --CollectionMethods All --ZipFileName bloodhound_$(Get-Date -Format yyyyMMdd).zip

# More targeted - just ACLs and group memberships (faster, less network noise)
.\SharpHound.exe --CollectionMethods DCOnly --ZipFileName bh_dconly.zip

Custom Cypher Queries for Defenders

If you're unsure where to start, this list is ordered by impact-to-effort ratio. The top items remove the most common attack paths with the least implementation complexity.

• Critical
  Add DA, EA, Schema Admins, and named privileged accounts to Protected Users

  Blocks NTLM, RC4 Kerberos, delegation, and credential caching for privileged accounts. Do NOT add KRBTGT (breaks Kerberos domain-wide), computer accounts, or service accounts using NTLM/delegation. Test individual accounts in a lab first.
• Critical
  Enforce logon restrictions for Tier 0 accounts via GPO

  Use "Deny log on locally" and "Deny log on through Remote Desktop Services" GPO settings to prevent DA/EA credentials from ever being used on non-DC/PAW machines.
• Critical
  Deploy LAPS on all workstations and servers

  Eliminates shared local admin passwords. Prefer Windows LAPS (built-in) on modern systems. Blocks one of the most common lateral movement vectors.
• Critical
  Audit and reduce DA/EA membership

  Most environments have far more Domain Admins than needed. Each one is a potential target. Run Get-ADGroupMember "Domain Admins" -Recursive and remove all unnecessary members.
• Critical
  Verify no service accounts are members of Domain Admins or other Tier 0 groups

  A service account with DA rights running on any server means that server's compromise equals full domain compromise. Identify service accounts by SPN, naming convention (svc_, sa_), or non-interactive account type, then cross-reference DA membership. There is almost never a legitimate reason for a service account to be DA — it is virtually always a misconfiguration from initial setup that was never corrected.
• Critical
  Disable Print Spooler on all Domain Controllers

  Eliminates PrinterBug / SpoolSample coercion. The print spooler has no legitimate function on DCs. Stop-Service Spooler; Set-Service Spooler -StartupType Disabled
• High
  Enable Credential Guard on all modern workstations

  Prevents NTLM hash and TGT extraction from LSASS. Requires VBS/UEFI. Deploy via GPO: Device Guard → Turn On Virtualization Based Security.
• High
  Enable LDAP signing, channel binding, and SMB signing on DCs

  LDAP signing prevents relay of LDAP authentication; channel binding ties LDAP sessions to the TLS channel preventing relay even when signing is in place. SMB signing prevents SMB relay. The nuances of each — what exactly to enable, where, GPO paths, and what breaks — are covered in depth on the Authentication Protocols page. Also enable Extended Protection for Authentication (EPA) on ADCS web enrollment endpoints to block NTLM relay to ADCS.
• High
  Find and fix AS-REP roastable accounts

  Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} — should return zero. Enable pre-auth on every account that appears. This is quick to fix and removes an easy attack vector.
• High
  Migrate service accounts with SPNs to gMSAs

  Eliminates Kerberoasting for those accounts — 240-byte auto-rotating random passwords are computationally infeasible to crack. Run BloodHound "Kerberoastable Accounts" query to find targets.
• High
  Set "Account is sensitive and cannot be delegated" on privileged accounts that cannot join Protected Users

  If an account is already in Protected Users, this flag is completely redundant — delegation is already blocked. Only set this on accounts excluded from Protected Users (e.g., service accounts needing NTLM or longer TGT lifetimes) to prevent TGT forwarding via unconstrained delegation.
• High
  Run BloodHound and fix the shortest paths to DA

  Focus on the fewest-hop paths first. Even fixing 2-3 hop paths from non-admin users dramatically improves your security posture.
• Medium
  Deploy honey accounts with alerting

  Create 2-3 honey accounts with plausible names, SPNs, and never-used credentials. Alert on any 4624, 4625, 4768, 4769. Zero-noise, high-confidence early warning.
• Medium
  Audit unconstrained delegation

  No machines except DCs should have unconstrained delegation enabled. Find with BloodHound or: Get-ADComputer -Filter {TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516}
• Medium
  Enable and collect DS Access audit events (5136, 5137, 4662)

  Required for detecting ACL manipulation, AdminSDHolder backdoors, and DCSync. Must be enabled in Advanced Audit Policy. Send to a SIEM — these events are high value but lower volume than logon events.
• Medium
  Audit ADCS templates for ESC1 (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)

  Any template with this flag and Client Authentication EKU that Domain Users can enroll in is an immediate privilege escalation path. Run Certify or Certipy to audit.