[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] [REG:110020183056252] - Inconsistencies in ACLs
From: Matthieu Patou <mat+Informatique.Samba () matws ! net>
Date: 2010-03-20 14:27:21
Message-ID: 4BA4DB49.3060203 () matws ! net
[Download RAW message or body]
Hello Hongwei,
So far it's good , you can close it.
Matthieu.
> Matthieu,
>
> I just want to check with you to see if you have any further questions on this \
> issue. If not , I will consider this case closed. Again, if you have related \
> questions in the future, we can always revisit this case.
> Thanks!
>
> Hongwei
>
> -----Original Message-----
> From: Hongwei Sun
> Sent: Thursday, March 04, 2010 6:08 PM
> To: Matthieu Patou
> Cc: Sebastian Canevari; pfif@tridgell.net; cifs-protocol@samba.org; MSSolve Case \
> Email
> Subject: RE: [REG:110020183056252] - Inconsistencies in ACLs
>
> Resending.. just an editorial change...
>
> Matthieu,
>
> The default GPOs created during domain creation time (DcPromo) are Default Domain \
> Group Policy(31B2F340-016D-11D2-945F-00C04FB984F9) and Default Domain Controller \
> Group Policy (6AC1786C-016F-11D2-945F-00C04fB984F9). The initial security \
> descriptors of default GPO SYSVOL folder and default DPO DS objects are assigned \
> pre-defined values ,which are stored in windows implementation specific \
> installation configuration files (schema.ini and defltdc.inf) , during DCPromo \
> process. They are not derived from each other. For default GPO object in DS, the \
> owner is always Domain Admins(DA), Group is always the Domain Admins(DA). For \
> default GPO folder under SYSVOL, the owner should be Builtin Administrator and \
> owner is System.
> Please let us know if you have more questions.
>
> Thanks!
>
> Hongwei
>
>
> -----Original Message-----
> From: Hongwei Sun
> Sent: Friday, February 26, 2010 6:34 PM
> To: 'Matthieu Patou'
> Cc: Sebastian Canevari; pfif@tridgell.net; cifs-protocol@samba.org; MSSolve Case \
> Email
> Subject: RE: [REG:110020183056252] - Inconsistencies in ACLs
>
> Matthieu,
>
>
> > Ok from the reading of the DS flags it's not obvious that all this flags
> > will "merge" to give FA. I suppose we should have a rule saying when you
> > have "RPWPCCDCLCLORCWOWDSDDTSW" then the associate ACE is FA full stop.
> > Is there other special translations rules ?
> >
> RPWPCCDCLCLORCWOWDSDDTSW (0x000f00ff) is not mapped to "FA" directly. \
> RPWPCCDCLCLORCWOWDSDDTSW is the access mask in DS DACL. It is translated to access \
> mask 0x001F01FF in SYSVOL DACL using the algorithm. In SDDL, 0x001F01FF is \
> displayed as "FA" , which means FILE_ALL_ACCESS. \
> (http://msdn.microsoft.com/en-us/library/aa374928(VS.85).aspx)
>
> > Ok so following our talks I am about to conclude that yes the algorithm
> > that you gave is OK but it only applies to DACL, SACL didn't count, user
> > and group also (I suppose that for new GPO the user/group is took from
> > the user that created the new GPO).
> > Just you need to investigate the glitches between DS ACE and FS ACE on
> > default GPO (btw what should be the owner/group of default GPO ?).
> >
>
> > Did i made a right sum-up ?
> >
> This is a right summary.
>
>
> Hongwei
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba@matws.net]
> Sent: Friday, February 26, 2010 4:04 PM
> To: Hongwei Sun
> Cc: Sebastian Canevari; pfif@tridgell.net; cifs-protocol@samba.org
> Subject: Re: [REG:110020183056252] - Inconsistencies in ACLs
>
> On 26/02/2010 02:52, Hongwei Sun wrote:
>
> > Matthieu,
> >
> > After considering what the access rights FA is associated with, I think that \
> > RPWPCCDCLCLORCWOWDSDDTSW is indeed mapped to FA if the logic is used. Please look \
> > at the output below (also attached as DS-Created.txt and SYSVOL-Created.txt)
> > In DS DACL, CC DC LC SW RP WP DT LO SD RC WD WO represents access mask of \
> > 0x000f00ff
> > Ace Mask: 0x000f00ff
> > DELETE
> > READ_CONTROL
> > WRITE_DAC
> > WRITE_OWNER
> > ACTRL_DS_CREATE_CHILD
> > ACTRL_DS_DELETE_CHILD
> > ACTRL_DS_LIST
> > ACTRL_DS_SELF
> > ACTRL_DS_READ_PROP
> > ACTRL_DS_WRITE_PROP
> > ACTRL_DS_DELETE_TREE
> > ACTRL_DS_LIST_OBJECT
> >
> > In SYSVOL DACL, "FA" is corresponding to :
> >
> > Type of access:
> > Special acccess : -Read -Write -Execute -Delete -Change Permissions -Take \
> > Ownership Detailed Access Flags : 0x001F01FF
> > FILE_READ_DATA-0x1 FILE_WRITE_DATA-0x2 FILE_APPEND_DATA-0x4
> > FILE_READ_EA-0x8 FILE_WRITE_EA-0x10 FILE_EXECUTE-0x20 \
> > FILE_DELETE_CHILD-0x40 FILE_READ_ATTRIBUTES-0x80 FILE_WRITE_ATTRIBUTES-0x100 \
> > DELETE-0x10000 READ_CONTROL-0x20000 WRITE_DAC-0x40000 \
> > WRITE_OWNER-0x80000 SYNCHRONIZE-0x100000
> > From the debugging, access mask 0x000f00ff in DS DACL does map to 0x001F01FF \
> > in SYSVOL DACL.
> Ok from the reading of the DS flags it's not obvious that all this flags
> will "merge" to give FA. I suppose we should have a rule saying when you
> have "RPWPCCDCLCLORCWOWDSDDTSW" then the associate ACE is FA full stop.
> Is there other special translations rules ?
>
> > After much of the investigation, I found that there is a little difference \
> > between default Group Policies(Domain Default and Domain Controller Default) \
> > and the ones created using GPMC.
> > The SYSVOL DACL and DS DACL of the group policy created through GPMC
> have exactly matching access masks(as per logic) and even trustees. The
> order of ACEs inside DACL are exactly matching too.
>
> > Please see the attached dump files(DS-created.txt and SYSVOL-created.txt). But \
> > for the default policies, the trustees and order of ACEs are different. The \
> > access mask mapping appears fine except for the ones with GXGR in SYSVOL DACL. \
> > Please see the attached dump files(DS-original.txt and SYSVOL-original.txt). I \
> > will work on the further clarification for the default policies. The logic we \
> > sent to you are right since they are used in GPMC tools to set the DACL on the \
> > newly created policy and fix the consistency problem as well.
> Ok so following our talks I am about to conclude that yes the algorithm
> that you gave is OK but it only applies to DACL, SACL didn't count, user
> and group also (I suppose that for new GPO the user/group is took from
> the user that created the new GPO).
> Just you need to investigate the glitches between DS ACE and FS ACE on
> default GPO (btw what should be the owner/group of default GPO ?).
>
> Did i made a right sum-up ?
>
> Matthieu
>
> >
> > Thanks!
> >
> > Hongwei
> >
> >
> > -----Original Message-----
> > From: Matthieu Patou [mailto:mat+Informatique.Samba@matws.net]
> > Sent: Wednesday, February 17, 2010 1:46 AM
> > To: Hongwei Sun
> > Cc: Sebastian Canevari; pfif@tridgell.net; cifs-protocol@samba.org
> > Subject: Re: [REG:110020183056252] - Inconsistencies in ACLs
> >
> > Hello Hongwei,
> > On 17/02/2010 03:21, Hongwei Sun wrote:
> >
> > > Matthieu,
> > >
> > > I now own the case for your new question regarding ACL on SYSVOL. First , \
> > > making ACL consistent between the DS object and the corresponding SYSVOL \
> > > object only applies to the DACL part of the security descriptor, just as shown \
> > > in the logic. Therefore, it can be explained why the owner and group SID could \
> > > be different. Besides being consistent with SYSVOL folder object, DS \
> > > objects also need to satisfy the security descriptor requirements for Active \
> > > Directory , as described in 7.1.3 of MS-ADTS.
> >
> > > As you suggested, I dumped the ACL of DS policy object and also dumped SYSVOL \
> > > folder object's ACL using subinacl in Windows server 2008 R2.
> > > The output is similar to what you shown in your mail. After
> > debugging, it seems that the logic mapping access masks between DS
> > policy objects and SYSVOL folder objects is correct.
> > > For example, for the access mask (0x00020094 or "RPLCLORC" ) in DS
> > ACL, applying the logic will translate it to access mask of 0x001200A9
> > in SYSVOL folder ACL. This result matches the output of dump.
> > I a recopying what I sent
> > > So for instance a w2k3 server acting as a DC I have :
> > >
> > c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C016F-11D2-945F-00C04fB984F9}
> > /sddl=
> > O:BAG:SYD:PARAI(A;;0x1200a9;;;AU)(A;OICIIO;GXGR;;;AU)(A;;0x1200a9;;;SO)
> > (A;OICIIO;GXGR;;;SO)(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;FA;;;BA)(A;OICIIO;GA;;;CO)
> >
> > >
> > So we have AU, SO, BA, SY and CO as trustees in the different ACE for
> > the DACL part.
> >
> > > It was obtained from:
> > > subinacl.exe /file
> > > c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C-016F-11D2-945F-0
> > > 0C04fB984F9} /display=sddl
> > >
> > > But if dump the ACL of the object
> > >
> > >
> > CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=Samba,DC=net
> > >
> > >
> > O:DAG:DAD:PAI(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;; \
> > EA)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;CI;R \
> > PWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;RPLCLORC;;;ED)
> >
> > S:AI(OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-0000f80367c1;WD)(OU;CIIOIDSA;WP;f30e3 \
> > bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOID \
> > SA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
> >
> > here for the DACL part we have those trustees:DA,EA,CO,SY,AU,ED
> >
> > From my understanding we should find the different trustees of the DS
> > ACL in the SYSVOL ACL (ie. something like '(A;;0x1200a9;;;ED)') then for
> > the trustees that are effectively present in the two ACLs (CO, or SY) we
> > have completely different ACL I'm not sure that RPWPCCDCLCLORCWOWDSDDTSW
> > translate only to FA.
> >
> > Matthieu.
> >
> > > -----Original Message-----
> > > From: cifs-protocol-bounces@cifs.org [mailto:cifs-protocol-bounces@cifs.org] On \
> > > Behalf Of Sebastian Canevari
> > > Sent: Monday, February 01, 2010 5:29 PM
> > > To: Bill Wesse; Matthieu Patou
> > > Cc: pfif@tridgell.net; cifs-protocol@samba.org
> > > Subject: Re: [cifs-protocol] Status: SRX091112600382 [MS-GPOL] - OI and CI \
> > > flags on every ACL entries
> > > Hi Matthieu,
> > >
> > > I am still working with the product group on documenting what we have been \
> > > working on (the way GPMC checks and corrects the ACLs).
> > > It's become a little bit more complicated than anticipated but I will keep you \
> > > updated of the progress as soon as I have news.
> > > On the other hand, I have just created a case with your new set of \
> > > observations/questions and someone from my team will contact you shortly to \
> > > follow up about this new case.
> > > Thanks and regards,
> > >
> > > Sebastian
> > >
> > >
> > >
> > > Sebastian Canevari
> > > Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > > 7100 N Hwy 161, Irving, TX - 75039
> > > "Las Colinas - LC2"
> > > Tel: +1 469 775 7849
> > > e-mail: sebastc@microsoft.com
> > >
> > >
> > > -----Original Message-----
> > > From: Bill Wesse
> > > Sent: Monday, February 01, 2010 7:20 AM
> > > To: Matthieu Patou
> > > Cc: Sebastian Canevari; cifs-protocol@samba.org; pfif@tridgell.net
> > > Subject: RE: Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL \
> > > entries
> > > Good morning again. Sebastian will be back in the office today; I have just \
> > > reassigned this case back to him.
> > > Sebastian - Matthieu has replied to my email from last Thursday with ACL/SDDL \
> > > considerations that look to be a new case. I was unfortunately taken ill last \
> > > Friday, and was not able to respond.
> > > Regards,
> > > Bill Wesse
> > > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > > 8055 Microsoft Way
> > > Charlotte, NC 28273
> > > Email: billwe@microsoft.com
> > > Tel: +1(980) 776-8200
> > > Cell: +1(704) 661-5438
> > > Fax: +1(704) 665-9606
> > >
> > >
> > > -----Original Message-----
> > > From: Matthieu Patou [mailto:mat+Informatique.Samba@matws.net]
> > > Sent: Friday, January 29, 2010 6:05 PM
> > > To: Bill Wesse
> > > Cc: Sebastian Canevari; cifs-protocol@samba.org; pfif@tridgell.net
> > > Subject: Re: Status: SRX091112600382 [MS-GPOL] - OI and CI flags on every ACL \
> > > entries
> > > On 28/01/2010 19:54, Bill Wesse wrote:
> > >
> > > > Good day Matthieu. Please note that my colleague Sebastian is out of the \
> > > > office for the next few days. In the interim, I will be your contact. Thanks \
> > > > in advance for your patience!
> > > > I have reviewed the case, and want to make sure I address any open questions. \
> > > > My current read indicates we haven't answered the below question. Could you \
> > > > confirm this is the case, and advise me of any other open questions you have? \
> > > > And last but not least question, it seems that GPMC wants to have OI and CI \
> > > > flags on every ACL entries; is it due to the presence of the \
> > > > "SDDL_AUTO_INHERITED">control in the SDDL?
> > > >
> > > Well I'm not sure of this because I remember an email from Hongwei that told me \
> > > that they were set because it was coded like that ...
> > > But in fact I would like to come back to you about NT ACLs (but maybe it might \
> > > be filled in another case let me know if you want to do so). Lately I \
> > > discovered that subinacl is able du dump NT ACLs in SDDL format. I checked and \
> > > it seems that the dump is ok (at least the owner is ok, the different granted \
> > > users/groups are ok also). So for instance a w2k3 server acting as a DC I have \
> > > : c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C-016F-11D2-945F-0
> > > 0C04fB984F9}
> > > /sddl=O:BAG:SYD:PARAI(A;;0x1200a9;;;AU)(A;OICIIO;GXGR;;;AU)(A;;0x1200a9;;;SO)(A;
> > > OICIIO;GXGR;;;SO)(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;
> > > ;FA;;;BA)(A;OICIIO;GA;;;CO)
> > >
> > > It was obtained from:
> > > subinacl.exe /file
> > > c:\WINDOWS\SYSVOL\sysvol\samba.net\Policies\{6AC1786C-016F-11D2-945F-0
> > > 0C04fB984F9} /display=sddl
> > >
> > > But if dump the ACL of the object
> > >
> > > CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=Samba,DC=net
> > >
> > > O:DAG:DAD:PAI(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW; \
> > > ;;EA)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;DA)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A; \
> > > CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d \
> > > 1-b41d-00a0c968f939;;AU)(A;CI;RPLCLORC;;;ED)S:AI(OU;CIIDSA;WPWD;;f30e3bc2-9ff0-1 \
> > > 1d1-b603-0000f80367c1;WD)(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf \
> > > 967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
> > >
> > >
> > > So even if we remove the SACL and apply the transformation rules proposed \
> > > before there is a huge difference between the file DS ACL and the associated \
> > > file ACL (owner/group is different, BA is used in file ACL when DA is used in \
> > > DS ACL). So it is seems that the logic is not ok (although it makes gpmc \
> > > happy).
> > > Can you explain this ? Can you take from your side dump of a fresh
> > > w2k3r2 dc (or w2k8/w2k8r2) and look for the ACL on files/dir associated with \
> > > GPO and with the GPO objects as well ?
> > > Regards.
> > > Matthieu.
> > >
> > >
> > > > Thanks in advance!
> > > >
> > > > Regards,
> > > > Bill Wesse
> > > > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > > > 8055 Microsoft Way
> > > > Charlotte, NC 28273
> > > > Email: billwe@microsoft.com
> > > > Tel: +1(980) 776-8200
> > > > Cell: +1(704) 661-5438
> > > > Fax: +1(704) 665-9606
> > > >
> > > > From: Matthieu Patou [mailto:mat+Informatique.Samba@matws.net]
> > > > Sent: Tuesday, December 22, 2009 3:56 PM
> > > > To: Hongwei Sun
> > > > Cc: Sebastian Canevari; cifs-protocol@samba.org; pfif@tridgell.net
> > > > Subject: Re: FW: [cifs-protocol] Group Policy questions
> > > >
> > > > On 23/12/2009 00:47, Hongwei Sun wrote:
> > > >
> > > >
> > > > > Matthieu,
> > > > >
> > > > > Your summary is a good recap of what we have done on this topic. I have \
> > > > > one clarification for the point below.
> > > > > * All ACE for allowed object are wipped out when
> > > > > "translating" AD ACL to File ACL
> > > > >
> > > > > When translating a ACL for DS object to a ACL for SYSVOL file object, the \
> > > > > ACEs with types of ACCESS_ALLOWED_OBJECT_ACE_TYPE, \
> > > > > ACCESS_DENIED_OBJECT_ACE_TYPE and SYSTEM_AUDIT_OBJECT_ACE_TYPE are not \
> > > > > really deleted from the ACL. Instead, for such a ACE, access mask in \
> > > > > AceHeader is assigned to zero.
> > > > >
> > > > >
> > > > Yeah I meant that when "translating" an AD ACL to a file ACL we do not care \
> > > > about it, for all those ACCESS_ALLOWED_OBJECT_ACE_TYPE in the AD no \
> > > > corresponding ACE in created.
> > > >
> > > >
> > > >
> > > > > Sebastian will follow up with you on your question regarding documenting \
> > > > > the logic for ACE OI and CI flags.
> > > > > Thanks!
> > > > >
> > > > > Hongwei
> > > > >
> > > > >
> > > > >
> > >
> > > _______________________________________________
> > > cifs-protocol mailing list
> > > cifs-protocol@cifs.org
> > > https://lists.samba.org/mailman/listinfo/cifs-protocol
> > >
> > >
> >
> >
>
>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic