{ "id": "d7a32ccb-7b57-41dd-a280-e0fe881861eb", "created_at": "2026-04-06T00:15:37.136201Z", "updated_at": "2026-04-10T13:12:53.669028Z", "deleted_at": null, "sha1_hash": "af93eafbb261335617ba23319cc7c09431b0bac7", "title": "The Most Dangerous User Right You (Probably) Have Never Heard Of", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 751184, "plain_text": "The Most Dangerous User Right You (Probably) Have Never\r\nHeard Of\r\nPublished: 2017-01-10 · Archived: 2026-04-05 13:29:13 UTC\r\nI find Windows user rights pretty interesting. Separate from machine/domain object DACLs, user rights govern\r\nthings like “by what method can specific users log into a particular system” and are managed under User Rights\r\nAssignment in Group Policy. Sidenote: I recently integrated privilege enumeration into PowerUp in the Get-ProcessTokenPrivilege function, with -Special returning ‘privileged’ privileges.\r\nSeEnableDelegationPrivilege\r\nOne user right I overlooked, until Ben Campbell’s post on constrained delegation, was\r\nSeEnableDelegationPrivilege. This right governs whether a user account can “Enable computer and user accounts\r\nto be trusted for delegation.” Part of the reason I overlooked it is stated right in the documentation: “There is no\r\nreason to assign this user right to anyone on member servers and workstations that belong to a domain because it\r\nhas no meaning in those contexts; it is only relevant on domain controllers and stand-alone computers.” So this\r\nright applies to the domain, not the local domain-joined machine.\r\nBen explained how SeEnableDelegationPrivilege factors into constrained delegation. This was a missing piece of\r\nthe whole puzzle for me. We both first thought that this right only governed the modification of the\r\nTRUSTED_FOR_DELEGATION and TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION flags- this\r\nwould have opened up a nifty attack that Ben outlined. Unfortunately for us attackers, it appears that this right also\r\ncontrols the modification of the msDS-AllowedToDelegateTo property, which contains the targets for constrained\r\ndelegation. If this is unclear, check out the post from last week for more background on constrained delegation.\r\nTL;DR we can’t modify delegation specific user account control settings NOR the msDS-AllowedToDelegateTo\r\nfield for targets (even if we have full control of the object) if we don’t have the SeEnableDelegationPrivilege\r\nright:\r\nhttps://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nPage 1 of 7\n\nNow the question is: how can we determine which users have this right in the domain? Since\r\nSeEnableDelegationPrivilege is applicable only on a domain controller itself, we need to check if any group\r\npolicy object applied to a domain controller modifies the user right assignments for that given DC. In most cases,\r\nthis will be the “Default Domain Controllers Policy” (GUID = {6AC1786C-016F-11D2-945F-00C04FB984F9}).\r\nThis is exactly what the Get-DomainPolicy -Source DC PowerView function will do:\r\nhttps://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nPage 2 of 7\n\nSo by default only members of BUILTIN\\Administrators (i.e. Domain Admins/Enterprise Admins/etc.) have the\r\nright to modify these delegation settings. But what happens if we can edit this GPO, or any other GPO applied to\r\nthe domain controller?\r\nWhy Care\r\nThere are a million ways to backdoor Active Directory given sufficient rights (make that a million and one : ).\r\nSean Metcalf calls these “Sneaky Active Directory Persistence Tricks“. Some of these involve ACL backdoors,\r\nsomething I’ve covered some in the past. Other approaches might require maliciously editing GPOs. Still others\r\ncould involve editing user objects. The SeEnableDelegationPrivilege approach is a bit of everything above.\r\nTL;DR: if we control an object that has SeEnableDelegationPrivilege in the domain, AND said object has\r\nGenericAll/GenericWrite rights over any other user object in the domain, we can compromise the domain at will,\r\nindefinitely.\r\nGiven elevated domain rights OR edit rights to the default domain controller GPO (something @_wald0,\r\n@cptjesus, and I are currently working on for BloodHound) for just a few minutes, you can make a single\r\nmodification to the given GPO to implement this backdoor. This GPO is located at\r\n\\\\DOMAIN\\sysvol\\testlab.local\\Policies\\{6AC1786C-016F-11D2-945F-00C04fB984F9}\\MACHINE\\Microsoft\\Windows NT\\SecEdit\\GptTmpl.inf. By adding any user SID or\r\nhttps://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nPage 3 of 7\n\nusername to the SeEnableDelegationPrivilege line of the [Privilege Rights] section, the setting will take hold\r\nwhenever the user/machine’s current DC reboots or refreshes its group policy:\r\nIf eviluser has full rights over ANY user in the domain, we can modify that user’s msDS-AllowedToDelegateTo\r\nvalue to be whatever target service we want to compromise. We can also modify the\r\nTRUSTED_TO_AUTHENTICATE_FOR_DELEGATION UAC flag if needed. In this case, let’s use\r\nldap/DOMAIN_CONTROLLER to facilitate DCSyncing at will:\r\nhttps://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nPage 4 of 7\n\nhttps://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nPage 5 of 7\n\nIf eviluser has GenericAll over any target victim, then we don’t even have to know the victim user’s password.\r\nWe can execute a force password reset using Set-DomainUserPassword to a known value and then execute the\r\nasktgt.exe/s4u.exe attack flow.\r\nObviously, from the defensive side, take note of what users have the SeEnableDelegationPrivilege privilege on\r\nyour domain controllers, through PowerView or other means. This right effectively gives those users complete\r\ncontrol of the domain, making a great ‘subtle’, but easy to detect (if you know what you’re looking for) AD\r\nbackdoor. There are obviously ways you could subvert this given SYSTEM access on a domain controller, and I\r\nwill detail methods to detect specific DACL modification in the coming weeks, but auditing these applied GPOs is\r\na great start.\r\nhttps://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nPage 6 of 7\n\nSource: https://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nhttps://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/" ], "report_names": [ "the-most-dangerous-user-right-you-probably-have-never-heard-of" ], "threat_actors": [], "ts_created_at": 1775434537, "ts_updated_at": 1775826773, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/af93eafbb261335617ba23319cc7c09431b0bac7.pdf", "text": "https://archive.orkl.eu/af93eafbb261335617ba23319cc7c09431b0bac7.txt", "img": "https://archive.orkl.eu/af93eafbb261335617ba23319cc7c09431b0bac7.jpg" } }