“Account is sensitive and cannot be delegated” is an Active Directory account option (the NOT_DELEGATED userAccountControl flag, 0x100000) that stops Kerberos from delegating that account’s identity to any service. Scanners flag privileged accounts without it. To fix it, enable the flag on every admin account with Set-ADAccountControl -AccountNotDelegated $true, or add human admins to Protected Users.

It is one of the cheapest directory fixes available: the account signs in and works exactly as before, minus delegation it should never need.

What the scanner is actually detecting

This is a directory configuration finding, not a host vulnerability. Both tools read the userAccountControl attribute of members of privileged groups and report those without the NOT_DELEGATED bit (hex 0x100000, decimal 1048576). In Active Directory Users and Computers the bit is the Account tab option Account is sensitive and cannot be delegated.

Scanner	Finding	What triggers it
Microsoft Defender for Identity	Ensure privileged accounts are not delegated (Secure Score assessment)	Privileged accounts, meaning members of groups such as Domain Admins and Enterprise Admins plus service accounts with elevated privileges, that do not have the “not delegated” setting. It can list both user and device accounts.
PingCastle	P-Delegated, “At least one administrator account can be delegated”	Enabled members of the groups in the report’s Admin Groups section that lack the flag and are not in Protected Users. The rationale gives a count; each detail line shows the DN and a reason.

PingCastle’s rule source adds useful detail. It maps the rule to DISA STIG V-243470 (“Delegation of privileged accounts must be prohibited”). It skips group managed service accounts (gMSAs) and any accounts you declared as honeypots. Protected Users membership counts as a fix only when the schema is at least version 69 (Windows Server 2012 R2); below that, members are still listed with the reason Schema too low. Otherwise the reason reads Not a protected user.

Real-world risk, stated honestly

Kerberos delegation lets a service act as a user toward other services. Without the flag, several delegation setups can be turned against an admin account:

Unconstrained delegation: when the admin authenticates to a service on a host trusted for unconstrained delegation, the admin’s TGT is handed to that host, and whoever controls the host can reuse it.
Constrained and resource-based constrained delegation: a service account or computer that an attacker controls, and that is allowed to delegate to a target service, can request tickets to that service in the admin’s name. With protocol transition, the admin does not even have to connect first.

PingCastle’s summary is that without the flag, any account can be impersonated by some service account. Defender for Identity calls the flag a way to ensure these accounts cannot be impersonated through delegation.

The limits matter too. The flag does nothing against pass-the-hash, Kerberoasting, or theft of credentials from memory on a machine where the admin signs in interactively; for that, see our guide to LSASS protection with Credential Guard and RunAsPPL. Nor does it fix servers trusted for delegation, which keep collecting other users’ tickets.

How to confirm it

Run this from a machine with the RSAT Active Directory module. It lists enabled members of common privileged groups that do not have the flag:

Import-Module ActiveDirectory

$groups = 'Domain Admins','Enterprise Admins','Schema Admins','Administrators',
          'Account Operators','Backup Operators','Server Operators','Print Operators'

$privileged = foreach ($g in $groups) {
    Get-ADGroupMember -Identity $g -Recursive -ErrorAction SilentlyContinue
}
$privileged = $privileged | Sort-Object distinguishedName -Unique

# Enabled privileged accounts without NOT_DELEGATED (0x100000)
$privileged | ForEach-Object {
    Get-ADObject -Identity $_.distinguishedName -Properties sAMAccountName,userAccountControl
} | Where-Object {
    ($_.userAccountControl -band 0x100000) -eq 0 -and ($_.userAccountControl -band 0x2) -eq 0
} | Select-Object Name, ObjectClass, sAMAccountName, userAccountControl

# Who is already in Protected Users
Get-ADGroupMember -Identity 'Protected Users' | Select-Object Name, objectClass

Enterprise Admins and Schema Admins exist only in the forest root domain, which is why errors are suppressed. Run the script in each domain, and extend the group list to match what your scanner treats as privileged. For a wider net, this query finds user accounts that were ever protected by AdminSDHolder and still lack the flag:

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

adminCount is not cleared when an account leaves a protected group, so this list can include former admins. Those are worth cleaning up either way.

How to fix it

1. Record the current state

$privileged | ForEach-Object {
    Get-ADObject -Identity $_.distinguishedName -Properties sAMAccountName,userAccountControl
} | Select-Object DistinguishedName, sAMAccountName, ObjectClass, userAccountControl |
    Export-Csv .not-delegated-before.csv -NoTypeInformation

Microsoft advises against applying the flag to an account that needs delegation for a legitimate business purpose until that delegation is redesigned. For a human admin account, that should be rare.

2. Set the flag on privileged user accounts

In Active Directory Users and Computers, open the account, go to the Account tab and, under Account options, select Account is sensitive and cannot be delegated. For one account in PowerShell:

Set-ADUser -Identity adm-jsmith -AccountNotDelegated $true

For every privileged user account at once, preview first:

$users = $privileged | Where-Object objectClass -eq 'user'
$users | ForEach-Object { Set-ADAccountControl -Identity $_.distinguishedName -AccountNotDelegated $true -WhatIf }
$users | ForEach-Object { Set-ADAccountControl -Identity $_.distinguishedName -AccountNotDelegated $true }

