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; p...@tridgell.net; cifs-proto...@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.sa...@matws.net] Sent: Friday, February 26, 2010 4:04 PM To: Hongwei Sun Cc: Sebastian Canevari; p...@tridgell.net; cifs-proto...@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.sa...@matws.net] > Sent: Wednesday, February 17, 2010 1:46 AM > To: Hongwei Sun > Cc: Sebastian Canevari; p...@tridgell.net; cifs-proto...@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;RPWPCCDCLCLORCWOWDSDDTSW;;;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;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;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-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] >> On Behalf Of Sebastian Canevari >> Sent: Monday, February 01, 2010 5:29 PM >> To: Bill Wesse; Matthieu Patou >> Cc: p...@tridgell.net; cifs-proto...@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: seba...@microsoft.com >> >> >> -----Original Message----- >> From: Bill Wesse >> Sent: Monday, February 01, 2010 7:20 AM >> To: Matthieu Patou >> Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@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: bil...@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.sa...@matws.net] >> Sent: Friday, January 29, 2010 6:05 PM >> To: Bill Wesse >> Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@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-11d1-b41d-00a0c968f939;;AU)(A;CI;RPLCLORC;;;ED)S:AI(OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-0000f80367c1;WD)(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-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: bil...@microsoft.com >>> Tel: +1(980) 776-8200 >>> Cell: +1(704) 661-5438 >>> Fax: +1(704) 665-9606 >>> >>> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] >>> Sent: Tuesday, December 22, 2009 3:56 PM >>> To: Hongwei Sun >>> Cc: Sebastian Canevari; cifs-proto...@samba.org; p...@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