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: [email protected] [mailto:[email protected]] On
Behalf Of Sebastian Canevari
Sent: Monday, February 01, 2010 5:29 PM
To: Bill Wesse; Matthieu Patou
Cc: [email protected]; [email protected]
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: [email protected]
-----Original Message-----
From: Bill Wesse
Sent: Monday, February 01, 2010 7:20 AM
To: Matthieu Patou
Cc: Sebastian Canevari; [email protected]; [email protected]
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: [email protected]
Tel: +1(980) 776-8200
Cell: +1(704) 661-5438
Fax: +1(704) 665-9606
-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Friday, January 29, 2010 6:05 PM
To: Bill Wesse
Cc: Sebastian Canevari; [email protected]; [email protected]
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: [email protected]
Tel: +1(980) 776-8200
Cell: +1(704) 661-5438
Fax: +1(704) 665-9606
From: Matthieu Patou [mailto:[email protected]]
Sent: Tuesday, December 22, 2009 3:56 PM
To: Hongwei Sun
Cc: Sebastian Canevari; [email protected]; [email protected]
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
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
