Group Policy questions

View: New views
6 Messages — Rating Filter:   Alert me  

Group Policy questions

by Matthieu Patou-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

We are facing some problems with group policies and I would like to have
more information on the following points.



Currently Samba is not able to set correctly acl on policy folders so
that they are "synchronized" with the acl for the policy object in the AD.
So every time a policy is selected in gpmc.msc we receive the message
indicating that the ACL are not in sync ....
1) What is the algorithm to transform the AD ACL for Group Policy Object
into the ACL for the associated files in \\realm\sysvol ? Lot of us
tried different things without success
2) If I modify the ACL of a the Policy directory on a w2k3 DC, I am
offered with the to opportunity to correct this when I select the GPO in
gpmc. On a S4 server it's not the case but I the ACL for the policy
object are the SAME in S4 and in w2k3 and I am testing with the domain
administrator (ie. default administrator with rid 500). It seems that
the it's not only the SID or the group membership that trigger the right
to adjust the ACL. What can influence one or the other behavior ?
3) In the delegation tab of the GPMC tool I am just offered the
"advanced" button other are grayed (no possiblity to add or remove a
delegation ... I click "advanced" it appear that I can't do much even if
the owner of the object is "Domain admins" and that the Administrator is
a member of it. It seems that there is also here a subtle logic. Can you
explain it ?

For your information the SDDL of the acl of a new policy is the
following one:


O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064-746857408-2662927446-513D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5
 
-21-3208502064-746857408-2662927446-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-
 
21-3208502064-746857408-2662927446-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-2
 
1-3208502064-746857408-2662927446-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-3208502064-746857408-2662927446
 
-519)(A;CIID;LC;;;RU)S:(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf9
 
67aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-00
  00f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)


Regards.

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

Re: Group Policy questions (SRX091011600003 [MS-GPSB] Group Policy AD ACL to File ACL)

by Bill Wesse :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Good morning Matthieu - thanks for your questions concerning ACLs on group policy & associated file objects. I have created the case noted below to track our work and responses against this. One of my colleagues will take ownership of the case and contact you tomorrow.

SRX091011600003 [MS-GPSB] Group Policy AD ACL to File ACL

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  +1(980) 776-8200
CELL: +1(704) 661-5438
FAX:  +1(704) 665-9606


-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
Sent: Sunday, October 11, 2009 7:28 AM
To: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: Group Policy questions

Hello,

We are facing some problems with group policies and I would like to have
more information on the following points.



Currently Samba is not able to set correctly acl on policy folders so
that they are "synchronized" with the acl for the policy object in the AD.
So every time a policy is selected in gpmc.msc we receive the message
indicating that the ACL are not in sync ....
1) What is the algorithm to transform the AD ACL for Group Policy Object
into the ACL for the associated files in \\realm\sysvol ? Lot of us
tried different things without success
2) If I modify the ACL of a the Policy directory on a w2k3 DC, I am
offered with the to opportunity to correct this when I select the GPO in
gpmc. On a S4 server it's not the case but I the ACL for the policy
object are the SAME in S4 and in w2k3 and I am testing with the domain
administrator (ie. default administrator with rid 500). It seems that
the it's not only the SID or the group membership that trigger the right
to adjust the ACL. What can influence one or the other behavior ?
3) In the delegation tab of the GPMC tool I am just offered the
"advanced" button other are grayed (no possiblity to add or remove a
delegation ... I click "advanced" it appear that I can't do much even if
the owner of the object is "Domain admins" and that the Administrator is
a member of it. It seems that there is also here a subtle logic. Can you
explain it ?

For your information the SDDL of the acl of a new policy is the
following one:


O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064-746857408-2662927446-513D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5
 
-21-3208502064-746857408-2662927446-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-
 
21-3208502064-746857408-2662927446-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-2
 
1-3208502064-746857408-2662927446-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-3208502064-746857408-2662927446
 
-519)(A;CIID;LC;;;RU)S:(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf9
 
67aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-00
  00f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)


