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: [email protected] -----Original Message----- From: Matthieu Patou [mailto:[email protected]] Sent: Friday, December 04, 2009 3:32 PM To: Sebastian Canevari Cc: Hongwei Sun; [email protected]; [email protected] 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: [email protected] > > > -----Original Message----- > From: Sebastian Canevari > Sent: Thursday, December 03, 2009 4:18 PM > To: 'Matthieu Patou'; [email protected]; Interoperability > Documentation Help; [email protected] > 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: [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-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:[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-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 >>>> [email protected] >>>> https://lists.samba.org/mailman/listinfo/cifs-protocol >>>> >>>> >>>> >>> >> >> > > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
