Information needed about security token default ACL
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Information needed about security token default ACL
by Nadezhda Ivanova-2
::
Rate this Message:
|
|
|
Re: Information needed about security token default ACL
by Dominic Salemno-2
::
Rate this Message:
|
|
|
Re: Information needed about security token default ACL
by Obaid Farooqi
::
Rate this Message:
|
|
|
|
|
|
Re: Information needed about security token default ACL
by Obaid Farooqi
::
Rate this Message:
|
|
|
|
|
|
Re: Information needed about security token default ACL
by Edgar Olougouna
::
Rate this Message:
|
|
|
|
|
|
Re: Information needed about security token default ACL
by Edgar Olougouna
::
Rate this Message:
|
|
|
Re: Information needed about security token default ACL
by Edgar Olougouna
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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----- 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@...] > Sent: Thursday, July 30, 2009 5:37 PM > To: Nadezhda Ivanova > Cc: 'pfif@...'; 'cifs-protocol@...' > 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@...] > Sent: Friday, July 17, 2009 7:46 AM > To: Interoperability Documentation Help > Cc: pfif@...; cifs-protocol@... > 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 cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
|
|
|
Re: Information needed about security token default ACL
by Edgar Olougouna
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...] 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@...] 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----- 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@...] > Sent: Thursday, July 30, 2009 5:37 PM > To: Nadezhda Ivanova > Cc: 'pfif@...'; 'cifs-protocol@...' > 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@...] > Sent: Friday, July 17, 2009 7:46 AM > To: Interoperability Documentation Help > Cc: pfif@...; cifs-protocol@... > 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 cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
|
|
|
Re: Information needed about security token default ACL
by Sebastian Canevari
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Nadezhda, I’ll be helping you with this
question. As soon as I have answers or
questions I will let you know. Thanks and regards, Sebastian Canevari "Las Colinas - LC2" Tel: +1 469 775 7849 From:
cifs-protocol-bounces@... [mailto:cifs-protocol-bounces@...] On
Behalf Of Nadezhda Ivanova 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@...] 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@...] 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@...] 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----- 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@...] > Sent: Thursday, July 30, 2009 5:37 PM > To: Nadezhda Ivanova > Cc: 'pfif@...'; 'cifs-protocol@...' > 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@...] > Sent: Friday, July 17, 2009 7:46 AM > To: Interoperability Documentation Help > Cc: pfif@...; cifs-protocol@... > 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 cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Information needed about security token default ACL
by Edgar Olougouna
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...] 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@...] 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@...] 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@...] 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----- 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@...] > Sent: Thursday, July 30, 2009 5:37 PM > To: Nadezhda Ivanova > Cc: 'pfif@...'; 'cifs-protocol@...' > 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@...] > Sent: Friday, July 17, 2009 7:46 AM > To: Interoperability Documentation Help > Cc: pfif@...; cifs-protocol@... > 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 cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
|
|
|
Re: Information needed about security token default ACL
by Sebastian Canevari
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Nadezhda, After reviewing the docs I feel
they are complete and accurate. I do not see a better way of describing
the usage of PRINCIPAL_SELF other than the one used in section 5.1.3.3 in
MS-ADTS. However, the SidInToken() pseudo code in MS-DTYP section 2.5.2.1
does help to clarify the SID substitution. I would like to make sure that you
and I both have the same understanding of your request. Based on your comments, you know
that PRINCIPAL_SELF is a generic Well Known SID (S-1-5-10) that may be used
with Security Descriptors as a way to identify the permissions the object has
to itself. This is used primarily in inheritance since SELF can be given permissions
to a container where all objects created inside of it will have certain rights
to modify themselves (ie – user A can change its phone # but not that of other
users). This is a way to be able to provide certain object with permissions
before its SID even exists. Any Security Descriptor processed
by the access check will have all instances of the PRINCIPAL_SELF SID replaced
with the SID of the object itself. The following is a simple test to
demonstrate the behavior: 1)
Create an account in
AD (anywhere) 2)
Look at the
permissions for that new account. 3)
Note the SELF security
principal has read and some specific rights to it. 4)
Log on with the newly
created account 5)
Look at the AD properties
for its own object in AD and note what you can read / modify 6)
Log off 7)
Log on with an admin
and deny all permissions to SELF (you can also try adding all permissions, or a
very specific permission) 8)
Logon back with the
user that you’ve just modified and compare what you can do with your own
account now against you could do prior to changing the permissions. 9)
Compare what you can
do with your account with what you can do with someone else’s account object. Thanks and regards, Sebastian Sebastian Canevari "Las Colinas - LC2" Tel: +1 469 775 7849 From: cifs-protocol-bounces@...
[mailto:cifs-protocol-bounces@...] On Behalf Of Nadezhda Ivanova 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@...] 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 NewDescriptor
is 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 NewDescriptor
is 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 "Las Colinas - LC2" Tel: +1 469 775 7849 From: Nadezhda Ivanova
[mailto:nadezhda.ivanova@...] 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@...] 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@...]
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@...] 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----- 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@...] > Sent: Thursday, July 30, 2009 5:37 PM > To: Nadezhda Ivanova > Cc: 'pfif@...'; 'cifs-protocol@...' > 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@...] > Sent: Friday, July 17, 2009 7:46 AM > To: Interoperability Documentation Help > Cc: pfif@...; cifs-protocol@... > 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 cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
Re: Information needed about security token default ACL
by Edgar Olougouna
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@...] 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@...] 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 NewDescriptor
is 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 NewDescriptor
is 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 "Las Colinas - LC2" Tel: +1 469 775 7849 From: Nadezhda Ivanova
[mailto:nadezhda.ivanova@...] 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@...] 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@...] 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@...] 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----- 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@...] > Sent: Thursday, July 30, 2009 5:37 PM > To: Nadezhda Ivanova > Cc: 'pfif@...'; 'cifs-protocol@...' > 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@...] > Sent: Friday, July 17, 2009 7:46 AM > To: Interoperability Documentation Help > Cc: pfif@...; cifs-protocol@... > 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 cifs-protocol@... https://lists.samba.org/mailman/listinfo/cifs-protocol |
|
|
|
