AD-PRIV-002: Privileged accounts that can be delegated¶

medium Privileged access MITRE ATT&CK T1558 Reads: LDAP

Privileged user accounts that are neither marked sensitive nor in Protected Users, so any service trusted for delegation can impersonate them.

Why it matters¶

Kerberos delegation lets a service act as a user towards other services. Unless an account is marked Account is sensitive and cannot be delegated or is a member of Protected Users, the KDC hands out forwardable tickets for it, and:

a host with unconstrained delegation (AD-DEL-001) receives the admin's TGT whenever the admin connects to it, and can reuse it anywhere;
a service with constrained delegation and protocol transition (AD-DEL-002) or resource-based constrained delegation (AD-DEL-003) can obtain a ticket as the admin without the admin doing anything (S4U2self + S4U2proxy).

Combined with authentication coercion, an attacker who controls one such service impersonates a Domain Admin to a domain controller (AD-CHAIN-002). Marking the account sensitive makes the KDC refuse to delegate it, which closes every one of these paths for that account.

How ad-doctor detects it¶

ad-doctor takes every enabled user account (computers and gMSA/sMSA/dMSA are skipped) that is a transitive member of a tier-0 group: Domain Admins, Schema Admins, Enterprise Admins, Administrators and the Account, Server, Print and Backup Operators, including members through primaryGroupID. An account is reported unless:

userAccountControl has the NOT_DELEGATED bit (0x100000, Account is sensitive and cannot be delegated), or
it is a transitive member of Protected Users (RID 525).

The objects are the account names, for example adm_bob, svc_sql.

Attributes and probes read

userAccountControl (NOT_DELEGATED, 0x100000)
memberOf (transitive) of the tier-0 groups and of Protected Users
primaryGroupID

Severity¶

Always medium. The account can be impersonated only through a delegation-enabled service the attacker already controls, but once that is the case, the result is a tier-0 identity.

False positives and limits¶

Service accounts in tier-0 groups sometimes need to be delegated by a front-end service. That is a design problem rather than a false positive: take the account out of tier 0, then the check stops reporting it.
The built-in Administrator (RID 500) is reported like any other admin; Microsoft recommends marking it sensitive as well.

Fix¶

List the privileged accounts that can still be delegated. adminCount = 1 is a quick approximation of "privileged"; the finding has the exact list.

Get-ADUser -LDAPFilter '(&(adminCount=1)(!(userAccountControl:1.2.840.113556.1.4.803:=1048576)))' |
    Select-Object SamAccountName, DistinguishedName

Mark each one sensitive (the same command ad-doctor writes with --fixes):
```
Set-ADAccountControl adm_bob -AccountNotDelegated $true -WhatIf
```
Add administrators to Protected Users as well, after testing that they do not depend on NTLM, RC4 or DES (AD-PRIV-010). Do not add service accounts or computer accounts:
```
Add-ADGroupMember 'Protected Users' -Members adm_bob -WhatIf
```
Reduce the delegation itself: remove unconstrained delegation from anything that is not a DC and review constrained and resource-based delegation (AD-DEL-001, AD-DEL-004).

Verify¶

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-PRIV-002

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-PRIV-002"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

References¶

Microsoft and vendors

Research

Active Directory Security Risk #101: Kerberos unconstrained delegation (Sean Metcalf)

MITRE ATT&CK

T1558

Available since 0.1.0.