Include the built-in Administrator and your break-glass account. Microsoft’s own guidance for securing the built-in Administrator account lists this flag, and it does not stop the account from signing in.

3. Computer accounts and gMSAs

First ask why a computer account is in a privileged group at all; removing it is usually the better fix. If it has to stay, Defender for Identity documents this command:

Get-ADComputer -Identity ComputerA | Set-ADAccountControl -AccountNotDelegated $true

The GUI alternative is to add NOT_DELEGATED (1048576) to userAccountControl on the Attribute Editor tab (enable View > Advanced Features first). gMSAs have no checkbox either; PingCastle suggests the same manual addition, or pipe Get-ADServiceAccount into Set-ADAccountControl the same way.

4. Optionally, add human admins to Protected Users

PingCastle accepts Protected Users membership instead of the flag (its documentation asks for Windows Server 2012 R2 domain functional level or higher). Members cannot be delegated, but they also lose NTLM, RC4, DES, offline sign-in and TGT renewal beyond four hours, so pilot it with one admin first. Never add service or computer accounts.

5. Keep new admins covered

The flag is not inherited from group membership, so every new admin account needs it. Add it to your account creation procedure, and with Audit User Account Management enabled on domain controllers, alert on event 4738 showing ‘Not Delegated’ – Disabled for any admin account.

How to verify the fix and rescan

Check a single account: Get-ADUser adm-jsmith -Properties AccountNotDelegated | Select-Object SamAccountName, AccountNotDelegated should return True.
Re-run the confirmation script. It should return nothing, or only accounts you have documented.
Have the admin sign out and back in (or run klist purge), then run klist in their session. Microsoft’s Kerberos specification (MS-KILE) says the KDC must not set the forwardable flag on tickets for such an account, so the krbtgt ticket’s Ticket Flags line should not include forwardable.
Let replication finish (repadmin /showrepl) before rescanning, since the scanner may query a different DC.
Rescan. Run a new PingCastle health check (PingCastle.exe –healthcheck –server contoso.local) and confirm P-Delegated is gone. In Defender for Identity, the exposed entity list updates within minutes, but Microsoft notes that scores and statuses update every 24 hours.

What can break and how to roll back

Only workflows that delegate the admin’s own identity. Microsoft’s PowerShell remoting documentation notes that accounts with this flag cannot be delegated through constrained or resource-based constrained delegation, so a second hop that relied on either one (for example, reaching a file share from inside a remote session) now fails with access denied. Web-based admin consoles that use Windows authentication and query a back end as the signed-in user behave the same way. The documented alternatives are Just Enough Administration (JEA), a session configuration with a RunAs account, or passing credentials explicitly to the second Invoke-Command.

Rollback for one account, or for everything recorded in step 1:

Set-ADAccountControl -Identity adm-jsmith -AccountNotDelegated $false

Import-Csv .not-delegated-before.csv |
    Where-Object { ([int]$_.userAccountControl -band 0x100000) -eq 0 } |
    ForEach-Object { Set-ADAccountControl -Identity $_.DistinguishedName -AccountNotDelegated $false }

After replication, the account needs new tickets (sign out and back in, or klist purge). Protected Users is undone with Remove-ADGroupMember.

Common false positive reasons

Protected Users members in Defender for Identity. PingCastle accepts membership, but the Defender for Identity assessment is described in terms of the flag itself. Setting the flag as well clears both.
Schema too low. PingCastle lists Protected Users members with this reason when the schema predates Windows Server 2012 R2. The finding is real; set the flag.
Honeypot accounts. PingCastle skips accounts declared as honeypots in its configuration; other tools list them.
Disabled or stale admin accounts. PingCastle only counts enabled members. Remove old accounts from privileged groups rather than accepting them.
Stale data. The scan ran before replication or before the next Secure Score refresh.

FAQ

Does the flag stop the admin from signing in?

No. Microsoft states it does not affect the account’s ability to sign in or its permissions. It only applies to Kerberos delegation.

Is Protected Users better than the flag?

It does more, since it also blocks NTLM, weak Kerberos encryption and credential caching, but it has side effects and cannot be used for service or computer accounts. The flag is safe for every admin account; Protected Users is an addition for human admins.

Should service accounts get the flag?

Defender for Identity recommends it for service accounts with elevated privileges. Test first, and skip any account whose identity must be delegated until that design changes.

Does this fix unconstrained delegation findings?

No. It protects the flagged accounts only. Hosts trusted for unconstrained delegation still receive other users’ TGTs and need their own fix.

Tracking this finding across many hosts

This finding tends to come back whenever a new admin account is created, so it is worth tracking over time rather than closing once. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and merges duplicates per scanner, not across scanners, so an account reported by two tools appears once for each. Its AI triage can suggest a false positive, such as a declared honeypot account, with evidence, and a human makes the decision.

Discovery and visibility

Scanning and collection

The AI layer

Action and closure

Team and governance

Reporting

Account Is Sensitive and Cannot Be Delegated: Fixing “Ensure Privileged Accounts Are Not Delegated”