Hi, Nadya,
We completed the investigation on your questions. The following are our
responses to the questions:
Q1: What is ACE canonical form?
ANS: An ACL is said to be in canonical form if:
(1) All explicit ACEs are placed before inherited ACEs.
(2) Within the explicit ACEs, deny ACEs come before grant ACEs.
(3) Inherited ACEs are placed in the order in which they were
inherited.
We will add the definition of ACL canonical form to [MS-DTYP] and also
add the reference to this information in 7.1.3.1 MS-ADTS.
Q2: In the sentence: "The nest rule is only applied if the previous
rule(s) give inconclusive results" - what would constitute an inconclusive
result?
ANS: We will remove the statement “The next rule is only applied if the
previous rule(s) give inconclusive results” from 7.1.3.1 [MS-ADTS].
Q3: . I created a group via LDAP and provided a security descriptor with
ACE's deliberately scrambled - e.g Deny before Allow, Object Specific before
Regular. I did not get an LDAP error, the group was successfully created, but
the SD looked the way I provided it, that is, not according to the rules
described in this section. Can you explain why this happens? What behavior
should I expect, is Windows supposed to sort them, return an error
ANS: If the ACEs in the input ACL are not in the canonical form as defined in
Q1 , Windows Active Directory will not sort the ACEs and no error will be
returned to the client.
Please let us know if you have more questions.
Thanks!
Hongwei
-----Original Message-----
From: Nadezhda Ivanova [mailto:[email protected]]
Sent: Monday, April 19, 2010 9:00 AM
To: Hongwei Sun
Cc: MSSolve Case Email; [email protected]
Subject: Re: [REG:110041557300829] RE: [cifs-protocol] Questions regarding
7.1.3.1 ACE Ordering Rules
Hi Hongwei,
Currently I am using the Samba make test framework. I'll find a way to make a
script that can be used without Samba and let you know.
Until then, if it helps, this is the ACL I am providing upon group creation, in
SDDL:
sddl =
"D:(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a54-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS)(OA;;RPWP;e45795b2-9455-11d1-aebd-0000f80367c1;;PS)(OA;;RPWP;e45795b3-9455-11d1-aebd-0000f80367c1;;PS)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS)(OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;;RS)(OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;;RS)(A;;RC;;;AU)(OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RP;77b5b886-944a-11d1-aebd-0000f80367c1;;AU)(OA;;RP;e45795b3-9455-11d1-aebd-0000f80367c1;;AU)(OA;;RP;e48d0154-bcf8-11d1-8702-00c04fb96050;;AU)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;;RS)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)(OA;;RPWP;5805bc62-bdc9-4428-a5e2-856a0f4c185e;;S-1-5-32-561)"
+ ("(D;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;%s)(D;;RPLCLORC;;;%s)" % (sid, sid))
The group is in an OU where inheritance is broken, that is, it will not inherit
anything from the parent.
The sid variable is the sid of a regular user, I suppose any user would do.
Thanks,
Nadya
----- Original Message -----
> From: Hongwei Sun <[email protected]>
> To: Nadezhda Ivanova <[email protected]>
> Cc: [email protected] <[email protected]>, MSSolve Case
> Email <[email protected]>
> Sent: Saturday, April 17, 2010 0:03:41 AM (GMT+02:00) Helsinki, Kyiv, Riga,
> Sofia, Tallinn, Vilnius
> Subject: [REG:110041557300829] RE: [cifs-protocol] Questions regarding
> 7.1.3.1 ACE Ordering Rules
> > Nadya,
>
> Active Directory is supposed to apply the requirements to any
> security descriptors maintained by a DC, as described in section
> 7.1.3. ACE ordering is one of the requirement. If forest functional
> level is DS_BEHAVIOR_WIN2003 and fDontStandardizeSDs is false, the
> ACEs in the ACLs will be sorted by DC using the ACE ordering rule in
> 7.1.3.1 MS-ADTS. This enforcement should happen either when a new
> object is created or when LDAP modify on security descriptor is done.
> If the ACE reordering cannot be done for some reasons, there will be
> no LDAP error returned and. The order of explicit ACEs supplied by
> the client is preserved.
>
> You are running test against Windows 2008 and by default
> fDontStandardizeSDs should be zero. So the ACE reordering should
> happen. Could you send me (1)the LDAP command you used to create the
> group
> (2)the SD you provided
> (3)the dump of SD finally set on group object ?
> I will investigate to find the reason why reordering is not happening.
>
>
> I am working on the clarification for the section of 7.1.3.1 based on
> two of your questions. I will let you know.
>
> Thanks!
>
> Hongwei
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Nadezhda Ivanova
> Sent: Thursday, April 15, 2010 8:22 AM
> To: Interoperability Documentation Help
> Cc: [email protected]
> Subject: [cifs-protocol] Questions regarding 7.1.3.1 ACE Ordering
> Rules
>
> Hello,
> I was running some test against a Windows 2008 server, forest
> functional level and domain functional level are both 2008. I created
> a group via LDAP and provided a security descriptor with ACE's
> deliberately scrambled - e.g Deny before Allow, Object Specific before
> Regular. I did not get an LDAP error, the group was successfully
> created, but the SD looked the way I provided it, that is, not
> according to the rules described in this section. Can you explain why
> this happens? What behavior should I expect, is Windows supposed to
> sort them, return an error, or sort them later, or when a recalculate
> hierarchy request is sent?
>
> In addition:
> What is ACE canonical form?
> In the sentence: "The nest rule is only applied if the previous
> rule(s) give inconclusive results" - what would constitute an
> inconclusive result?
>
> Best Regards,
> Nadya
>
> _______________________________________________
> cifs-protocol mailing list
> [email protected]
> https://lists.samba.org/mailman/listinfo/cifs-protocol
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
