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.sa...@matws.net]
Sent: Saturday, October 17, 2009 11:33 AM
To: Hongwei Sun
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: Group Policy questions
Hello Hongwei,Matthieu,
Thank you for the answers. I have a few more questions:
After testing, I think that I have some information to help you resolve
all the problems.
Problem #1:
As described in the following link
(http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 ) , GPMO will
check the consistency between ACLs in GPO in Active Directory and ACLs of
policy folders in SYSVOL when a GPO object is clicked in GPMC. The logic is
something like the following:
1. Get the security descriptor (SD) for GOP in AD and
folders in SYSVOL
2. Check both security descriptors to make sure they are DACL
protected (PD bit in Control flag is set). If not, ACL consistency check will
fail.
3. For every permission in AD DACL, there should be the same
permission in SYSVOL DACL. If all permissions have be checked through in AD ACL
and there is still extra permission in SYSVOL ACL, ACLs are not consistent.
Looking at the your attached SSDL of the new policy, it doesn't have
PD bit set. (D:PAI means DI bit is set, which is not DACL protected). This
will fail the second step of consistency checking.
I did an extraction of a W2K3 policy and got the following SDDL:
O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-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@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
