[cifs-protocol] Information needed about security token default ACL
Nadezhda Ivanova
nadezhda.ivanova at postpath.com
Wed Aug 19 02:31:05 MDT 2009
Hi Edgar,
I believe we have reached an understanding on my initial question. Thank you for your assistance!
Best Regards,
Nadezhda Ivanova
From: Edgar Olougouna [mailto:edgaro at microsoft.com]
Sent: Tuesday, August 18, 2009 11:40 PM
To: Nadezhda Ivanova
Cc: 'pfif at tridgell.net'; 'cifs-protocol at samba.org'; Sebastian Canevari
Subject: RE: Information needed about security token default ACL
Hi Nadezhda,
Regarding the defaulting rules with defaultSecurityDescriptor, we have reviewed the wording in Condition 2 of the proposed procedure (see below), which was meant to help compute the resultant ACL for a new AD object. Condition 2 covers the case where the parent does not contain inheritable ACEs and the classSchema of the object being created has a defaultSecurityDescriptor.
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
// New wording
If the defaultSecurityDesciptor is present, then the ACLs should be obtained from the defaultSecurityDescriptor
// Previous wording
If the defaultSecurityDescriptor is present then that will form the newly created object's security descriptor.
Please refer to [MS-DTYP] 2.5.2.3 CreateSecurityDescriptor algorithm for more details.
Best regards,
Edgar
From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
Sent: Monday, August 17, 2009 6:49 AM
To: Sebastian Canevari
Cc: pfif at tridgell.net; Interoperability Documentation Help; cifs-protocol at samba.org
Subject: RE: Information needed about security token default ACL
Hi Sebastian.
No, when I mean PRINCIPAL_SELF, I mean the special SID PRINCIPAL_SELF, see table at page 56 of MS-DTYP. Neither CREATOR_OWNER, nor PRINCIPAL_SELF relate to DEFAULT_GROUP in any way (or so is my current understanding). These two are place holders for the security principal that has the access rights given by a certain ACE. DEAFULT_GROUP is the group field of the entire security descriptor, if I understand correctly.
The actual issue here is that Edgar claims that defaultSecurityDescriptor is used unchanged when it is used. Our experiments show that this is not the case and these two principals are replaced during object creation -the section about access checking you quote confirms that, and we would like to know were the discrepancy comes from, and it should be better explained in the documentation.
The issue of the default group not being as described is a separate issue I have also raised, which is already settled by Obaid.
Best Regards,
Nadezhda Ivanova
From: Sebastian Canevari [mailto:Sebastian.Canevari at microsoft.com]
Sent: Friday, August 14, 2009 9:43 PM
To: Nadezhda Ivanova
Subject: RE: Information needed about security token default ACL
Hi Nadezhda,
I've been reviewing the documentation and I have a question and an answer for you.
#Question:
When you refer to the PRINCIPAL_SELF in a defaultSecurityDescriptor, could it be possible that you mean DEFAULT_GROUP?
If yes, then the answer for the CREATOR_OWNER also applies to the DEFAULT_GROUP.
If not, then I need some more clarification on what information you need regarding the PRINCIPAL_SELF.
#Answer:
With regards of the CREATOR_OWNER, I would like to know if you agree with section 2.5.2.3 CreateSecurityDescriptor (from [MS-DTYP]):
§ DEFAULT_OWNER_FROM_PARENT: Relevant only when the owner field is not specified in CreatorDescriptor. If this flag is set, the owner field in NewDescriptoris set to the owner of ParentDescriptor. If not set, the owner from the token is selected.
§ DEFAULT_GROUP_FROM_PARENT: Relevant only when the primary group field is not specified in CreatorDescriptor. If this flag is set, the primary group of NewDescriptoris set to the primary group of ParentDescriptor. If not set, the default group from the token is selected.
This section specifies that in the case that the flag is not set in CreatorDescriptor, then the owner and group are set to that of the Token. I was able to confirm this in the code.
On a side note, I wanted to make sure that we are both aligned regarding the PRINCIPAL_SELF information we are looking at:
[MS-ADTS]: Active Directory Technical Specification
5.1.3.3 Checking Access
Note that a special principal called Principal Self, identified by the fixed SID value of S-1-5-10, may appear in the SID field of an ACE in the security descriptor of an object. This fixed SID value represents the object itself in an ACE on a security principal object. For example, when an ACE on a user object grants certain access rights to Principal Self, it essentially grants those access rights to the user represented by that object. During an access check for object O, if O! nTSecurityDescriptor contains any ACEs with the fixed SID for Principal Self the server replaces them with O! objectSid before proceeding with the access check.
For the access checking behavior described in the following sections, it is assumed that any security descriptor used as input to that process has already undergone the SID substitution for Principal Self (as described in this section), if necessary.
Please let me know if this answers your question.
Thanks and regards,
Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
Las Colinas - LC2
Tel: +1 469 775 7849
e-mail: sebastc at microsoft.com <mailto:sebastc at microsoft.com>
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/20090819/1bc84e36/attachment-0001.html>
More information about the cifs-protocol
mailing list