| Previous | Next |
| STATUS_HANDLES_CLOSED | STATUS_GUID_SUBSTITUTION_MADE |
STATUS_NO_INHERITANCE
Inheritance depends on ACE flags, object type, and protection state
STATUS_NO_INHERITANCE is about ACL propagation, not about whether the parent has a DACL at all. An ACL can contain many explicit ACEs yet provide nothing that may be inherited by a newly created child. For container hierarchies, inheritance is controlled by flags in each ACE header, including OBJECT_INHERIT_ACE, CONTAINER_INHERIT_ACE, NO_PROPAGATE_INHERIT_ACE, and INHERIT_ONLY_ACE.
Windows also distinguishes ordinary ACE inheritance from automatic propagation performed by security-descriptor APIs. Object-specific ACEs can carry GUIDs that limit inheritance to particular child object types. A parent ACL can therefore look inheritable in a raw dump while still yielding no applicable ACEs for the child type being created. Protected DACL/SACL control flags are another reason not to infer the result from the parent ACL text alone.
Diagnosis should compare the parent ACL, the child object type, and the security-descriptor control flags used by the creation path. Dump each ACE type and inheritance flags before and after the security API runs. Do not “fix” the status by copying every parent ACE as an explicit ACE: that changes future propagation behavior and can freeze permissions that were intended to follow the hierarchy.
What to inspect
- Inspect ACE inheritance flags rather than merely counting ACEs in the parent ACL.
- For object-specific ACEs, record the inherited-object GUID and the child object type being created.
- Check whether the child descriptor is protected from inheritance before changing ACL contents.
References
- Microsoft: ACE inheritance rules
- Microsoft: Automatic propagation of inheritable ACEs
- Microsoft: Object-specific ACEs
- Microsoft: CreatePrivateObjectSecurityEx
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.