FW: Group Policy questions

[Hongwei Sun]

Matthieu,

   I keep receiving the message from our e-mail server about the undeliverable e-mail to one of the address(cifs-protocol@...), 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@...; pfif@...
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.Samba@...]
Sent: Sunday, October 25, 2009 5:48 AM
To: cifs-protocol@...; Hongwei Sun; Interoperability Documentation Help; pfif@...
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-2695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-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:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)

Before it was:
O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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.Samba@...]
>> Sent: Saturday, October 17, 2009 11:33 AM
>> To: Hongwei Sun
>> Cc: pfif@...; cifs-protocol@...
>> 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-2662927446-512)
>>
>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-519)
>>
>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-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-11d0-a285-00aa003049e2;WD)
>>
>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-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@...
> https://lists.samba.org/mailman/listinfo/cifs-protocol

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Matthieu Patou-5]

Hi Hongwei,

I received your answer and it looks very interesting. I have to correct
the implementation so that ACL on folder are correctly set.
I hope to be able to do it next week. Once it's done I'll tell you about
the results.

Regards.

Matthieu.
On 10/29/2009 05:31 AM, 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@...), 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@...; pfif@...
> 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.Samba@...]
> Sent: Sunday, October 25, 2009 5:48 AM
> To: cifs-protocol@...; Hongwei Sun; Interoperability Documentation Help; pfif@...
> 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-2695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-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:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>
> Before it was:
> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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.Samba@...]
>>> Sent: Saturday, October 17, 2009 11:33 AM
>>> To: Hongwei Sun
>>> Cc: pfif@...; cifs-protocol@...
>>> 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-2662927446-512)
>>>
>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-519)
>>>
>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-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-11d0-a285-00aa003049e2;WD)
>>>
>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-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@...
>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>      
>    

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Matthieu Patou-5]

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@...), 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@...; pfif@...
> 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.Samba@...]
> Sent: Sunday, October 25, 2009 5:48 AM
> To: cifs-protocol@...; Hongwei Sun; Interoperability Documentation Help; pfif@...
> 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-2695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-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:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>
> Before it was:
> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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.Samba@...]
>>> Sent: Saturday, October 17, 2009 11:33 AM
>>> To: Hongwei Sun
>>> Cc: pfif@...; cifs-protocol@...
>>> 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-2662927446-512)
>>>
>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-519)
>>>
>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-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-11d0-a285-00aa003049e2;WD)
>>>
>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-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@...
>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>      
>    

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

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.Samba@...]
Sent: Wednesday, November 11, 2009 12:22 AM
To: Hongwei Sun
Cc: cifs-protocol@...; pfif@...
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@...), 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@...; pfif@...
> 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.Samba@...]
> Sent: Sunday, October 25, 2009 5:48 AM
> To: cifs-protocol@...; Hongwei Sun; Interoperability Documentation Help; pfif@...
> 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-2695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-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:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>
> Before it was:
> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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-2695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;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.Samba@...]
>>> Sent: Saturday, October 17, 2009 11:33 AM
>>> To: Hongwei Sun
>>> Cc: pfif@...; cifs-protocol@...
>>> 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-2662927446-512)
>>>
>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-519)
>>>
>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927446-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-11d0-a285-00aa003049e2;WD)
>>>
>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-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@...
>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Sebastian Canevari]

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: [phone]
e-mail: sebastc@...


-----Original Message-----
From: Hongwei Sun
Sent: Wednesday, November 11, 2009 9:35 PM
To: Matthieu Patou
Cc: cifs-protocol@...; pfif@...; 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.Samba@...]
Sent: Wednesday, November 11, 2009 12:22 AM
To: Hongwei Sun
Cc: cifs-protocol@...; pfif@...
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@...), 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@...; pfif@...
> 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.Samba@...]
> Sent: Sunday, October 25, 2009 5:48 AM
> To: cifs-protocol@...; Hongwei Sun; Interoperability
> Documentation Help; pfif@...
> 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-269
> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-269515
> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-269515868
> 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:AI
> (OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-
> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c
> 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;;RPWPCCDCLCLORCWOWDSDDTS
> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWO
> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPC
> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLOR
> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;
> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSD
> 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-11
> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f803
> 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;;RPWPCCDCLCLORCWOWDSDDTS
> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWO
> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPC
> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLOR
> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;
> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSD
> 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-11
> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f803
> 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.Samba@...]
>>> Sent: Saturday, October 17, 2009 11:33 AM
>>> To: Hongwei Sun
>>> Cc: pfif@...; cifs-protocol@...
>>> 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-26629
>>> 27446-512)
>>>
>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-26629
>>> 27446-519)
>>>
>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927
>>> 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@...
>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Matthieu Patou-5]

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: [phone]
> e-mail: sebastc@...
>
>
> -----Original Message-----
> From: Hongwei Sun
> Sent: Wednesday, November 11, 2009 9:35 PM
> To: Matthieu Patou
> Cc: cifs-protocol@...; pfif@...; 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.Samba@...]
> Sent: Wednesday, November 11, 2009 12:22 AM
> To: Hongwei Sun
> Cc: cifs-protocol@...; pfif@...
> 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@...), 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@...; pfif@...
>> 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.Samba@...]
>> Sent: Sunday, October 25, 2009 5:48 AM
>> To: cifs-protocol@...; Hongwei Sun; Interoperability
>> Documentation Help; pfif@...
>> 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-269
>> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-269515
>> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-269515868
>> 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:AI
>> (OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-
>> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c
>> 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;;RPWPCCDCLCLORCWOWDSDDTS
>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWO
>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPC
>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLOR
>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;
>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSD
>> 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-11
>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f803
>> 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;;RPWPCCDCLCLORCWOWDSDDTS
>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWO
>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPWPC
>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLOR
>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC;;
>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWDSD
>> 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-11
>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f803
>> 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.Samba@...]
>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>> To: Hongwei Sun
>>>> Cc: pfif@...; cifs-protocol@...
>>>> 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-26629
>>>> 27446-512)
>>>>
>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-26629
>>>> 27446-519)
>>>>
>>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-2662927
>>>> 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@...
>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>
>>>        
>>      
>
>    

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Sebastian Canevari]

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: [phone]
e-mail: sebastc@...


