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. Sebastian will follow up with you on your question regarding documenting the logic for ACE OI and CI flags. Thanks! Hongwei -----Original Message----- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Friday, December 18, 2009 4:01 PM To: Sebastian Canevari Cc: Hongwei Sun; Interoperability Documentation Help; cifs-proto...@samba.org Subject: Re: FW: [cifs-protocol] Group Policy questions Hello Sebastian and Hongwei, Sorry for being silent on this. So if I try to sum up we agreed that: * in order to allow modification of ACL on files sdeffectiverights must have the flag DACL_SECURITY_INFORMATION set, and the ACL must have the SE_DACL_PROTECTED set in the control flags. * in order to avoid a warning message ACL of Policy object must be synchronized with ACL in the files following this logic for the translation: The specific rights in access mask for Active Directory object are defined in 5.1.3.2 of MS-ADTS as follows. #define RIGHT_DS_CREATE_CHILD 0x00000001 #define RIGHT_DS_DELETE_CHILD 0x00000002 #define RIGHT_DS_LIST_CONTENTS 0x00000004 #define ACTRL_DS_SELF 0x00000008 #define RIGHT_DS_READ_PROPERTY 0x00000010 #define RIGHT_DS_WRITE_PROPERTY 0x00000020 #define RIGHT_DS_DELETE_TREE 0x00000040 #define RIGHT_DS_LIST_OBJECT 0x00000080 #define RIGHT_DS_CONTROL_ACCESS 0x00000100 The specific rights in access mask for a file or directory object are defined as (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx ) #define FILE_READ_DATA ( 0x0001 ) #define FILE_LIST_DIRECTORY ( 0x0001 ) #define FILE_WRITE_DATA ( 0x0002 ) #define FILE_ADD_FILE ( 0x0002 ) #define FILE_APPEND_DATA ( 0x0004 ) #define FILE_ADD_SUBDIRECTORY ( 0x0004 ) #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 ) #define FILE_READ_EA ( 0x0008 ) #define FILE_WRITE_EA ( 0x0010 ) #define FILE_EXECUTE ( 0x0020 ) #define FILE_TRAVERSE ( 0x0020 ) #define FILE_DELETE_CHILD ( 0x0040 ) #define FILE_READ_ATTRIBUTES ( 0x0080 ) #define FILE_WRITE_ATTRIBUTES ( 0x0100 ) The generic access rights that are common to all objects are #define DELETE (0x00010000L) #define READ_CONTROL (0x00020000L) #define WRITE_DAC (0x00040000L) #define WRITE_OWNER (0x00080000L) #define SYNCHRONIZE (0x00100000L) #define STANDARD_RIGHTS_ALL (0x001F0000L) The following logic is used by GPMC to convert a access mask for DS object to a access mask for SYSVOL. DSAccessMask as Input; SYSVOLAccessMask as Output; SYSVOLAccessMask = DSAccessMask; SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ; if ((DSAccessMask& RIGHT_DS_READ_PROPERTY) AND (DSAccessMask& RIGHT_DS_LIST_CONTENTS)) SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY | FILE_READ_ATTRIBUTES | FILE_READ_EA | FILE_READ_DATA | FILE_EXECUTE); if (DSAccessMask& RIGHT_DS_WRITE_PROPERTY) SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA | FILE_APPEND_DATA | FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE | FILE_ADD_SUBDIRECTORY); if (DSAccessMask& RIGHT_DS_CREATE_CHILD) SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY | FILE_ADD_FILE); if (DSAccessMask& RIGHT_DS_DELETE_CHILD) SYSVOLAccessMask |= FILE_DELETE_CHILD; * All ACE for allowed object are wipped out when "translating" AD ACL to File ACL * For the following ACE OI and CI flags are always set in the resulting file ACE: ACCESS_ALLOWED_ACE_TYPE ACCESS_DENIED_ACE_TYPE SYSTEM_AUDIT_ACE_TYPE Am I right ? For the part that are "hardcoded" like this will it change any time soon ? Also do you plan to document this in any kind of document ? if so which and when ? Regards. Matthieu. On 12/12/2009 01:00, Sebastian Canevari wrote: > Hi Matthieu, > > With regards to ACCESS_ALLOWED_OBJECT_ACE, we do wipe it in the process. > That's hardcoded. > > With regards to the RU... > > I need further clarification on what you are actually seeing. > > It is my understanding and that since prew2k clients will not download > policies, the ACEs will be cleared if they contain that well known SID. > > We are still investigating but please let me know if that explains what you > are seeing. > > > Thanks! > > > 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: Sebastian Canevari > Sent: Thursday, December 10, 2009 2:19 PM > To: 'Matthieu Patou' > Cc: Hongwei Sun; cifs-proto...@samba.org; p...@tridgell.net > Subject: RE: FW: [cifs-protocol] Group Policy questions > > Hi Matthieu, > > With regards of the OI and CI flags, we always set those flags on if the ACE > type is any of the following 3 types: > > ACCESS_ALLOWED_ACE_TYPE > ACCESS_DENIED_ACE_TYPE > SYSTEM_AUDIT_ACE_TYPE > > This is hardcoded. > > I'll provide you with the answer to your other question soon. > > 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] > Sent: Friday, December 04, 2009 3:32 PM > To: Sebastian Canevari > Cc: Hongwei Sun; cifs-proto...@samba.org; p...@tridgell.net > Subject: Re: FW: [cifs-protocol] Group Policy questions > > On 04/12/2009 23:00, Sebastian Canevari wrote: > >> Hi Matthieu, >> >> Just a clarification to ask you for: >> >> We are discussing with Hongwei and the PGs if it is that you are seeing >> GPMC "expect" the inheritance to happen OR if it is that you are dumping the >> ACLs and "seeing" the flags always. >> >> >> > What I see if when I dump the SD of the files modified by GPMC after it > realize that there was a mismatch between the SD in AD and the SD in the > Policy folder. > Note: it was with XP sp2 as a client. > > Matthieu. > >> Please clarify because we were under the impression that we had to look into >> the client tool, but if the latter is what your question means, then we need >> to look into AD. >> >> Thanks and regards, >> >> >> >> 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: Sebastian Canevari >> Sent: Thursday, December 03, 2009 4:18 PM >> To: 'Matthieu Patou'; cifs-proto...@samba.org; Interoperability >> Documentation Help; p...@tridgell.net >> Subject: RE: FW: [cifs-protocol] Group Policy questions >> >> Hi Matthieu, >> >> We are still actively working on this and I do have the PG engaged. >> >> Please accept my apologies if we are delaying a little longer than expected. >> I guess we can say that the holidays affected the timing a little without >> trying to use that as an excuse. >> >> I'll keep you posted as soon as I have news. >> >> 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] >> Sent: Thursday, December 03, 2009 4:05 PM >> To: Sebastian Canevari; cifs-proto...@samba.org; Interoperability >> Documentation Help; p...@tridgell.net >> Subject: Re: FW: [cifs-protocol] Group Policy questions >> >> Hello sebastian >> >> >> >>> And last but not least question, it seems that GPMC whats 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 ? >>> >>> >> Any news on this ? >> More exactly my question is why this flag appear on each ACE ? >> >> Also do you plan to document this in a WSPP document ? >> >> Regards. >> Matthieu. >> On 13/11/2009 02:40, Sebastian Canevari wrote: >> >> >>> Hi Matthieu, >>> >>> >>> I'll be working with you on these questions. >>> >>> I will keep you updated. >>> >>> Thanks! >>> >>> 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: Hongwei Sun >>> Sent: Wednesday, November 11, 2009 9:35 PM >>> To: Matthieu Patou >>> Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari >>> Subject: RE: FW: [cifs-protocol] Group Policy questions >>> >>> Matthieu, >>> >>> I double checked the logic and your assumption is right. The return >>> value for SYSVOL access mask should be assigned to the input value first. >>> For your other questions, since I am out of office , Sebastian will work >>> on them and let you know. >>> >>> Thanks! >>> >>> Hongwei >>> >>> -----Original Message----- >>> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] >>> Sent: Wednesday, November 11, 2009 12:22 AM >>> To: Hongwei Sun >>> Cc: cifs-proto...@samba.org; p...@tridgell.net >>> Subject: Re: FW: [cifs-protocol] Group Policy questions >>> >>> Hello Hongwei, >>> >>> I've been working on the translation function, I am getting quite similar >>> ACL right now but I have some remarks and questions. >>> >>> The pseudo code contains this: >>> >>> DSAccessMask as Input; >>> SYSVOLAccessMask as Output; >>> >>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ; >>> >>> I have impression that it should be >>> >>> DSAccessMask as Input; >>> SYSVOLAccessMask as Output; >>> >>> SYSVOLAccessMask = DSAccessMask; >>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ; >>> >>> >>> Maybe the third line is implied in this kind of pseudo code. >>> >>> Also it seems to me that GPMC is discarding any ACL of type >>> ACCESS_ALLOWED_OBJECT_ACE (OA) and also everything related to SID >>> SID_BUILTIN_PREW2K (RU). >>> >>> And last but not least question, it seems that GPMC whats 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 ? >>> >>> Thanks for your answers. >>> >>> Matthieu. >>> >>> On 29/10/2009 05:31, Hongwei Sun wrote: >>> >>> >>> >>>> Matthieu, >>>> >>>> I keep receiving the message from our e-mail server about the >>>> undeliverable e-mail to one of the address(cifs-protocol@cifs.org), which >>>> is in your original e-mail. In order to make sure you receive the email, >>>> I just forward it again. >>>> >>>> If you already received it, please let me know if it resolved your >>>> issue. >>>> >>>> Thanks! >>>> >>>> Hongwei >>>> >>>> >>>> -----Original Message----- >>>> From: Hongwei Sun >>>> Sent: Monday, October 26, 2009 6:14 PM >>>> To: Matthieu Patou; cifs-protocol@cifs.org; p...@tridgell.net >>>> Subject: RE: [cifs-protocol] Group Policy questions >>>> >>>> Matthieu, >>>> >>>> Matthieu, >>>> >>>> The attached GPMC log shows the problem of inconsistency >>>> between ACLs of the policy object and that of SYSVOL folders. The >>>> log shows that >>>> >>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE] >>>> CGPMGPO::IsAclConsistent():Checking Aces for SID >>>> S-1-5-21-2212615479-2695158682-2101375467-512 >>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE] >>>> GetSysvolPermissionsFromDSPermissions: DS access mask is 0xf00ff ...... >>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE] >>>> CGPMGPO::IsAclConsistent(): ACLs not consistent for >>>> SID<S-1-5-21-2212615479-2695158682-2101375467-512>. Mask: Expected >>>> 0x1f01ff, Found 0xf00ff >>>> >>>> The access mask for the ace of Active Directory policy object is >>>> 0xf00ff. When the GPMO converts the access mask to a corresponding file >>>> system access mask, it expects 0x1f01ff. For SYSVOL, you set the access >>>> mask to 0xf00ff. They don't match and that is why inconsistency is >>>> declared. In the SYSVOL access mask you set, you missed >>>> 0x100000(SYNCHRONIZE) and 0x100(FILE_WRITE_ATTRIBUTES). >>>> >>>> Since AD objects and SYSVOL file/folder objects are different >>>> objects, their specific rights in access mask are not one-to-one >>>> matched. The following are the definitions of bits for both objects. >>>> >>>> The specific rights in access mask for Active Directory object are >>>> defined in 5.1.3.2 of MS-ADTS as follows. >>>> >>>> #define RIGHT_DS_CREATE_CHILD 0x00000001 >>>> #define RIGHT_DS_DELETE_CHILD 0x00000002 >>>> #define RIGHT_DS_LIST_CONTENTS 0x00000004 >>>> #define ACTRL_DS_SELF 0x00000008 >>>> #define RIGHT_DS_READ_PROPERTY 0x00000010 >>>> #define RIGHT_DS_WRITE_PROPERTY 0x00000020 >>>> #define RIGHT_DS_DELETE_TREE 0x00000040 >>>> #define RIGHT_DS_LIST_OBJECT 0x00000080 >>>> #define RIGHT_DS_CONTROL_ACCESS 0x00000100 >>>> >>>> The specific rights in access mask for a file or directory >>>> object are defined as >>>> (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx ) >>>> >>>> #define FILE_READ_DATA ( 0x0001 ) >>>> #define FILE_LIST_DIRECTORY ( 0x0001 ) >>>> #define FILE_WRITE_DATA ( 0x0002 ) >>>> #define FILE_ADD_FILE ( 0x0002 ) >>>> #define FILE_APPEND_DATA ( 0x0004 ) >>>> #define FILE_ADD_SUBDIRECTORY ( 0x0004 ) >>>> #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 ) >>>> #define FILE_READ_EA ( 0x0008 ) >>>> #define FILE_WRITE_EA ( 0x0010 ) >>>> #define FILE_EXECUTE ( 0x0020 ) >>>> #define FILE_TRAVERSE ( 0x0020 ) >>>> #define FILE_DELETE_CHILD ( 0x0040 ) >>>> #define FILE_READ_ATTRIBUTES ( 0x0080 ) >>>> #define FILE_WRITE_ATTRIBUTES ( 0x0100 ) >>>> >>>> The generic access rights that are common to all objects are >>>> >>>> #define DELETE (0x00010000L) >>>> #define READ_CONTROL (0x00020000L) >>>> #define WRITE_DAC (0x00040000L) >>>> #define WRITE_OWNER (0x00080000L) >>>> #define SYNCHRONIZE (0x00100000L) >>>> #define STANDARD_RIGHTS_ALL (0x001F0000L) >>>> >>>> >>>> The following logic is used by GPMC to convert a access mask for DS >>>> object to a access mask for SYSVOL. >>>> >>>> DSAccessMask as Input; >>>> SYSVOLAccessMask as Output; >>>> >>>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ; >>>> >>>> if ((DSAccessMask& RIGHT_DS_READ_PROPERTY) AND >>>> (DSAccessMask& RIGHT_DS_LIST_CONTENTS)) >>>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY | >>>> FILE_READ_ATTRIBUTES | FILE_READ_EA | >>>> FILE_READ_DATA | FILE_EXECUTE); >>>> >>>> if (DSAccessMask& RIGHT_DS_WRITE_PROPERTY) >>>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA | >>>> FILE_APPEND_DATA | FILE_WRITE_EA | >>>> FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE | >>>> FILE_ADD_SUBDIRECTORY); >>>> >>>> >>>> if (DSAccessMask& RIGHT_DS_CREATE_CHILD) >>>> SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY | >>>> FILE_ADD_FILE); >>>> >>>> >>>> if (DSAccessMask& RIGHT_DS_DELETE_CHILD) >>>> SYSVOLAccessMask |= FILE_DELETE_CHILD; >>>> >>>> >>>> Please let me know if this solves your problem. I will file a >>>> request to update the document accordingly. >>>> >>>> Thanks! >>>> >>>> Hongwei >>>> >>>> >>>> -----Original Message----- >>>> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] >>>> Sent: Sunday, October 25, 2009 5:48 AM >>>> To: cifs-protocol@cifs.org; Hongwei Sun; Interoperability >>>> Documentation Help; p...@tridgell.net >>>> Subject: Re: [cifs-protocol] Group Policy questions >>>> >>>> Hello hongwei, >>>> >>>> On 10/20/2009 01:05 PM, Matthieu Patou wrote: >>>> >>>> >>>> >>>> >>>>> Hi Hongwei, >>>>> For the moment it's quite clear why we fail as we do not set any >>>>> ACL by default on the sysvol volume. >>>>> I will already fix this + the sDRightsEffective attribute and I'll >>>>> see if it do the job. >>>>> >>>>> >>>>> >>>>> >>>> I worked a little bit on the ACL and still face "unsynchronized" ACL >>>> despite the fact that now our Policy folder are created with the same ACL >>>> as in AD. >>>> >>>> Let's take the following >>>> policy:{7557D70F-14C9-4EA5-8369-10AE7C2C31D3} >>>> >>>> I face the message that the ACL is unconsitent with the one stored >>>> in the AD, after clicking on yes GPMC changed the ACL for >>>> >>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479 >>>> - >>>> 2 >>>> 695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-221261547 >>>> 9 >>>> - >>>> 2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2 >>>> 6 >>>> 9 >>>> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695 >>>> 1 >>>> 5 >>>> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158 >>>> 6 >>>> 8 >>>> 2-2101375467-512)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;SY)( >>>> A >>>> ; >>>> OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001f01bf;;;BA >>>> ) >>>> ( >>>> A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)S: >>>> A >>>> I >>>> (OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d >>>> 0 >>>> - >>>> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f8036 >>>> 7 >>>> c >>>> 1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) >>>> >>>> Before it was: >>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479 >>>> - >>>> 2 >>>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21 >>>> - >>>> 2 >>>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S >>>> - >>>> 1 >>>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDD >>>> T >>>> S >>>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORC >>>> W >>>> O >>>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPW >>>> P >>>> C >>>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCL >>>> O >>>> R >>>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC >>>> ; >>>> ; >>>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWD >>>> S >>>> D >>>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU >>>> ) >>>> S >>>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6- >>>> 1 >>>> 1 >>>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f8 >>>> 0 >>>> 3 >>>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) >>>> >>>> >>>> And if I request the nTSecurityDescriptor for this object in the AD I get: >>>> {7557D70F-14C9-4EA5-8369-10AE7C2C31D3} >>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479 >>>> - >>>> 2 >>>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21 >>>> - >>>> 2 >>>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S >>>> - >>>> 1 >>>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDD >>>> T >>>> S >>>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORC >>>> W >>>> O >>>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPW >>>> P >>>> C >>>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCL >>>> O >>>> R >>>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC >>>> ; >>>> ; >>>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWD >>>> S >>>> D >>>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU >>>> ) >>>> S >>>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6- >>>> 1 >>>> 1 >>>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f8 >>>> 0 >>>> 3 >>>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD) >>>> >>>> >>>> Which looks like the ACL that were present for the file. >>>> I also made a tcpdump capture (attached to this mail) and it's clear that >>>> the nTSecurityDescriptor is like the one just above. (packet 927). >>>> >>>> So what's going on, with an ACL that is the same when stored in the AD, >>>> transmitted through LDAP and stored in the file we have at the end GPMC >>>> that change the value but it's hard to understand how it construct this >>>> ACL. >>>> >>>> I attached also the GPMC log when I clicked on "OK" so that the ACL in AD >>>> and ACL for the file are synchronized (well from GPMC point of view). >>>> >>>> >>>> >>>> >>>> >>>> >>>>> I will try to use also the same SSDL as in w2k3 to see if I have >>>>> the same resulting delagation or not. >>>>> >>>>> For the moment I have some tests to do before going back to you. >>>>> >>>>> Regards. >>>>> Matthieu. >>>>> On 10/20/2009 03:11 AM, Hongwei Sun wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Matthieu, >>>>>> >>>>>> For Problem #1, only the SE_DACL_PROTECTED(0x1000) has to be set >>>>>> for ControlFlag in Security Descriptor in order to pass the step 2 >>>>>> in consistency testing. This is translated to "P" flag in SDDL. >>>>>> With this said, it is normal to have D:PAI since this will >>>>>> indicate that the SE_DACL_PROTECTED bit is set. It seems that your >>>>>> Security Descriptor is right in this regard. We have to get more >>>>>> information to see why the consistency checking fails. Could you >>>>>> enable GPMC logging as described in my previous mail? Please >>>>>> enable VERBOSE for Gpmgmttracelevel. >>>>>> >>>>>> Just for your reference, you can also use ldp.exe to display the >>>>>> security descriptor of a policy object in SSDL string format and >>>>>> parsed display format. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Hongwei >>>>>> >>>>>> -----Original Message----- >>>>>> From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] >>>>>> Sent: Saturday, October 17, 2009 11:33 AM >>>>>> To: Hongwei Sun >>>>>> Cc: p...@tridgell.net; cifs-proto...@samba.org >>>>>> Subject: Re: Group Policy questions >>>>>> >>>>>> Hello Hongwei,Matthieu, >>>>>> Thank you for the answers. I have a few more questions: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> After testing, I think that I have some information to help you >>>>>>> resolve all the problems. >>>>>>> >>>>>>> Problem #1: >>>>>>> >>>>>>> As described in the following link >>>>>>> (http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 ) >>>>>>> , GPMO will check the consistency between ACLs in GPO in Active >>>>>>> Directory and ACLs of policy folders in SYSVOL when a GPO object >>>>>>> is clicked in GPMC. The logic is something like the following: >>>>>>> >>>>>>> 1. Get the security descriptor (SD) for GOP in AD and folders in >>>>>>> SYSVOL >>>>>>> >>>>>>> 2. Check both security descriptors to make sure they are DACL >>>>>>> protected (PD bit in Control flag is set). If not, ACL >>>>>>> consistency check will fail. >>>>>>> >>>>>>> 3. For every permission in AD DACL, there should be the same >>>>>>> permission in SYSVOL DACL. If all permissions have be checked >>>>>>> through in AD ACL and there is still extra permission in SYSVOL >>>>>>> ACL, ACLs are not consistent. >>>>>>> >>>>>>> Looking at the your attached SSDL of the new policy, it doesn't >>>>>>> have PD bit set. (D:PAI means DI bit is set, which is not DACL >>>>>>> protected). >>>>>>> This will fail the second step of consistency checking. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I did an extraction of a W2K3 policy and got the following SDDL: >>>>>> >>>>>> O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-320850206 >>>>>> 4 >>>>>> - >>>>>> 746857408-2662927446-512 >>>>>> >>>>>> D:PAI >>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-266 >>>>>> 2 >>>>>> 9 >>>>>> 27446-512) >>>>>> >>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-266 >>>>>> 2 >>>>>> 9 >>>>>> 27446-519) >>>>>> >>>>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-26629 >>>>>> 2 >>>>>> 7 >>>>>> 446-512) >>>>>> >>>>>> (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;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6 >>>>>> - >>>>>> 1 >>>>>> 1d0-a285-00aa003049e2;WD) >>>>>> >>>>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6 >>>>>> - >>>>>> 1 >>>>>> 1d0-a285-00aa003049e2;WD) >>>>>> >>>>>> (OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-0000f80367c1;WD) >>>>>> >>>>>> And you say that we should not have AI flag (because it's related >>>>>> to SE_DACL_AUTO_INHERITED aka DI bit) just the P flag (because >>>>>> it's related to DE_DACL_PROTECTED aka PD bit) right ? >>>>>> But the above SDDL seems to show the opposite, I can't exclude the >>>>>> fact that we have bugs when reading ACL and/or when converting >>>>>> them into SDDL but before to trying to check this I would like to >>>>>> be sure of which flag we should see. >>>>>> >>>>>> I even tweaked XCACLS.vbs (attached to this email) from >>>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 to >>>>>> make it show the value of the control and it appear that the ACL >>>>>> for the c:\windows\sysvol has both PD and DI bit sets >>>>>> >>>>>> ie. >>>>>> Directory: C:\WINDOWS\SYSVOL >>>>>> >>>>>> ControlFlags: 37892 >>>>>> >>>>>> Do gpmc pass some controls while making its LDAP request because I >>>>>> had a look at the delegated permission through GPMC and through >>>>>> dsa.msc they are really different (a lot of inherited from parents >>>>>> objects). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Problem #2: >>>>>>> >>>>>>> In GPMO, if the attribute sDRightsEffective of selected GPO >>>>>>> object has DACL_SECURITY_INFORMATION bit (0x04) set, users will >>>>>>> be prompted for ACL correction if ACLs inconsistency between AD >>>>>>> GPO and SYSVOL is detected when a GPO node is selected. You >>>>>>> should check the attribute for the GOP object in AD. >>>>>>> >>>>>>> Problem #3: >>>>>>> >>>>>>> This is basically the same logic as in (2). The "Add" and "Remove" >>>>>>> buttons in Delegation dialog are enabled only when the attribute >>>>>>> sDRightsEffective of selected GPO object has >>>>>>> DACL_SECURITY_INFORMATION (0x04) bit set. You should check the >>>>>>> attribute for the GOP object in AD. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yeah for this it seems that the obvious problem is the lack of >>>>>> sDRightsEffective in SAMBA 4. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Debugging Information: >>>>>>> >>>>>>> By the way, you can follow the instruction in this link >>>>>>> (http://technet.microsoft.com/en-us/library/cc737379(WS.10).aspx >>>>>>> ) to enable GPMC logging, if you want to troubleshoot the issues >>>>>>> related to operations in GPMC. For example, the logging will show >>>>>>> you in which step the consistency checking fails. >>>>>>> You can look for the text "CGPMGPO::IsAclConsistent()" in the >>>>>>> logs generated. >>>>>>> >>>>>>> If you need more information, please let us know. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Matthieu. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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