6.1.3.3 Processing Specifics

  • Artikel

  1. The clients might send in SD values that include both explicit and inherited ACEs (during add or modify operations). Only the set of explicit ACEs is considered authoritative data. Any inherited ACEs that are included in the SD value are ignored. Instead, the set of inherited ACEs is computed per the rules in the preceding sections and set on the object.

  2. During an add operation, the DC makes sure that the object's security descriptor value is consistent with the parent's SD value (according to the preceding rules), at the moment when the add operation is committed.

  3. During a move operation, the DC makes sure that the moved object's security descriptor value is consistent with the new parent's SD value (according to the preceding rules), at the moment when the move operation is committed. If the moved object has descendant objects (that is, a tree move was performed), then the SD values of the children objects are updated outside of the move transaction (see Modify DN, section 3.1.1.5.4).

  4. During an SD modify operation, the DC ensures that the updated object's security descriptor value is consistent with the parent's SD value (according to the preceding rules), at the moment when the modify operation is committed. If the updated object has descendant objects, then the SD values of the children objects are updated outside of the modify transaction.

  5. When processing inbound replication containing SD updates, the SD requirements are enforced (in other words, it is not guaranteed that the SD value sent by the replication partner is consistent with the parent's SD value). It is the responsibility of the DC performing the inbound replication to ensure that the set of inherited ACEs present in the SD is consistent in the subtree that is rooted at the affected object (according to the preceding rules). One exception to this rule is when processing inbound replication of a deleted object. In this case, the DC retains the SD value (including both explicit and inherited ACEs) as it is supplied by the replication partner, in cases when it is supplied by the replication partner. If the SD value is not supplied by the replication partner, then the existing SD value is retained.

  6. When an originating add operation is processed, the client might or might not supply an SD value. If the SD value is not supplied, then the DACL and SACL on the newly created object are defaulted according to the SD defaulting rules (section 6.1.3.6). If the SD value is present, then the DACL and SACL are obtained from this value. If the DACL is not present in the supplied value, then the add operation is failed with unwillingToPerform / <unrestricted>  (per the preceding constraint). If the SACL is not present in the supplied value, then a NULL value is written in place of this SACL.

  7. If the RM control field is present in the supplied SD value, then its value is reset to contain the SECURITY_PRIVATE_OBJECT bit, and nothing else.

  8. AD LDS imposes a restriction on the security principals that can be used in an AD LDS security descriptor (owner, group, and SID values within ACEs). The SID of a security principal within an AD LDS application NC can appear in a security descriptor within that application NC, but cannot appear in a security descriptor within any other NC of the same forest. Other SIDs are not restricted, so for instance a Windows security principal is allowed in any AD LDS security descriptor, as is a security principal from another AD LDS forest, as well as a security principal from the config NC of the same AD LDS forest.

  9. Windows Server 2008 R2 operating system and later impose a restriction on modifying the OWNER field. If a modify operation attempts to set the OWNER SID to a value, the operation will fail with a constraintViolation / ERROR_INVALID_OWNER error unless at least one of the following conditions applies.

    Let U be the user performing the modify operation:

    • U.SID equals OWNER SID.

    • Let G be a group in U.Groups whose SID is being set in the OWNER field. G.Attributes contains SE_GROUP_OWNER but not SE_GROUP_USE_FOR_DENY_ONLY.

    • U.Privileges contains SE_RESTORE_PRIVILEGE.

    This restriction is processed before the security checks described in section 6.1.3.5.