-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
Sent: Thursday, December 03, 2009 4:05 PM
To: Sebastian Canevari; cifs-protocol@...; Interoperability Documentation Help; pfif@...
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: [phone]
> e-mail: sebastc@...
>
>
> -----Original Message-----
> From: Hongwei Sun
> Sent: Wednesday, November 11, 2009 9:35 PM
> To: Matthieu Patou
> Cc: cifs-protocol@...; pfif@...; 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.Samba@...]
> Sent: Wednesday, November 11, 2009 12:22 AM
> To: Hongwei Sun
> Cc: cifs-protocol@...; pfif@...
> 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@...), 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@...; pfif@...
>> 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.Samba@...]
>> Sent: Sunday, October 25, 2009 5:48 AM
>> To: cifs-protocol@...; Hongwei Sun; Interoperability
>> Documentation Help; pfif@...
>> 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:mat+Informatique.Samba@...]
>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>> To: Hongwei Sun
>>>> Cc: pfif@...; cifs-protocol@...
>>>> 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
>>> cifs-protocol@...
>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>
>>>
>>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Matthieu Patou-5]

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: [phone]
> e-mail: sebastc@...
>
>
> -----Original Message-----
> From: Sebastian Canevari
> Sent: Thursday, December 03, 2009 4:18 PM
> To: 'Matthieu Patou'; cifs-protocol@...; Interoperability Documentation Help; pfif@...
> 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: [phone]
> e-mail: sebastc@...
>
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
> Sent: Thursday, December 03, 2009 4:05 PM
> To: Sebastian Canevari; cifs-protocol@...; Interoperability Documentation Help; pfif@...
> 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: [phone]
>> e-mail: sebastc@...
>>
>>
>> -----Original Message-----
>> From: Hongwei Sun
>> Sent: Wednesday, November 11, 2009 9:35 PM
>> To: Matthieu Patou
>> Cc: cifs-protocol@...; pfif@...; 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.Samba@...]
>> Sent: Wednesday, November 11, 2009 12:22 AM
>> To: Hongwei Sun
>> Cc: cifs-protocol@...; pfif@...
>> 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@...), 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@...; pfif@...
>>> 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.Samba@...]
>>> Sent: Sunday, October 25, 2009 5:48 AM
>>> To: cifs-protocol@...; Hongwei Sun; Interoperability
>>> Documentation Help; pfif@...
>>> 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:mat+Informatique.Samba@...]
>>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>>> To: Hongwei Sun
>>>>> Cc: pfif@...; cifs-protocol@...
>>>>> 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
>>>> cifs-protocol@...
>>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>>
>>>>
>>>>          
>>>        
>>
>>      
>
>    

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Sebastian Canevari]

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: [phone]
e-mail: sebastc@...

-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
Sent: Friday, December 04, 2009 3:32 PM
To: Sebastian Canevari
Cc: Hongwei Sun; cifs-protocol@...; pfif@...
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: [phone]
> e-mail: sebastc@...
>
>
> -----Original Message-----
> From: Sebastian Canevari
> Sent: Thursday, December 03, 2009 4:18 PM
> To: 'Matthieu Patou'; cifs-protocol@...; Interoperability
> Documentation Help; pfif@...
> 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: [phone]
> e-mail: sebastc@...
>
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
> Sent: Thursday, December 03, 2009 4:05 PM
> To: Sebastian Canevari; cifs-protocol@...; Interoperability
> Documentation Help; pfif@...
> 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: [phone]
>> e-mail: sebastc@...
>>
>>
>> -----Original Message-----
>> From: Hongwei Sun
>> Sent: Wednesday, November 11, 2009 9:35 PM
>> To: Matthieu Patou
>> Cc: cifs-protocol@...; pfif@...; 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.Samba@...]
>> Sent: Wednesday, November 11, 2009 12:22 AM
>> To: Hongwei Sun
>> Cc: cifs-protocol@...; pfif@...
>> 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@...), 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@...; pfif@...
>>> 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.Samba@...]
>>> Sent: Sunday, October 25, 2009 5:48 AM
>>> To: cifs-protocol@...; Hongwei Sun; Interoperability
>>> Documentation Help; pfif@...
>>> 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.Samba@...]
>>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>>> To: Hongwei Sun
>>>>> Cc: pfif@...; cifs-protocol@...
>>>>> 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@...
>>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol