[cifs-protocol] Information needed about security token default ACL
edgaro at microsoft.com
Thu Jul 30 08:36:40 MDT 2009
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] 220.127.116.11, 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 18.104.22.168 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.
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] 22.214.171.124, method ComputeInheritedACLFromParent [MS-DTYP] section 126.96.36.199 can be called by passing ACLs from the defaultSecurityDescriptor as the parameters.
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 188.8.131.52 ComputeACL.
Please let me know if you need further assistance on this topic.
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
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 184.108.40.206
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?
More information about the cifs-protocol