[cifs-protocol] Information needed about security token default ACL

Edgar Olougouna edgaro at microsoft.com
Mon Aug 10 13:34:02 MDT 2009


Hi Nadezhda,

Thanks for your new question. One of my colleagues will contact you soon (if not already done), and will be working with you to address this inquiry.

Best regards,

Edgar


From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
Sent: Monday, August 10, 2009 4:48 AM
To: Edgar Olougouna
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Information needed about security token default ACL

Hi Edgar,
What about replacement of SID placeholders such as CREATOR_OWNER and PRINCIPAL_SELF in a defaultSecurityDescriptor? These are actually replaced with the SID of the authenticated user and the SID of the new security principal, respectively. So some processing of the default occurs during object creation in AD. I apologize for being so picky, but I think we should clear all such issues. My initial question of what parameter we use to pass defaultSecurityDescriptor has been answered. Now it would appear that we also may need to pass some routine for pre-processing it (replacing holders for example). Is this the case?

Regards,
Nadezhda Ivanova

________________________________
From: Edgar Olougouna [mailto:edgaro at microsoft.com]
Sent: Saturday, August 08, 2009 12:18 AM
To: Nadezhda Ivanova
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Information needed about security token default ACL

Hi Nadezhda,

After further review, it has been determined that the defaultSecurityDescriptor should be used as it is in a scenario where its usage is permissible.
I have prepared a set of questions and answers to explain how we address the issues you rose.

Questions and answers
==================

Question:
Will the issue of DEFAULT_DESCRIPTOR_FOR_OBJECT usage be clarified in the updated MS-ADTS?
Answer:
The proposed procedure in this communication covers inheritable ACEs in general, i.e. object-specific inheritable ACEs and generic inheritable ACEs.
Your previous feedback related to the DEFAULT_DESCRIPTOR_FOR_OBJECT was based on the assumption that the defaultSecurityDescriptor is passed as CreatorDescriptor argument in ComputeACL algorithm, which is not the case as we clarify in the revised procedure.

Question:
When can we expect the document update to be available?
Answer:
The product team is working to update the MS-ADTS document to reflect the defaulting rules related to defaultSecurityDescriptor when assigning security descriptors to AD objects. The changes will be available in a future version of the document.

Question:
In Windows 2008 Active Directory, why the security descriptor of a domain-dns object is identical to the defaultSecurityDescriptor of its classSchema object?
Answer:
The example of a root of a NC is illustrative of a usage of defaultSecurityDescriptor. However it is also an exception case and the security descriptor of the root of a NC does not include any inherited ACEs. Active directory objects have some specific requirements as detailed in [MS-ADTS] 7.1.3 Security Descriptor Requirements http://msdn.microsoft.com/en-us/library/cc223731(PROT.13).aspx.

Question:
I had a look at defaultSecurityDescriptor attributes in some classSchema objects. There is no ACE-flag set on them. Does this means the ACEs would not be inherited?
Answer:
This is not an issue since we now use the defaultSecurityDescriptor when the scenario requires, instead of calling the ComputeInheritedACLFromParent method with the ACEs extracted from defaultSecurityDescriptor.

Question:
If we must call ComputeInheritedACLFromParent with ACEs from defaultSecurityDescriptor as ParentACL, does that mean that CreateSecurityDescriptor must have another argument to allow passing of the defaultSecurityDescriptor?
Answer:
Even though ComputeInheritedACLFromParent is not being called anymore, defaultSecurityDescriptor will be an extra parameter that needs to be passed to the CreateSecurityDescriptor method.

Question:
If the ACEs cannot be inherited from defaultSecurityDescriptor, shouldn't we just use the ACEs from the defaultSecurityDescriptor as opposed to calling ComputeInheritedACLFromParent with ACEs from defaultSecurityDescriptor as ParentACL?
Answer:
This is the correct approach, using the defaultSecurityDescriptor without calling ComputeInheritedACLFromParent.

Revised procedure
==============

Condition 1 : Parent contains inheritable ACEs

Step 1.  If the control flags on the client allow inheritance then the inheritable ACEs from the parent form the newly created object's initial DACL and SACL

Step 2.  If the control flags on the client do not allow inheritance, set initial DACL and SACL to NULL

Step 3.  If an explicit security descriptor is provided by the client, that is merged with the initial DACL and SACL.

