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:[email protected]]
Sent: Friday, July 31, 2009 6:53 AM
To: Edgar Olougouna
Cc: [email protected]; [email protected]
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:[email protected]]
> Sent: Thursday, July 30, 2009 5:37 PM
> To: Nadezhda Ivanova
> Cc: '[email protected]'; '[email protected]'
> 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:[email protected]]
> Sent: Friday, July 17, 2009 7:46 AM
> To: Interoperability Documentation Help
> Cc: [email protected]; [email protected]
> 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
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
