| Previous | Next |
| ERROR_SERVER_SID_MISMATCH | ERROR_FLOAT_MULTIPLE_FAULTS |
ERROR_CANT_ENABLE_DENY_ONLY
What this result means
ERROR_CANT_ENABLE_DENY_ONLY is a Windows system result. Deny-only groups participate only in access-denial checks. Windows intentionally prevents callers from converting such a group into an enabled allow group because that would bypass token restriction semantics.
Likely causes
- code attempts to enable every group without inspecting attributes
- a restricted token is being modified as though it were a normal primary token
- impersonation or sandbox policy deliberately converted a group to deny-only
- the wrong token was selected for adjustment
How to diagnose it
Capture token type, impersonation level, group SID and attributes, restriction source, caller privileges, and the intended access operation. Compare the selected token with the process or thread token expected by the design.
Correct handling
Do not try to override deny-only state. Obtain a correctly constructed token through authentication or supported service configuration, or redesign the operation to work within the restricted identity.
Where this code is usually encountered
- Token-adjustment code tries to enable every group indiscriminately.
- A restricted token converted a SID to deny-only as part of sandboxing or least privilege.
- The caller adjusts a thread or duplicated token different from the identity it intended.
Evidence worth collecting
- token type, source, integrity level, and impersonation level
- the target SID and complete group attributes
- restricted SIDs, privileges, and token-creation path
- the access check or operation the caller hoped to enable
Practical diagnostic sequence
- Inspect the group attributes before calling AdjustTokenGroups.
- Trace token selection across impersonation boundaries and asynchronous work.
- Determine why the group became deny-only; this normally comes from token construction, not a transient state.
- Create or obtain the correct token through supported authentication rather than mutating a restricted one.
Guidance for developers
Treat deny-only as an invariant. Code that enumerates groups must branch on SE_GROUP_USE_FOR_DENY_ONLY and should never promise that arbitrary groups can be enabled.
Guidance for administrators
Changing local group membership may not alter an already issued restricted token. Correct the service, logon, or sandbox configuration and start a new security context.
How to interpret it correctly
A disabled ordinary group can sometimes be enabled. A deny-only group is intentionally prevented from granting access and cannot be converted in place.
Example failure pattern
For example, CreateRestrictedToken can convert a group to deny-only so that its SID still participates in deny ACE evaluation but cannot satisfy allow ACEs. A later generic “enable all groups” routine violates that intentional restriction and receives this result.
Retry and recovery policy
There is no transient condition to wait out. Acquire a newly authenticated or correctly constructed token, then repeat the business operation under that identity; never loop on AdjustTokenGroups.
Suggested telemetry
For ERROR_CANT_ENABLE_DENY_ONLY, record the operation name, component version, process and thread identity, the original numeric result, the immediately preceding state transition, and a correlation identifier. Keep the ERROR_CANT_ENABLE_DENY_ONLY event separate from later fallback failures so its first actionable cause remains searchable across machines.
References
Looking for a different code? Search another status or error code.