Step 4.  If an explicit security descriptor is not provided by the client then the DACL and SACL from the defaultSecurityDescriptor are merged with the initial DACL and SACL.



In ComputeACL method [MS-DTYP] section 2.5.2.4 defaultSecurityDescriptor is used in the highlighted areas :



Set ComputedACL to NULL

Set ComputedControl to NULL



CALL ContainsInheritableACEs WITH ParentACL RETURNING result



IF result = TRUE THEN

   // ParentACL contains inheritable ACEs

    IF(CreatorACL is not present) OR

      ((CreatorACL is present) AND

      (AutoInheritFlags contains DEFAULT_DESCRIPTOR))

    THEN

        // Use only the inherited ACEs from the parent

        CALL ComputeInheritedACLFromParent WITH

          ParentACL, IsContainerObject, ObjectTypes

        RETURNING NextACL

        CALL PostProcessACL WITH

          NextACL, Owner, Group, GenericMapping

        RETURNING FinalACL

        Here the defaultSecurityDescriptor should be merged with the FinalACL above. That will be the new resultant FinalACL

      Set ComputedACL to FinalACL

    ENDIF



    IF ((CreatorACL is present) AND

      (AutoInheritFlags does not contain DEFAULT_DESCRIPTOR))

    THEN

        CALL PreProcessACLFromCreator WITH CreatorACL

        RETURNING PreACL



        CALL ComputeInheritedACLFromCreator WITH

          PreACL, IsContainerObject, ObjectTypes

        RETURNING TmpACL



        IF((ComputeType = DACL_COMPUTE) AND

          (CreatorControl does not contain DACL_PROTECTED) AND

          (AutoInheritFlags contains DACL_AUTO_INHERIT flag))

        THEN

            // Compute the inherited ACEs from the parent

            CALL ComputeInheritedACLFromParent WITH

              ParentACL, IsContainerObject, ObjectTypes

            RETURNING ParentACL

            Append ParentACL.ACEs to TmpACL.ACEs

            Add DACL_AUTO_INHERITED to ComputedControl

        ELSE

            IF ((ComputeType = SACL_COMPUTE) AND

              (CreatorControl does not contain SACL_PROTECTED) AND

              (AutoInheritFlags contains SACL_AUTO_INHERIT flag))

            THEN

                // Compute the inherited ACEs from the parent

                CALL ComputeInheritedACLFromParent WITH

                  ParentACL, IsContainerObject, ObjectTypes

                RETURNING ParentACL

                Append ParentACL.ACEs to TmpACL.ACEs

                Add SACL_AUTO_INHERITED to ComputedControl

            ENDIF

        ENDIF

    ENDIF



    If (CREATORACL is absent)

        Here ACLs should be obtained from the parent and be merged with those from the defaultSecurityDescriptor.

    ENDIF



    CALL PostProcessACL WITH

      TmpACL, Owner, Group, GenericMapping

    RETURNING ProcessedACL



    Set ComputedACL to ProcessedACL



ELSE // ParentACL does not contain inheritable ACEs




Condition 2 : Parent does not contain inheritable ACEs
                If the parentACL does not contain inheritable ACEs and no explicit security descriptor has been provided for the newly created object then check to see if a defaultSecurityDescriptor for the objectClass under consideration is present.
                At this stage :

ELSE // ParentACL does not contain inheritable ACEs

IF CreatorACL = NULL THEN

        // No ACL supplied for the object
               if the defaultSecurityDescriptor is present then that will form the newly created object's security descriptor.

In this case the security information in the token need not be used.

Condition 3 : Parent does not contain inheritable ACEs AND defaultSecurityDescriptor for the particular object is absent
If the defaultSecurityDescriptor of the particular objectClass under consideration is absent then make use of Token as described in the ComputeACL method.


ELSE // ParentACL does not contain inheritable ACEs

IF CreatorACL = NULL THEN

        // No ACL supplied for the object

        IF (ComputeType = DACL_COMPUTE) THEN

            Set ComputedACL to Token.DefaultDACL

        ELSE

            // No default for SACL; left as NULL

        ENDIF



    ELSE

Let me know if you require further assistance on this topic.

Best regards,

Edgar

From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
Sent: Thursday, August 06, 2009 10:38 AM
To: Edgar Olougouna
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Information needed about security token default ACL

