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

[Nadezhda Ivanova]

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