Search/ GitHub
PW-008HygieneKerberos, passwords and credentials

Tier Zero accounts without delegation protection

Tier Zero user accounts are neither in Protected Users nor marked sensitive, so their credentials can be cached and delegated.

Category
Hygiene
Severity
Medium.
Typical owner
AD / identity team
Data needed
Any collection: Protected Users membership and the sensitive flag are directory data.
MITRE ATT&CKT1558T1003.001
Most useful toDefensive engineersIdentity and access engineersAuditors
On this page

In plain language

Windows has two switches that make privileged accounts much harder to abuse. The Protected Users group stops a member's credentials from being cached in reusable forms and blocks delegation and older, weaker protocols. The "Account is sensitive and cannot be delegated" flag at least blocks delegation.

Admin accounts without either are easier to steal and impersonate. Adding them is low-cost hardening, but test service accounts first: Protected Users disables NTLM, among other things.

What Pathwarden flags

These Tier Zero user accounts are neither members of the Protected Users group nor marked "Account is sensitive and cannot be delegated". Their credentials can therefore be cached on the computers they log on to, and their Kerberos tickets can be forwarded by any service trusted for delegation.

How attackers use it

An attacker who controls a server trusted for unconstrained or constrained delegation can impersonate any delegatable account that authenticates to it, including Domain Admins (Kerberos delegation abuse, MITRE ATT&CK T1558). Accounts outside Protected Users also leave NTLM hashes and long-lived credentials in LSASS memory, which tools like Mimikatz extract (OS Credential Dumping, T1003.001). Protected Users removes both of these options for its members.

Find it with Pathwarden

Data needed: Any collection: Protected Users membership and the sensitive flag are directory data.

In the web UI or the HTML report, open the Findings tab and expand PW-008: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-008
# the step-by-step guide on this page, offline
pathwarden guide PW-008
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-008

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

  • Protected Users members cannot use NTLM, DES or RC4 Kerberos encryption, Kerberos delegation, or cached (offline) logons, and their Kerberos TGTs last 4 hours. Anything that relies on these will break for the account.
  • Never add service accounts or computer accounts to Protected Users. Use the "sensitive and cannot be delegated" flag (Option B) for service accounts that are Tier Zero.
  • Check for NTLM use by the account first: enable NTLM auditing ("Network security: Restrict NTLM: Audit NTLM authentication in this domain") and review event 8004 on domain controllers, or 4624 events with Authentication Package NTLM.
  • Make sure the domain functional level is Windows Server 2012 R2 or later. Protected Users only takes full effect from that level.
  • Keep at least one break-glass account outside Protected Users in case Kerberos fails. Store its password offline.

How to fix it

  1. Open Active Directory Users and Computers (dsa.msc).
  2. Go to the Users container and open the Protected Users group.
  3. Members tab > Add. Add one test admin account first.
  4. Sign out and sign back in with that account. Confirm your admin tools still work.
  5. Add the remaining interactive Tier Zero admin accounts listed in the finding.

Option B: Mark the account "sensitive and cannot be delegated"

Use this for accounts that cannot join Protected Users, such as Tier Zero service accounts.

  1. In dsa.msc, open the account > Account tab.
  2. Under Account options, tick Account is sensitive and cannot be delegated.
  3. Click OK.

PowerShell

PowerShell
Import-Module ActiveDirectory

# Option A: add an interactive admin account to Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "<Account>"

# Option B: block delegation for an account that cannot join Protected Users
Set-ADUser -Identity "<Account>" -AccountNotDelegated $true

Verify the fix

PowerShell
# Members of Protected Users
Get-ADGroupMember -Identity "Protected Users" | Select-Object SamAccountName

# Accounts flagged as not delegatable
Get-ADUser -Identity "<Account>" -Properties AccountNotDelegated |
    Select-Object SamAccountName, AccountNotDelegated

Collect again (or use Retest on the finding) and confirm the finding ID is gone (or lists fewer accounts).

Roll back

  • Remove the account from the group: Remove-ADGroupMember -Identity "Protected Users" -Members "<Account>". The change applies at the account's next logon. Existing tickets expire within 4 hours.
  • Clear the flag: Set-ADUser -Identity "<Account>" -AccountNotDelegated $false.

References

  1. Microsoft: Protected Users security grouplearn.microsoft.com
  2. Microsoft: How to configure protected accountslearn.microsoft.com
  3. MITRE ATT&CK T1558: Steal or Forge Kerberos Ticketsattack.mitre.org
  4. MITRE ATT&CK T1003.001: OS Credential Dumping: LSASS Memoryattack.mitre.org

↑↓ to moveEnter to openEsc to close