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: [email protected] -----Original Message----- From: Matthieu Patou [mailto:[email protected]] Sent: Thursday, December 03, 2009 4:05 PM To: Sebastian Canevari; [email protected]; Interoperability Documentation Help; [email protected] 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: [email protected] > > > -----Original Message----- > From: Hongwei Sun > Sent: Wednesday, November 11, 2009 9:35 PM > To: Matthieu Patou > Cc: [email protected]; [email protected]; 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:[email protected]] > Sent: Wednesday, November 11, 2009 12:22 AM > To: Hongwei Sun > Cc: [email protected]; [email protected] > 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([email protected]), 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; [email protected]; [email protected] >> 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:[email protected]] >> Sent: Sunday, October 25, 2009 5:48 AM >> To: [email protected]; Hongwei Sun; Interoperability >> Documentation Help; [email protected] >> 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-2212615479 >> - >> 2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26 >> 9 >> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26951 >> 5 >> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-26951586 >> 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-11d0 >> - >> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367 >> 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;;RPWPCCDCLCLORCWOWDSDDT >> S >> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCW >> O >> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWP >> C >> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLO >> R >> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC; >> ; >> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDS >> 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-0000f80 >> 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;;RPWPCCDCLCLORCWOWDSDDT >> S >> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCW >> O >> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWP >> C >> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLO >> R >> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC; >> ; >> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDS >> 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-0000f80 >> 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:[email protected]] >>>> Sent: Saturday, October 17, 2009 11:33 AM >>>> To: Hongwei Sun >>>> Cc: [email protected]; [email protected] >>>> 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-3208502064 >>>> - >>>> 746857408-2662927446-512 >>>> >>>> D:PAI >>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662 >>>> 9 >>>> 27446-512) >>>> >>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662 >>>> 9 >>>> 27446-519) >>>> >>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-266292 >>>> 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 >>> [email protected] >>> https://lists.samba.org/mailman/listinfo/cifs-protocol >>> >>> >> > > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