Regards.

Matthieu Patou.

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

Re: Group Policy questions

by Hongwei Sun :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Matthieu,

  Could you share the exact error message displayed ?  A screen shot works too.

Thanks!

Hongwei

-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
Sent: Sunday, October 11, 2009 6:28 AM
To: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: Group Policy questions

Hello,

We are facing some problems with group policies and I would like to have
more information on the following points.



Currently Samba is not able to set correctly acl on policy folders so
that they are "synchronized" with the acl for the policy object in the AD.
So every time a policy is selected in gpmc.msc we receive the message
indicating that the ACL are not in sync ....
1) What is the algorithm to transform the AD ACL for Group Policy Object
into the ACL for the associated files in \\realm\sysvol ? Lot of us
tried different things without success
2) If I modify the ACL of a the Policy directory on a w2k3 DC, I am
offered with the to opportunity to correct this when I select the GPO in
gpmc. On a S4 server it's not the case but I the ACL for the policy
object are the SAME in S4 and in w2k3 and I am testing with the domain
administrator (ie. default administrator with rid 500). It seems that
the it's not only the SID or the group membership that trigger the right
to adjust the ACL. What can influence one or the other behavior ?
3) In the delegation tab of the GPMC tool I am just offered the
"advanced" button other are grayed (no possiblity to add or remove a
delegation ... I click "advanced" it appear that I can't do much even if
the owner of the object is "Domain admins" and that the Administrator is
a member of it. It seems that there is also here a subtle logic. Can you
explain it ?

For your information the SDDL of the acl of a new policy is the
following one:


O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064-746857408-2662927446-513D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5
 
-21-3208502064-746857408-2662927446-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-
 
21-3208502064-746857408-2662927446-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-2
 
1-3208502064-746857408-2662927446-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-3208502064-746857408-2662927446
 
-519)(A;CIID;LC;;;RU)S:(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf9
 
67aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-00
  00f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)


Regards.

Matthieu Patou.

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

Re: Group Policy questions

by Hongwei Sun :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Matthieu,

   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.
       
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.


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!

Hongwei



-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba@...]
Sent: Sunday, October 11, 2009 6:28 AM
To: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: Group Policy questions

Hello,

We are facing some problems with group policies and I would like to have
more information on the following points.



Currently Samba is not able to set correctly acl on policy folders so
that they are "synchronized" with the acl for the policy object in the AD.
So every time a policy is selected in gpmc.msc we receive the message
indicating that the ACL are not in sync ....
1) What is the algorithm to transform the AD ACL for Group Policy Object
into the ACL for the associated files in \\realm\sysvol ? Lot of us
tried different things without success
2) If I modify the ACL of a the Policy directory on a w2k3 DC, I am
offered with the to opportunity to correct this when I select the GPO in
gpmc. On a S4 server it's not the case but I the ACL for the policy
object are the SAME in S4 and in w2k3 and I am testing with the domain
administrator (ie. default administrator with rid 500). It seems that
the it's not only the SID or the group membership that trigger the right
to adjust the ACL. What can influence one or the other behavior ?
3) In the delegation tab of the GPMC tool I am just offered the
"advanced" button other are grayed (no possiblity to add or remove a
delegation ... I click "advanced" it appear that I can't do much even if
the owner of the object is "Domain admins" and that the Administrator is
a member of it. It seems that there is also here a subtle logic. Can you
explain it ?

For your information the SDDL of the acl of a new policy is the
following one:


O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-3208502064-746857408-2662927446-513D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5
 
-21-3208502064-746857408-2662927446-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-
 
21-3208502064-746857408-2662927446-519)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-2
 
1-3208502064-746857408-2662927446-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-3208502064-746857408-2662927446
 
-519)(A;CIID;LC;;;RU)S:(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf9
 
67aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-00
  00f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)


Regards.

Matthieu Patou.

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

Parent Message unknown Re: Group Policy questions

by Hongwei Sun :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: Group Policy questions

by Matthieu Patou-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 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