Hi Nadezhda: We have identified the flaw in the algorithm and as soon as I have the final version of the algorithm, I’ll be in touch. Your finding is correct and algorithm needs modification.
Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft From: Nadezhda Ivanova [mailto:[email protected]] Sent: Monday, July 27, 2009 6:45 AM To: Obaid Farooqi Cc: [email protected]; [email protected] Subject: RE: Help regarding the security descriptor creation algorithms Hi Obaid, I was wandering if there is any progress on this issue? Regards, Nadezhda Ivanova ________________________________ From: Obaid Farooqi [mailto:[email protected]] Sent: Wednesday, July 15, 2009 7:55 PM To: Nadezhda Ivanova Cc: [email protected]; [email protected] Subject: RE: Help regarding the security descriptor creation algorithms Hi Nadezhda: Just an update. I am still working on your issue. I’ll update you as soon as I have something concrete. Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft From: Obaid Farooqi Sent: Friday, July 10, 2009 10:47 AM To: 'Nadezhda Ivanova' Cc: [email protected]; [email protected] Subject: RE: Help regarding the security descriptor creation algorithms Hi Nadezhda: My name is Obaid Farooqi and I am a member of protocol documentation team. I’ll be helping you with your question regarding security descriptor creation algorithms. I’ll keep you updated as appropriate with my investigation. Feel free to contact me if you have any further question or clarification about this issue. Regards, Obaid Farooqi Sr. SEE | Microsoft From: Nadezhda Ivanova [mailto:[email protected]] Sent: Friday, July 10, 2009 6:09 AM To: Interoperability Documentation Help Cc: [email protected]; [email protected] Subject: Help regarding the security descriptor creation algorithms Hi, I have been working on implementing correct nTSecurityDeascriptor creation in the directory service of Samba 4, and have come upon a problem in the ComputeInheritedACLfromParent subroutine described in MS-DTYP 2.5.2.6. The way the algorithm is described, the purpose of this algorithm is to determine which ACE’s from an object’s parent are to be inherited by the new object actively, and which are to be inherited only. The ComputeInheritedACLfromParent as described, walks the parent ACL twice. The first time it determines the active inherited ACE’s, the second time the ones that are inherited but inactive. I have been testing our implementation with the CN=Schema partition, as the attributes and objects by default are not given a security descriptor during creation, and the defaultSecurityDescriptor of attribute-Schema is empty DACL and SACL. So, they inherit all their DACL ACE’s from their parent, CN=Schema. In a Win2008R2, CN=Schema has three inheritable DACL ACE’s: (A;CI;RPLCLORC;;;AU) (A;CI;RPWPCRCCLCLORCWOWDSW;;;SA) (A;CI;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY) ComputeInheritedACLfromParent has the following arguments: ACL: ACL that contains the parent's ACEs from which to compute the inherited ACL. IsContainerObject: TRUE if the object is a container, FALSE otherwise. ObjectTypes: Array of GUIDs for the object type being created. So if we invoke the ComputeInheritedACLfromParent with the above DACL,and isConatinerObject = true (According to MS-ADTS 7.1.3, true is always the value), the first walk of the input Initialize ExplicitACL to Empty ACL FOR each ACE in ACL DO IF ACE.Flags contains INHERIT_ONLY THEN CONTINUE ENDIF IF(((ACE.Flags contains CONTAINER_INHERIT) AND (IsContainerObject = TRUE))OR ((ACE.Flags contains OBJECT_INHERIT) AND (IsContainerObject = FALSE))) THEN CASE ACE.Type OF ALLOW: DENY: Set NewACE to ACE Set NewACE.Flags to INHERITED Append NewACE to ExplicitACL OBJECT_ALLOW: OBJECT_DENY: IF (ObjectTypes contains ACE.ObjectGUID) THEN Set NewACE to ACE Set NewACE.Flags to INHERITED Append NewACE to ExplicitACL ENDIF ENDCASE ENDIF END FOR Will give: D:AI(A;CIID;RPLCLORC;;;AU)(A;CIID;RPWPCRCCLCLORCWOWDSW;;;SA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY) Which is as expected, as this is the DACL of all attributes and classes in Win 2008. However, the algorithm then walks the input a second time: Initialize InheritableACL to Empty ACL IF (IsContainerObject = TRUE) THEN //In our case this is always true FOR each ACE in ACL DO IF ACE.Flags contains NO_PROPAGATE THEN //This flag is not set CONTINUE ENDIF IF((ACE.Flags contains CONTAINER_INHERIT) OR (ACE.Flags contains OBJECT_INHERIT)) THEN Set NewACE to ACE Add INHERITED to NewACE.Flags Add INHERIT_ONLY to NewACE.Flags Append NewACE to InheritableACL ENDIF END FOR ENDIF This second loop yields: (A;CIIOID;RPLCLORC;;;AU)(A;CIIOID;RPWPCRCCLCLORCWOWDSW;;;SA)(A;CIIOID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY) Which after: RETURN concatenation of ExplicitACL and InheritableACL Makes the final DACL look like: D:AI(A;CIID;RPLCLORC;;;AU)(A;CIID;RPWPCRCCLCLORCWOWDSW;;;SA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;CIIOID;RPLCLORC;;;AU)(A;CIIOID;RPWPCRCCLCLORCWOWDSW;;;SA)(A;CIIOID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY) So ACE’s are duplicated. However, an attribute’s DACL in Win2008 does not have these last three ACE’s, so I am obviously missing something. How should the flow actually go with this same example in order to avoid this duplication? Or am I providing the wrong argument? Best Regards, Nadezhda Ivanova [cid:[email protected]] Nadezhda Ivanova Software Engineer Software Development [email protected]<mailto:[email protected]> CISCO SYSTEMS BULGARIA EOOD 18 Macedonia Blvd. Sofia 1606 Bulgaria Cisco home page<http://www.cisco.com/global/BG/> [Think before you print.]Think before you print.
<<inline: image001.gif>>
<<inline: image002.gif>>
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