Hi Edgar,
So, if we must call ComputeInheritedACLFromParent with defaultSecurityDescriptor as parent, does that mean that CreateSecurityDescriptor must have another argument to allow passing of the defaultSecurityDescriptor? And I suppose the issue of DEFAULT_DESCRIPTOR_FOR_OBJECT usage will be clarified in the updated MS-ADTS? When can we expect this update to be available?

Also, there is something I do not understand in your answer. ComputeInheritedACLFromParent returns only the list of ACEs from the input ACL that are inheritable, i.e have CI ot OI flag set - see the algorithm in MS-DTYP, its pretty straightforward.  IT only concatenates inheritable ACE's. So, if we pass defaultSecurityDescriptor to ComputeInheritedACLFromParent, we will only get the inheritable ACE's from defaultSecurityDescriptor. That is not the case, however, as I have established experimentally.
For example, lets take the security descriptor of a domain-dns object in Win 2008. It has no parent as it is an NC, its descriptor looks like this:

(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-3191434175-1265308384-3577286990-498)
(A;;RP;;;WD)
(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(A;;RPLCLORC;;;AU)
(A;;RPWPCRLCLOCCRCWDWOSW;;;DA)
(A;CI;RPWPCRLCLOCCRCWDWOSDSW;;;BA)
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)
(A;CI;LC;;;RU)
(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;;RP;c7407360-20bf-11d0-a768-00aa006e0529;;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)
(A;;RPRC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(A;;LCRPLORC;;;ED)
(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RPLCLORC;;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;;RP;b8119fd0-04f6-4762-ab7a-4986c76b3f9a;;RU)
(OA;;RP;b8119fd0-04f6-4762-ab7a-4986c76b3f9a;;AU)
(OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)
(OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)
(OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)
(OA;;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;DD)
(OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;ED)
(OA;;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;BA)
(OA;;CR;e2a36dc9-ae17-47c3-b58b-be34c55ba633;;S-1-5-32-557)
(OA;;CR;280f369c-67c7-438e-ae98-1d46f3c6f541;;AU)
(OA;;CR;ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501;;AU)
(OA;;CR;05c74c5e-4deb-43b4-bd9f-86664c2a7fd5;;AU)
(OA;;CR;1131f6ae-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6ae-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;CIIO;CRRPWP;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)
S:(AU;SA;WDWOWP;;;WD)
(AU;SA;CR;;;BA)
(AU;SA;CR;;;DU)
(OU;CISA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
(OU;CISA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)

And the defaultSecurityDescriptor of domain-DNS class is:

(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-3191434175-1265308384-3577286990-498)
(A;;RP;;;WD)
(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(A;;RPLCLORC;;;AU)
(A;;RPWPCRLCLOCCRCWDWOSW;;;DA)
(A;CI;RPWPCRLCLOCCRCWDWOSDSW;;;BA)
(A;;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;SY)
(A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;EA)
(A;CI;LC;;;RU)
(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;;RP;c7407360-20bf-11d0-a768-00aa006e0529;;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)
(A;;RPRC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(A;;LCRPLORC;;;ED)
(OA;CIIO;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;CIIO;RPLCLORC;;4828CC14-1437-45bc-9B07-AD6F015E5F28;RU)
(OA;;RP;b8119fd0-04f6-4762-ab7a-4986c76b3f9a;;RU)
(OA;;RP;b8119fd0-04f6-4762-ab7a-4986c76b3f9a;;AU)
(OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)
(OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)
(OA;CIIO;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)
(OA;;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;DD)
(OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;ED)
(OA;;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;;CR;89e95b76-444d-4c62-991a-0facbeda640c;;BA)
(OA;;CR;e2a36dc9-ae17-47c3-b58b-be34c55ba633;;S-1-5-32-557)
(OA;;CR;280f369c-67c7-438e-ae98-1d46f3c6f541;;AU)
(OA;;CR;ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501;;AU)
(OA;;CR;05c74c5e-4deb-43b4-bd9f-86664c2a7fd5;;AU)
(OA;;CR;1131f6ae-9c07-11d1-f79f-00c04fc2dcd2;;ED)
(OA;;CR;1131f6ae-9c07-11d1-f79f-00c04fc2dcd2;;BA)
(OA;CIIO;CRRPWP;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)
S:(AU;SA;WDWOWP;;;WD)
(AU;SA;CR;;;BA)
(AU;SA;CR;;;DU)
(OU;CISA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
(OU;CISA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)

They are absolutely identical, and both contain non-inheritable ace's which would not be in the domain object's descriptor  if the defaultSecurityDescriptor was processed by ComputeInheritableFromParent, as you write. It could be that the algorithm is not correct, I am still waiting for an update from Obaid on an issue about that. I am sorry but it does not make sense to me....

Regards,
Nadezhda Ivanova




________________________________
From: Edgar Olougouna [mailto:edgaro at microsoft.com]
Sent: Thursday, August 06, 2009 5:47 PM
To: Nadezhda Ivanova
Cc: 'pfif at tridgell.net'; 'cifs-protocol at samba.org'
Subject: RE: Information needed about security token default ACL


Hi Nadezhda,



We have completed investigation of your request. The MS-ADTS document will be updated to address defaulting rules related to defaultSecurityDescriptor when assigning security descriptors to AD objects. Our revised response for your inquiry is as follows.


Condition 1 : Parent contains inheritable ACEs

Step 1.  If the control flags on the client allow inheritance then the inheritable ACEs from the parent form the newly created object's initial DACL and SACL

Step 2.  If the control flags on the client do not allow inheritance  set initial DACL and SACL to NULL

Step 3.  If an explicit security descriptor is provided by the client, that is merged with the initial DACL and SACL.

Step 4.  If an explicit security descriptor is not provided by the client then the DACL and SACL from the defaultSecurityDescriptor are merged with the initial DACL and SACL. Method ComputeInheritedACLFromParent [MS-DTYP] section 2.5.2.6 should be called passing DACL and SACL from the defaultSecurityDescriptor as the parameters.



In ComputeACL method [MS-DTYP] section 2.5.2.4 a call to ComputeInheritedACLFromParent should to be made in the highlighted area :



Set ComputedACL to NULL

Set ComputedControl to NULL



CALL ContainsInheritableACEs WITH ParentACL RETURNING result



IF result = TRUE THEN

   // ParentACL contains inheritable ACEs

    IF(CreatorACL is not present) OR

      ((CreatorACL is present) AND

      (AutoInheritFlags contains DEFAULT_DESCRIPTOR))

    THEN

        // Use only the inherited ACEs from the parent

        CALL ComputeInheritedACLFromParent WITH

          ParentACL, IsContainerObject, ObjectTypes

        RETURNING NextACL

        CALL PostProcessACL WITH

          NextACL, Owner, Group, GenericMapping

        RETURNING FinalACL

        Here ComputeInheritedACLFromParent should be called passing defaultSecurityDescriptor. The ACLs obtained via this call should be merged with the FinalACL above. That will be the new resultant FinalACL

      Set ComputedACL to FinalACL

    ENDIF



    IF ((CreatorACL is present) AND

      (AutoInheritFlags does not contain DEFAULT_DESCRIPTOR))

    THEN

        CALL PreProcessACLFromCreator WITH CreatorACL

        RETURNING PreACL



        CALL ComputeInheritedACLFromCreator WITH

          PreACL, IsContainerObject, ObjectTypes

        RETURNING TmpACL



        IF((ComputeType = DACL_COMPUTE) AND

          (CreatorControl does not contain DACL_PROTECTED) AND

          (AutoInheritFlags contains DACL_AUTO_INHERIT flag))

        THEN

            // Compute the inherited ACEs from the parent

            CALL ComputeInheritedACLFromParent WITH

              ParentACL, IsContainerObject, ObjectTypes

            RETURNING ParentACL

            Append ParentACL.ACEs to TmpACL.ACEs

            Add DACL_AUTO_INHERITED to ComputedControl

        ELSE

            IF ((ComputeType = SACL_COMPUTE) AND

              (CreatorControl does not contain SACL_PROTECTED) AND

              (AutoInheritFlags contains SACL_AUTO_INHERIT flag))

            THEN

                // Compute the inherited ACEs from the parent

                CALL ComputeInheritedACLFromParent WITH

                  ParentACL, IsContainerObject, ObjectTypes

                RETURNING ParentACL

                Append ParentACL.ACEs to TmpACL.ACEs

                Add SACL_AUTO_INHERITED to ComputedControl

            ENDIF

        ENDIF

    ENDIF



    If (CREATORACL is absent)

        Here ACLs should be obtained from the parent and be merged with those from the defaultSecurityDescriptor. Both via calls to ComputeInheritedACLFromParent.

    ENDIF



    CALL PostProcessACL WITH

      TmpACL, Owner, Group, GenericMapping

    RETURNING ProcessedACL



    Set ComputedACL to ProcessedACL



ELSE // ParentACL does not contain inheritable ACEs




Condition 2 : Parent does not contain inheritable ACEs
                If the parentACL does not contain inheritable ACEs then check to see if a defaultSecurityDescriptor for the objectClass under consideration is present.
If defaultSecurityDescriptor is present then call ComputeInheritedACLFromParent by passing (ACL from defaultSecurityDescriptor) in place of ParentACL. That is the following part in the ComputeACL method [MS-DTYP] section 2.5.2.4.



  CALL ComputeInheritedACLFromParent WITH

          ParentACL, IsContainerObject, ObjectTypes

     RETURNING NextACL

     CALL PostProcessACL WITH

          NextACL, Owner, Group, GenericMapping

      RETURNING FinalACL

      Set ComputedACL to FinalACL


In this case the security information in the token need not be used.

Condition 3 : Parent does not contain inheritable ACEs AND defaultSecurityDescriptor for the particular object is absent
If the defaultSecurityDescriptor of the particular objectClass under consideration is absent then make use of Token as described in the ComputeACL method.


ELSE // ParentACL does not contain inheritable ACEs

IF CreatorACL = NULL THEN

        // No ACL supplied for the object

        IF (ComputeType = DACL_COMPUTE) THEN

            Set ComputedACL to Token.DefaultDACL

        ELSE

            // No default for SACL; left as NULL

        ENDIF



    ELSE



Let us know if you need further assistance on this topic.



Best regards,

Edgar





-----Original Message-----
From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
Sent: Friday, July 31, 2009 6:53 AM
To: Edgar Olougouna
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Information needed about security token default ACL





Hi Edgar,

Thank you for your explanation. It answered a lot of questions, but also raised some more, see below:



> -----Original Message-----

> From: Edgar Olougouna [mailto:edgaro at microsoft.com]

> Sent: Thursday, July 30, 2009 5:37 PM

> To: Nadezhda Ivanova

> Cc: 'pfif at tridgell.net'; 'cifs-protocol at samba.org'

> Subject: RE: Information needed about security token default ACL

>

> Hi Nadezhda,

>

> This response relates to the portion of your inquiry regarding the

> CreateSecurityDescriptor algorithm. I hope the following information will

> clarify how CreatorDescriptor and defaultSecuritiDescriptor relate to the

> CreateSecurityDescriptor procedure.

>

> The CreatorDescriptor (optional) is a security descriptor explicitly

> provided by the creator of the object. The creator of the object is the

> subject that is creating the object. A subject is a thread executing in

> the security context provided by an access token.

>

> [MS-ADTS] Section 7 provides additional information that may help on your

> topic. Section "7.1.3 Security Descriptor Requirements" details the

> parameters used by the CreateSecurityDescriptor algorithm to compute the

> resultant security descriptor value of an AD object, for instance

> AutoInheritFlags: DACL_AUTO_INHERIT | SACL_AUTO_INHERIT.

> Note these key points when an ACL is built for an AD object compared to

> other types of objects:

> *       Generic inheritable ACEs apply to all types of child objects.

> Object-specific inheritable ACEs apply only to a specific type of child

> object.

> *       If there is no supplied security descriptor, no parent-inheritable

> ACEs, the operating system uses the ACL from the defaultSecurityDescriptor

> in the classSchema object.

>

> Based on the CreateSecurityDescriptor procedure from [MS-DTYP] 2.5.2.3,

> you can apply the following rules to ACL assignment for a new AD object:

> If an explicit security descriptor (CreatorDescriptor) is provided by the

> client, then that forms the object's initial DACL and SACL. If the

> client's controls allow inheritance then the inheritable ACEs from the

> parent are merged into the object's initial DACL and SACL.

> If the client does not provide an explicit security descriptor then the

> inheritable ACEs from the parent are merged into the new object's DACL and

> SACL. For details please refer to [MS-DTYP] section 2.5.2.4 ComputeACL

> method. If the parent contains object-specific inheritable ACEs then the

> defaultSecurityDescriptor is not used during the security descriptor

> creation process for the newly added object.

[Nadezhda Ivanova]



Above you state that defaultSecurityDescriptor is used if there are NO  inheritable ACE's, here you say it's used if there are no Object-Specific Inheritable ACE's... If there are non-object specific inheritable ACE's , do we merge them in with the ace's from the defaultSecurityDescriptor?



> If the parent does not contain object-specific inheritable ACEs then the

> defaultSecurityDescriptor from the Active Directory schema for the object

> type is used. Following the definition of method ComputeACL in [MS-DTYP]

> 2.5.2.4, method ComputeInheritedACLFromParent [MS-DTYP] section 2.5.2.6

> can be called by passing ACLs from the defaultSecurityDescriptor as the

> parameters.

[Nadezhda Ivanova]

I need clarification here. By definition ComputeInheritedACLFromParent accepts the Parent's descriptor and returns the set of ACE's to be inherited by the new object. How exactly do you use it with defaultSecurityDescriptor's ACE?



I assume you mean the following part of computeACL:



IF result = TRUE

        THEN // ParentACL contains inheritable ACEs

        IF(CreatorACL is not present) OR ((CreatorACL is present)                                       AND(AutoInheritFlags contains DEFAULT_DESCRIPTOR))

        THEN // Use only the inherited ACEs from the parent

                CALL ComputeInheritedACLFromParent WITH ParentACL,                                 IsContainerObject, ObjectTypes

                RETURNING NextACL

        CALL PostProcessACL WITH NextACL, Owner, Group, GenericMapping  RETURNING FinalACL

        Set ComputedACL to FinalACL

        ENDIF



Here is the description of DEFAULT_DESCRIPTOR:



DEFAULT_DESCRIPTOR_FOR_OBJECT: Selects the CreatorDescriptor as the default security descriptor provided that no object type specific ACEs are inherited from the parent. If such ACEs do get inherited, CreatorDescriptor is ignored.



So, it appears that the defaultSecurityDescriptor is passed on as CreatorDescriptor, and the DEFAULT_DESCRIPTOR_FOR_OBJECT flag is raised in this case. How does that connect with calling ComputeInheritedACLFromParent with defaultSecurityDescriptors ACE's.



Also, the above portion of the algorithm appears to always disregard CreatorACL if the flag is raised, and not if the flag is raised AND the parent contains Object-Specific inheritable ACES, as the flag's description and your answer state. So, what am I missing here?



> If the Active Directory schema does not specify a

> defaultSecurityDescriptor for the object type then the security

> information in the requestor's token is used. For details about the usage

> of the requestor's token please refer [MS-DTYP] Section 2.5.2.4

> ComputeACL.

>

> Please let me know if you need further assistance on this topic.

>

> Best regards,

> Edgar

>

> -----Original Message-----

> From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]

> Sent: Friday, July 17, 2009 7:46 AM

> To: Interoperability Documentation Help

> Cc: pfif at tridgell.net; cifs-protocol at samba.org

> Subject: Information needed about security token default ACL

>

> Hi,

>

> In the course of my work in implementing security descriptor inheritance

> in Directory service of Samba 4, I came across the following statement in

> MS-DTYP, 2.5.2

> "The token also contains an ACL, Token.DefaultDACL, that serves as the

> DACL assigned by default to any objects created by the user. "

>

> So, am I right to understand that this DACL is used when no

> nTSecurityDescriptor is provided by the incoming LDAP add request, and

> there is no defaultSecurityDescriptor for the objectClass.

> If so, how is the Token.DefaultDACL constructed and when? Is this based on

> the user's credentials and how?

>

> In addition, I have a question about the security descriptor creation

> algorithm described in MS-DTYP 2.5.2.3

> One of the arguments of CreateSecurityDescriptor is:

> CreatorDescriptor: Security descriptor for the new object provided by the

> creator of the object. Caller can pass NULL.

>

> Am I right in understanding that this is either the nTSecurityDescriptor

> attribute provided by the user, or, in the lack thereof, the

> defaultSecurityDescriptor of the object class?

>

> Best Regards,

> Nadezhda Ivanova




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20090810/d185beb6/attachment-0001.html>


More information about the cifs-protocol mailing list