Understanding the "Account is sensitive and cannot be delegated" Flag in Active Directory

the "account is sensitive and cannot be delegated" flag is a critical security feature in active directory that prevents certain user accounts from being subject to kerberos delegation this setting plays a vital role in protecting high privilege accounts from potential security risks associated with delegation attacks what is kerberos delegation? kerberos delegation allows a service to impersonate a user when accessing other services on their behalf using kerberos tickets , not stored credentials this is a crucial distinction the delegating service never sees or stores the user's password instead, it receives a delegable kerberos ticket from the domain controller that allows it to request service tickets for backend services on behalf of the user this ticket based impersonation enables seamless single sign on experiences and service to service authentication, but also introduces potential security vulnerabilities when delegation is enabled, a compromised service could potentially access resources using the delegated tickets of any user who has authenticated to that service the sensitive account flag explained when the "account is sensitive and cannot be delegated" flag is set on a user account, active directory explicitly prevents that account from being delegated to any service this means that even if a service is configured to use delegation, it cannot impersonate this particular user account to access other resources the flag corresponds to the not delegated attribute in active directory and can be found in the user account properties under the account tab when enabled, it sets the ads uf not delegated flag in the useraccountcontrol attribute why use this flag? this security control is particularly important for protecting high privilege accounts such as domain administrators, enterprise administrators, and service accounts with elevated permissions these accounts are prime targets for attackers, and preventing their delegation reduces the attack surface significantly consider a scenario where a domain administrator logs into a web application that uses kerberos delegation without the sensitive account flag, if that web server becomes compromised, an attacker could potentially use the delegated kerberos tickets to access domain resources with administrative privileges by marking the account as sensitive, this ticket delegation path is blocked entirely important note this flag specifically prevents kerberos ticket delegation , not scenarios where applications store and reuse user credentials (which would be a separate security concern) in true kerberos delegation, the delegating service never sees or stores the user's password it only receives delegable tickets from the domain controller when to enable the flag you should consider enabling this flag for accounts that have elevated privileges within your environment, including domain administrators enterprise administrators schema administrators service accounts with broad permissions across infrastructure it security personnel accounts users with access to sensitive systems however, be cautious when applying this flag to service accounts that legitimately require delegation functionality enabling it on such accounts will break their intended functionality and could cause application failures implementation considerations before implementing this flag widely, conduct a thorough analysis of your environment to identify which accounts truly require delegation capabilities document any legitimate business requirements for delegation and ensure that alternative authentication mechanisms are available where needed testing is crucial when deploying this flag start with a small subset of accounts in a non production environment to validate that no critical services are disrupted monitor authentication logs and application behavior to identify any unexpected issues managing the flag the flag can be managed through several methods including active directory users and computers, powershell cmdlets, and group policy for large scale deployments, powershell provides efficient bulk management capabilities \# enable the flag for a single user set aduser identity "username" accountnotdelegated $true \# disable the flag for a single user set aduser identity "username" accountnotdelegated $false \# check current status get aduser identity "username" properties accountnotdelegated | select name, accountnotdelegated \# bulk enable for multiple users get aduser filter "memberof eq 'cn=domain admins,cn=users,dc=contoso,dc=com'" | set aduser accountnotdelegated $true group policy can also be used to automatically apply this setting to members of specific security groups, providing centralized management for sensitive accounts monitoring and auditing regular auditing of accounts with this flag is essential to ensure it remains appropriately configured as organizational roles change and new accounts are created, the delegation settings should be reviewed and updated accordingly you can create reports to monitor accounts with this flag \# find all accounts with the sensitive flag enabled get aduser filter "accountnotdelegated eq $true" properties accountnotdelegated, lastlogondate | select name, samaccountname, accountnotdelegated, lastlogondate | export csv path "sensitiveaccounts csv" notypeinformation implement monitoring to detect any unauthorized changes to these security settings through security log analysis and change tracking tools limitations and alternatives while this flag provides valuable protection, it's not a complete security solution it only prevents kerberos delegation and doesn't protect against other attack vectors organizations should implement comprehensive security measures including proper privilege management regular access reviews network segmentation multi factor authentication privileged access management (pam) solutions for environments requiring both security and delegation functionality, consider implementing constrained delegation limits delegation to specific services resource based constrained delegation provides more granular control over delegation permissions protocol transition allows services to obtain kerberos tickets without requiring the user's password best practices regular review periodically review which accounts have this flag enabled and ensure it's still appropriate documentation maintain clear documentation of why specific accounts have this flag enabled testing always test in non production environments before implementing changes monitoring implement comprehensive logging and monitoring of authentication events least privilege apply the principle of least privilege when determining which accounts need this protection troubleshooting common issues if applications break after enabling this flag, common troubleshooting steps include verify the account actually requires delegation for legitimate business purposes check application logs for authentication failures consider alternative authentication methods implement constrained delegation instead of disabling the flag entirely real world delegation examples understanding where delegation is used in practice helps clarify why the sensitive account flag is important web applications with backend databases a classic example is sharepoint or custom web applications where users authenticate to the web app with their ad credentials, the web application receives a delegable kerberos ticket (not the user's password), uses this ticket to access sql server as the original user, and sql server sees the end user's identity for proper auditing and row level security if the web server becomes compromised, an attacker could use the delegated tickets of any recently authenticated user to access backend services sharepoint and office 365 integration users access sharepoint sites which then use delegated kerberos tickets to access exchange for calendar integration or other sharepoint farms this provides seamless access without re authentication, but creates risk if sharepoint services are compromised since the attacker could use active delegated tickets reporting services (ssrs) when users request reports through a web portal, ssrs uses delegated kerberos tickets to connect to sql server, so reports run with the user's permissions and show only data they should see while maintaining the security context throughout the chain multi tier applications in three tier architectures (user → web server → application server → database), each hop maintains the original user's identity through kerberos ticket delegation , ensuring database audit logs show actual end users rather than generic service accounts file server access via web apps document management systems or intranet portals use delegated kerberos tickets to access file shares, allowing file system acls to apply based on the actual user's permissions rather than the web application's service account frequently asked questions does this flag prevent remote powershell usage? no, the "account is sensitive and cannot be delegated" flag does not prevent remote powershell usage this flag specifically blocks kerberos delegation, while remote powershell (winrm) uses different authentication mechanisms including direct authentication, credssp, basic authentication over https, or certificate based authentication a user or service account with this flag set can still use enter pssession, invoke command, authenticate directly to remote systems, and run powershell commands remotely the flag would only interfere if a web service was trying to use kerberos delegation to impersonate that account and then run powershell commands on the user's behalf, which is a much less common scenario should i set this on elevated service accounts? this depends on the service account's role set the flag on service accounts that you want to protect from being delegated to (like sql service accounts with sysadmin privileges, exchange service accounts, or backup service accounts with broad access) however, do not set this flag on service accounts that need to perform delegation themselves (like web application pools or sharepoint app pools that need to delegate user credentials to backend services) conclusion the "account is sensitive and cannot be delegated" flag represents an important defense in depth security control for active directory environments by preventing high privilege accounts from being subject to kerberos delegation, organizations can significantly reduce their exposure to credential theft and lateral movement attacks however, successful implementation requires careful planning, testing, and ongoing management to ensure both security objectives and business functionality are maintained this flag should be part of a broader active directory security strategy that includes regular security assessments, proper account lifecycle management, and comprehensive monitoring of authentication activities throughout your environment remember that security is a balance between protection and functionality while this flag provides excellent protection for sensitive accounts, it should be implemented thoughtfully with proper testing and documentation to ensure it enhances rather than hinders your organization's security posture