[cifs-protocol] [REG:110041557300829] RE: Questions regarding 7.1.3.1 ACE Ordering Rules
Hongwei Sun
hongweis at microsoft.com
Wed May 5 01:54:14 MDT 2010
Nadya,
Just to confirm what we have just talked about during our conversation. If the client provides ACL sorted by rule 1 and 2, which basically make it in canonical form, Windows will sort them further by rule 3 and 4. Please let me know if there is any more question.
Thanks!
Hongwei
-----Original Message-----
From: Nadezhda Ivanova [mailto:nadezhda.ivanova at postpath.com]
Sent: Monday, May 03, 2010 2:30 AM
To: Hongwei Sun
Cc: MSSolve Case Email; cifs-protocol at samba.org
Subject: Re: [REG:110041557300829] RE: [cifs-protocol] Questions regarding 7.1.3.1 ACE Ordering Rules
Hi Hongwei,
This makes things a bit clearer, but I have one more question:
If the client provides ACL sorted by rules 1 and 2, will Windows automatically sort them by rule 3 and 4, or is the client responsible for this too?
Regards,
Nadya
----- Original Message -----
> From: Hongwei Sun <hongweis at microsoft.com>
> To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
> Cc: MSSolve Case Email <casemail at microsoft.com>,
> cifs-protocol at samba.org <cifs-protocol at samba.org>
> Sent: Sunday, May 2, 2010 6:46:08 AM (GMT+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius
> Subject: RE: [REG:110041557300829] RE: [cifs-protocol] Questions regarding 7.1.3.1 ACE Ordering Rules
> > 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:nadezhda.ivanova at postpath.com]
> Sent: Monday, April 19, 2010 9:00 AM
> To: Hongwei Sun
> Cc: MSSolve Case Email; cifs-protocol at samba.org
> 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-1
> e
> 2f-11d0-9819-00aa0040529b;;PS)(OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040
> 5
> 29b;;PS)(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS)(OA;;RPWP;e
> 4
> 5795b2-9455-11d1-aebd-0000f80367c1;;PS)(OA;;RPWP;e45795b3-9455-11d1-ae
> b
> d-0000f80367c1;;PS)(OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS)(O
> A
> ;;RP;4c164200-20c0-11d0-a768-00aa006e0529;;RS)(OA;;RP;bc0ac240-79a9-11
> d
> 0-9020-00c04fc2d4cf;;RS)(A;;RC;;;AU)(OA;;RP;59ba2f42-79a2-11d0-9020-00
> c
> 04fc2d3cf;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORC
> W
> OWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)(
> O
> A;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RP;77b5b886-944a-1
> 1
> d1-aebd-0000f80367c1;;AU)(OA;;RP;e45795b3-9455-11d1-aebd-0000f80367c1;
> ;
> AU)(OA;;RP;e48d0154-bcf8-11d1-8702-00c04fb96050;;AU)(OA;;CR;ab721a53-1
> e
> 2f-11d0-9819-00aa0040529b;;WD)(OA;;RP;5f202010-79a5-11d0-9020-00c04fc2
> d
> 4cf;;RS)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(OA;;RP;46a
> 9
> b11d-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 <hongweis at microsoft.com>
> > To: Nadezhda Ivanova <nadezhda.ivanova at postpath.com>
> > Cc: cifs-protocol at samba.org <cifs-protocol at samba.org>, MSSolve Case
> > Email <casemail at microsoft.com>
> > 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: cifs-protocol-bounces at cifs.org
> > [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of Nadezhda
> Ivanova
> > Sent: Thursday, April 15, 2010 8:22 AM
> > To: Interoperability Documentation Help
> > Cc: cifs-protocol at samba.org
> > 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
> > cifs-protocol at cifs.org
> > https://lists.samba.org/mailman/listinfo/cifs-protocol
More information about the cifs-protocol
mailing list