Matthieu,
Your summary is a good recap of what we have done on this topic. I have
one clarification for the point below.
* All ACE for allowed object are wipped out when "translating" AD ACL
to File ACL
When translating a ACL for DS object to a ACL for SYSVOL file object,
the ACEs with types of ACCESS_ALLOWED_OBJECT_ACE_TYPE,
ACCESS_DENIED_OBJECT_ACE_TYPE and SYSTEM_AUDIT_OBJECT_ACE_TYPE are not really
deleted from the ACL. Instead, for such a ACE, access mask in AceHeader is
assigned to zero.
Sebastian will follow up with you on your question regarding documenting the
logic for ACE OI and CI flags.
Thanks!
Hongwei
-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Friday, December 18, 2009 4:01 PM
To: Sebastian Canevari
Cc: Hongwei Sun; Interoperability Documentation Help; [email protected]
Subject: Re: FW: [cifs-protocol] Group Policy questions
Hello Sebastian and Hongwei,
Sorry for being silent on this.
So if I try to sum up we agreed that:
* in order to allow modification of ACL on files sdeffectiverights must
have the flag DACL_SECURITY_INFORMATION set, and the ACL must have the
SE_DACL_PROTECTED set in the control flags.
* in order to avoid a warning message ACL of Policy object must be
synchronized with ACL in the files following this logic for the translation:
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 = DSAccessMask;
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;
* All ACE for allowed object are wipped out when "translating" AD ACL to
File ACL
* For the following ACE OI and CI flags are always set in the resulting
file ACE:
ACCESS_ALLOWED_ACE_TYPE
ACCESS_DENIED_ACE_TYPE
SYSTEM_AUDIT_ACE_TYPE
Am I right ?
For the part that are "hardcoded" like this will it change any time soon
? Also do you plan to document this in any kind of document ? if so
which and when ?
Regards.
Matthieu.
On 12/12/2009 01:00, Sebastian Canevari wrote:
> Hi Matthieu,
>
> With regards to ACCESS_ALLOWED_OBJECT_ACE, we do wipe it in the process.
> That's hardcoded.
>
> With regards to the RU...
>
> I need further clarification on what you are actually seeing.
>
> It is my understanding and that since prew2k clients will not download
> policies, the ACEs will be cleared if they contain that well known SID.
>
> We are still investigating but please let me know if that explains what you
> are seeing.
>
>
> Thanks!
>
>
> Sebastian Canevari
> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 7100 N Hwy 161, Irving, TX - 75039
> "Las Colinas - LC2"
> Tel: +1 469 775 7849
> e-mail: [email protected]
>
>
> -----Original Message-----
> From: Sebastian Canevari
> Sent: Thursday, December 10, 2009 2:19 PM
> To: 'Matthieu Patou'
> Cc: Hongwei Sun; [email protected]; [email protected]
> Subject: RE: FW: [cifs-protocol] Group Policy questions
>
> Hi Matthieu,
>
> With regards of the OI and CI flags, we always set those flags on if the ACE
> type is any of the following 3 types:
>
> ACCESS_ALLOWED_ACE_TYPE
> ACCESS_DENIED_ACE_TYPE
> SYSTEM_AUDIT_ACE_TYPE
>
> This is hardcoded.
>
> I'll provide you with the answer to your other question soon.
>
> Thanks and regards,
>
> Sebastian
>
>
> Sebastian Canevari
> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161,
> Irving, TX - 75039 "Las Colinas - LC2"
> Tel: +1 469 775 7849
> e-mail: [email protected]
>
> -----Original Message-----
> From: Matthieu Patou [mailto:[email protected]]
> Sent: Friday, December 04, 2009 3:32 PM
> To: Sebastian Canevari
> Cc: Hongwei Sun; [email protected]; [email protected]
> Subject: Re: FW: [cifs-protocol] Group Policy questions
>
> On 04/12/2009 23:00, Sebastian Canevari wrote:
>
>> Hi Matthieu,
>>
>> Just a clarification to ask you for:
>>
>> We are discussing with Hongwei and the PGs if it is that you are seeing
>> GPMC "expect" the inheritance to happen OR if it is that you are dumping the
>> ACLs and "seeing" the flags always.
>>
>>
>>
> What I see if when I dump the SD of the files modified by GPMC after it
> realize that there was a mismatch between the SD in AD and the SD in the
> Policy folder.
> Note: it was with XP sp2 as a client.
>
> Matthieu.
>
>> Please clarify because we were under the impression that we had to look into
>> the client tool, but if the latter is what your question means, then we need
>> to look into AD.
>>
>> Thanks and regards,
>>
>>
>>
>> Sebastian Canevari
>> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N
>> Hwy 161, Irving, TX - 75039 "Las Colinas - LC2"
>> Tel: +1 469 775 7849
>> e-mail: [email protected]
>>
>>
>> -----Original Message-----
>> From: Sebastian Canevari
>> Sent: Thursday, December 03, 2009 4:18 PM
>> To: 'Matthieu Patou'; [email protected]; Interoperability
>> Documentation Help; [email protected]
>> Subject: RE: FW: [cifs-protocol] Group Policy questions
>>
>> Hi Matthieu,
>>
>> We are still actively working on this and I do have the PG engaged.
>>
>> Please accept my apologies if we are delaying a little longer than expected.
>> I guess we can say that the holidays affected the timing a little without
>> trying to use that as an excuse.
>>
>> I'll keep you posted as soon as I have news.
>>
>> Thanks and regards,
>>
>> Sebastian
>>
>>
>> Sebastian Canevari
>> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161,
>> Irving, TX - 75039 "Las Colinas - LC2"
>> Tel: +1 469 775 7849
>> e-mail: [email protected]
>>
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:[email protected]]
>> Sent: Thursday, December 03, 2009 4:05 PM
>> To: Sebastian Canevari; [email protected]; Interoperability
>> Documentation Help; [email protected]
>> Subject: Re: FW: [cifs-protocol] Group Policy questions
>>
>> Hello sebastian
>>
>>
>>
>>> And last but not least question, it seems that GPMC whats to have OI and CI
>>> flags on every ACL entries is it due to the presence of the
>>> "SDDL_AUTO_INHERITED">control in the SDDL ?
>>>
>>>
>> Any news on this ?
>> More exactly my question is why this flag appear on each ACE ?
>>
>> Also do you plan to document this in a WSPP document ?
>>
>> Regards.
>> Matthieu.
>> On 13/11/2009 02:40, Sebastian Canevari wrote:
>>
>>
>>> Hi Matthieu,
>>>
>>>
>>> I'll be working with you on these questions.
>>>
>>> I will keep you updated.
>>>
>>> Thanks!
>>>
>>> Sebastian
>>>
>>>
>>>
>>> Sebastian Canevari
>>> Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N
>>> Hwy 161, Irving, TX - 75039 "Las Colinas - LC2"
>>> Tel: +1 469 775 7849
>>> e-mail: [email protected]
>>>
>>>
>>> -----Original Message-----
>>> From: Hongwei Sun
>>> Sent: Wednesday, November 11, 2009 9:35 PM
>>> To: Matthieu Patou
>>> Cc: [email protected]; [email protected]; Sebastian Canevari
>>> Subject: RE: FW: [cifs-protocol] Group Policy questions
>>>
>>> Matthieu,
>>>
>>> I double checked the logic and your assumption is right. The return
>>> value for SYSVOL access mask should be assigned to the input value first.
>>> For your other questions, since I am out of office , Sebastian will work
>>> on them and let you know.
>>>
>>> Thanks!
>>>
>>> Hongwei
>>>
>>> -----Original Message-----
>>> From: Matthieu Patou [mailto:[email protected]]
>>> Sent: Wednesday, November 11, 2009 12:22 AM
>>> To: Hongwei Sun
>>> Cc: [email protected]; [email protected]
>>> Subject: Re: FW: [cifs-protocol] Group Policy questions
>>>
>>> Hello Hongwei,
>>>
>>> I've been working on the translation function, I am getting quite similar
>>> ACL right now but I have some remarks and questions.
>>>
>>> The pseudo code contains this:
>>>
>>> DSAccessMask as Input;
>>> SYSVOLAccessMask as Output;
>>>
>>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>>
>>> I have impression that it should be
>>>
>>> DSAccessMask as Input;
>>> SYSVOLAccessMask as Output;
>>>
>>> SYSVOLAccessMask = DSAccessMask;
>>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>>
>>>
>>> Maybe the third line is implied in this kind of pseudo code.
>>>
>>> Also it seems to me that GPMC is discarding any ACL of type
>>> ACCESS_ALLOWED_OBJECT_ACE (OA) and also everything related to SID
>>> SID_BUILTIN_PREW2K (RU).
>>>
>>> And last but not least question, it seems that GPMC whats to have OI and CI
>>> flags on every ACL entries is it due to the presence of the
>>> "SDDL_AUTO_INHERITED" control in the SDDL ?
>>>
>>> Thanks for your answers.
>>>
>>> Matthieu.
>>>
>>> On 29/10/2009 05:31, Hongwei Sun wrote:
>>>
>>>
>>>
>>>> Matthieu,
>>>>
>>>> I keep receiving the message from our e-mail server about the
>>>> undeliverable e-mail to one of the address([email protected]), which
>>>> is in your original e-mail. In order to make sure you receive the email,
>>>> I just forward it again.
>>>>
>>>> If you already received it, please let me know if it resolved your
>>>> issue.
>>>>
>>>> Thanks!
>>>>
>>>> Hongwei
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Hongwei Sun
>>>> Sent: Monday, October 26, 2009 6:14 PM
>>>> To: Matthieu Patou; [email protected]; [email protected]
>>>> Subject: RE: [cifs-protocol] Group Policy questions
>>>>
>>>> Matthieu,
>>>>
>>>> Matthieu,
>>>>
>>>> The attached GPMC log shows the problem of inconsistency
>>>> between ACLs of the policy object and that of SYSVOL folders. The
>>>> log shows that
>>>>
>>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>>>> CGPMGPO::IsAclConsistent():Checking Aces for SID
>>>> S-1-5-21-2212615479-2695158682-2101375467-512
>>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>>>> GetSysvolPermissionsFromDSPermissions: DS access mask is 0xf00ff ......
>>>> [6bc.678] 10/25/2009 00:55:47:359 [VERBOSE]
>>>> CGPMGPO::IsAclConsistent(): ACLs not consistent for
>>>> SID<S-1-5-21-2212615479-2695158682-2101375467-512>. Mask: Expected
>>>> 0x1f01ff, Found 0xf00ff
>>>>
>>>> The access mask for the ace of Active Directory policy object is
>>>> 0xf00ff. When the GPMO converts the access mask to a corresponding file
>>>> system access mask, it expects 0x1f01ff. For SYSVOL, you set the access
>>>> mask to 0xf00ff. They don't match and that is why inconsistency is
>>>> declared. In the SYSVOL access mask you set, you missed
>>>> 0x100000(SYNCHRONIZE) and 0x100(FILE_WRITE_ATTRIBUTES).
>>>>
>>>> Since AD objects and SYSVOL file/folder objects are different
>>>> objects, their specific rights in access mask are not one-to-one
>>>> matched. The following are the definitions of bits for both objects.
>>>>
>>>> The specific rights in access mask for Active Directory object are
>>>> defined in 5.1.3.2 of MS-ADTS as follows.
>>>>
>>>> #define RIGHT_DS_CREATE_CHILD 0x00000001
>>>> #define RIGHT_DS_DELETE_CHILD 0x00000002
>>>> #define RIGHT_DS_LIST_CONTENTS 0x00000004
>>>> #define ACTRL_DS_SELF 0x00000008
>>>> #define RIGHT_DS_READ_PROPERTY 0x00000010
>>>> #define RIGHT_DS_WRITE_PROPERTY 0x00000020
>>>> #define RIGHT_DS_DELETE_TREE 0x00000040
>>>> #define RIGHT_DS_LIST_OBJECT 0x00000080
>>>> #define RIGHT_DS_CONTROL_ACCESS 0x00000100
>>>>
>>>> The specific rights in access mask for a file or directory
>>>> object are defined as
>>>> (http://msdn.microsoft.com/en-us/library/aa364399(VS.85).aspx )
>>>>
>>>> #define FILE_READ_DATA ( 0x0001 )
>>>> #define FILE_LIST_DIRECTORY ( 0x0001 )
>>>> #define FILE_WRITE_DATA ( 0x0002 )
>>>> #define FILE_ADD_FILE ( 0x0002 )
>>>> #define FILE_APPEND_DATA ( 0x0004 )
>>>> #define FILE_ADD_SUBDIRECTORY ( 0x0004 )
>>>> #define FILE_CREATE_PIPE_INSTANCE ( 0x0004 )
>>>> #define FILE_READ_EA ( 0x0008 )
>>>> #define FILE_WRITE_EA ( 0x0010 )
>>>> #define FILE_EXECUTE ( 0x0020 )
>>>> #define FILE_TRAVERSE ( 0x0020 )
>>>> #define FILE_DELETE_CHILD ( 0x0040 )
>>>> #define FILE_READ_ATTRIBUTES ( 0x0080 )
>>>> #define FILE_WRITE_ATTRIBUTES ( 0x0100 )
>>>>
>>>> The generic access rights that are common to all objects are
>>>>
>>>> #define DELETE (0x00010000L)
>>>> #define READ_CONTROL (0x00020000L)
>>>> #define WRITE_DAC (0x00040000L)
>>>> #define WRITE_OWNER (0x00080000L)
>>>> #define SYNCHRONIZE (0x00100000L)
>>>> #define STANDARD_RIGHTS_ALL (0x001F0000L)
>>>>
>>>>
>>>> The following logic is used by GPMC to convert a access mask for DS
>>>> object to a access mask for SYSVOL.
>>>>
>>>> DSAccessMask as Input;
>>>> SYSVOLAccessMask as Output;
>>>>
>>>> SYSVOLAccessMask&= STANDARD_RIGHTS_ALL ;
>>>>
>>>> if ((DSAccessMask& RIGHT_DS_READ_PROPERTY) AND
>>>> (DSAccessMask& RIGHT_DS_LIST_CONTENTS))
>>>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_LIST_DIRECTORY |
>>>> FILE_READ_ATTRIBUTES | FILE_READ_EA |
>>>> FILE_READ_DATA | FILE_EXECUTE);
>>>>
>>>> if (DSAccessMask& RIGHT_DS_WRITE_PROPERTY)
>>>> SYSVOLAccessMask |= (SYNCHRONIZE | FILE_WRITE_DATA |
>>>> FILE_APPEND_DATA | FILE_WRITE_EA |
>>>> FILE_WRITE_ATTRIBUTES | FILE_ADD_FILE |
>>>> FILE_ADD_SUBDIRECTORY);
>>>>
>>>>
>>>> if (DSAccessMask& RIGHT_DS_CREATE_CHILD)
>>>> SYSVOLAccessMask |= (FILE_ADD_SUBDIRECTORY |
>>>> FILE_ADD_FILE);
>>>>
>>>>
>>>> if (DSAccessMask& RIGHT_DS_DELETE_CHILD)
>>>> SYSVOLAccessMask |= FILE_DELETE_CHILD;
>>>>
>>>>
>>>> Please let me know if this solves your problem. I will file a
>>>> request to update the document accordingly.
>>>>
>>>> Thanks!
>>>>
>>>> Hongwei
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Matthieu Patou [mailto:[email protected]]
>>>> Sent: Sunday, October 25, 2009 5:48 AM
>>>> To: [email protected]; Hongwei Sun; Interoperability
>>>> Documentation Help; [email protected]
>>>> Subject: Re: [cifs-protocol] Group Policy questions
>>>>
>>>> Hello hongwei,
>>>>
>>>> On 10/20/2009 01:05 PM, Matthieu Patou wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Hongwei,
>>>>> For the moment it's quite clear why we fail as we do not set any
>>>>> ACL by default on the sysvol volume.
>>>>> I will already fix this + the sDRightsEffective attribute and I'll
>>>>> see if it do the job.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I worked a little bit on the ACL and still face "unsynchronized" ACL
>>>> despite the fact that now our Policy folder are created with the same ACL
>>>> as in AD.
>>>>
>>>> Let's take the following
>>>> policy:{7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>>>>
>>>> I face the message that the ACL is unconsitent with the one stored
>>>> in the AD, after clicking on yes GPMC changed the ACL for
>>>>
>>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479
>>>> -
>>>> 2
>>>> 695158682-2101375467-512D:PAI(A;OICI;0x001f01ff;;;S-1-5-21-221261547
>>>> 9
>>>> -
>>>> 2695158682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2
>>>> 6
>>>> 9
>>>> 5158682-2101375467-519)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695
>>>> 1
>>>> 5
>>>> 8682-2101375467-512)(A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158
>>>> 6
>>>> 8
>>>> 2-2101375467-512)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;SY)(
>>>> A
>>>> ;
>>>> OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)(A;OICI;0x001f01bf;;;BA
>>>> )
>>>> (
>>>> A;OICI;0x001f01ff;;;S-1-5-21-2212615479-2695158682-2101375467-519)S:
>>>> A
>>>> I
>>>> (OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d
>>>> 0
>>>> -
>>>> a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f8036
>>>> 7
>>>> c
>>>> 1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>>>
>>>> Before it was:
>>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479
>>>> -
>>>> 2
>>>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21
>>>> -
>>>> 2
>>>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S
>>>> -
>>>> 1
>>>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDD
>>>> T
>>>> S
>>>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORC
>>>> W
>>>> O
>>>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPW
>>>> P
>>>> C
>>>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCL
>>>> O
>>>> R
>>>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC
>>>> ;
>>>> ;
>>>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWD
>>>> S
>>>> D
>>>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU
>>>> )
>>>> S
>>>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-
>>>> 1
>>>> 1
>>>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f8
>>>> 0
>>>> 3
>>>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>>>
>>>>
>>>> And if I request the nTSecurityDescriptor for this object in the AD I get:
>>>> {7557D70F-14C9-4EA5-8369-10AE7C2C31D3}
>>>> O:S-1-5-21-2212615479-2695158682-2101375467-512G:S-1-5-21-2212615479
>>>> -
>>>> 2
>>>> 695158682-2101375467-512D:PAI(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21
>>>> -
>>>> 2
>>>> 212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S
>>>> -
>>>> 1
>>>> -5-21-2212615479-2695158682-2101375467-519)(A;;RPWPCCDCLCLORCWOWDSDD
>>>> T
>>>> S
>>>> W;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;;RPWPCCDCLCLORC
>>>> W
>>>> O
>>>> WDSDDTSW;;;S-1-5-21-2212615479-2695158682-2101375467-512)(A;CIIO;RPW
>>>> P
>>>> C
>>>> CDCLCLORCWOWDSDDTSW;;;CO)(A;;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCL
>>>> O
>>>> R
>>>> C;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;;RPLCLORC
>>>> ;
>>>> ;
>>>> ;ED)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;;BA)(A;CIID;RPWPCRCCDCLCLORCWOWD
>>>> S
>>>> D
>>>> DTSW;;;S-1-5-21-2212615479-2695158682-2101375467-519)(A;CIID;LC;;;RU
>>>> )
>>>> S
>>>> :AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-
>>>> 1
>>>> 1
>>>> d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f8
>>>> 0
>>>> 3
>>>> 67c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>>>>
>>>>
>>>> Which looks like the ACL that were present for the file.
>>>> I also made a tcpdump capture (attached to this mail) and it's clear that
>>>> the nTSecurityDescriptor is like the one just above. (packet 927).
>>>>
>>>> So what's going on, with an ACL that is the same when stored in the AD,
>>>> transmitted through LDAP and stored in the file we have at the end GPMC
>>>> that change the value but it's hard to understand how it construct this
>>>> ACL.
>>>>
>>>> I attached also the GPMC log when I clicked on "OK" so that the ACL in AD
>>>> and ACL for the file are synchronized (well from GPMC point of view).
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I will try to use also the same SSDL as in w2k3 to see if I have
>>>>> the same resulting delagation or not.
>>>>>
>>>>> For the moment I have some tests to do before going back to you.
>>>>>
>>>>> Regards.
>>>>> Matthieu.
>>>>> On 10/20/2009 03:11 AM, Hongwei Sun wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Matthieu,
>>>>>>
>>>>>> For Problem #1, only the SE_DACL_PROTECTED(0x1000) has to be set
>>>>>> for ControlFlag in Security Descriptor in order to pass the step 2
>>>>>> in consistency testing. This is translated to "P" flag in SDDL.
>>>>>> With this said, it is normal to have D:PAI since this will
>>>>>> indicate that the SE_DACL_PROTECTED bit is set. It seems that your
>>>>>> Security Descriptor is right in this regard. We have to get more
>>>>>> information to see why the consistency checking fails. Could you
>>>>>> enable GPMC logging as described in my previous mail? Please
>>>>>> enable VERBOSE for Gpmgmttracelevel.
>>>>>>
>>>>>> Just for your reference, you can also use ldp.exe to display the
>>>>>> security descriptor of a policy object in SSDL string format and
>>>>>> parsed display format.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Hongwei
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Matthieu Patou [mailto:[email protected]]
>>>>>> Sent: Saturday, October 17, 2009 11:33 AM
>>>>>> To: Hongwei Sun
>>>>>> Cc: [email protected]; [email protected]
>>>>>> Subject: Re: Group Policy questions
>>>>>>
>>>>>> Hello Hongwei,Matthieu,
>>>>>> Thank you for the answers. I have a few more questions:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> After testing, I think that I have some information to help you
>>>>>>> resolve all the problems.
>>>>>>>
>>>>>>> Problem #1:
>>>>>>>
>>>>>>> As described in the following link
>>>>>>> (http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 )
>>>>>>> , GPMO will check the consistency between ACLs in GPO in Active
>>>>>>> Directory and ACLs of policy folders in SYSVOL when a GPO object
>>>>>>> is clicked in GPMC. The logic is something like the following:
>>>>>>>
>>>>>>> 1. Get the security descriptor (SD) for GOP in AD and folders in
>>>>>>> SYSVOL
>>>>>>>
>>>>>>> 2. Check both security descriptors to make sure they are DACL
>>>>>>> protected (PD bit in Control flag is set). If not, ACL
>>>>>>> consistency check will fail.
>>>>>>>
>>>>>>> 3. For every permission in AD DACL, there should be the same
>>>>>>> permission in SYSVOL DACL. If all permissions have be checked
>>>>>>> through in AD ACL and there is still extra permission in SYSVOL
>>>>>>> ACL, ACLs are not consistent.
>>>>>>>
>>>>>>> Looking at the your attached SSDL of the new policy, it doesn't
>>>>>>> have PD bit set. (D:PAI means DI bit is set, which is not DACL
>>>>>>> protected).
>>>>>>> This will fail the second step of consistency checking.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I did an extraction of a W2K3 policy and got the following SDDL:
>>>>>>
>>>>>> O:S-1-5-21-3208502064-746857408-2662927446-512G:S-1-5-21-320850206
>>>>>> 4
>>>>>> -
>>>>>> 746857408-2662927446-512
>>>>>>
>>>>>> D:PAI
>>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-266
>>>>>> 2
>>>>>> 9
>>>>>> 27446-512)
>>>>>>
>>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-266
>>>>>> 2
>>>>>> 9
>>>>>> 27446-519)
>>>>>>
>>>>>> (A;;RPWPCCDCLCLORCWOWDSDDTSW;;;S-1-5-21-3208502064-746857408-26629
>>>>>> 2
>>>>>> 7
>>>>>> 446-512)
>>>>>>
>>>>>> (A;CIIO;RPWPCCDCLCLORCWOWDSDDTSW;;;CO)
>>>>>> (A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)
>>>>>> (A;CI;RPLCLORC;;;AU)
>>>>>> (OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)
>>>>>> (A;CI;RPLCLORC;;;ED)
>>>>>> S:AI
>>>>>> (OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6
>>>>>> -
>>>>>> 1
>>>>>> 1d0-a285-00aa003049e2;WD)
>>>>>>
>>>>>> (OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6
>>>>>> -
>>>>>> 1
>>>>>> 1d0-a285-00aa003049e2;WD)
>>>>>>
>>>>>> (OU;CIIDSA;WPWD;;f30e3bc2-9ff0-11d1-b603-0000f80367c1;WD)
>>>>>>
>>>>>> And you say that we should not have AI flag (because it's related
>>>>>> to SE_DACL_AUTO_INHERITED aka DI bit) just the P flag (because
>>>>>> it's related to DE_DACL_PROTECTED aka PD bit) right ?
>>>>>> But the above SDDL seems to show the opposite, I can't exclude the
>>>>>> fact that we have bugs when reading ACL and/or when converting
>>>>>> them into SDDL but before to trying to check this I would like to
>>>>>> be sure of which flag we should see.
>>>>>>
>>>>>> I even tweaked XCACLS.vbs (attached to this email) from
>>>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;828760 to
>>>>>> make it show the value of the control and it appear that the ACL
>>>>>> for the c:\windows\sysvol has both PD and DI bit sets
>>>>>>
>>>>>> ie.
>>>>>> Directory: C:\WINDOWS\SYSVOL
>>>>>>
>>>>>> ControlFlags: 37892
>>>>>>
>>>>>> Do gpmc pass some controls while making its LDAP request because I
>>>>>> had a look at the delegated permission through GPMC and through
>>>>>> dsa.msc they are really different (a lot of inherited from parents
>>>>>> objects).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Problem #2:
>>>>>>>
>>>>>>> In GPMO, if the attribute sDRightsEffective of selected GPO
>>>>>>> object has DACL_SECURITY_INFORMATION bit (0x04) set, users will
>>>>>>> be prompted for ACL correction if ACLs inconsistency between AD
>>>>>>> GPO and SYSVOL is detected when a GPO node is selected. You
>>>>>>> should check the attribute for the GOP object in AD.
>>>>>>>
>>>>>>> Problem #3:
>>>>>>>
>>>>>>> This is basically the same logic as in (2). The "Add" and "Remove"
>>>>>>> buttons in Delegation dialog are enabled only when the attribute
>>>>>>> sDRightsEffective of selected GPO object has
>>>>>>> DACL_SECURITY_INFORMATION (0x04) bit set. You should check the
>>>>>>> attribute for the GOP object in AD.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Yeah for this it seems that the obvious problem is the lack of
>>>>>> sDRightsEffective in SAMBA 4.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Debugging Information:
>>>>>>>
>>>>>>> By the way, you can follow the instruction in this link
>>>>>>> (http://technet.microsoft.com/en-us/library/cc737379(WS.10).aspx
>>>>>>> ) to enable GPMC logging, if you want to troubleshoot the issues
>>>>>>> related to operations in GPMC. For example, the logging will show
>>>>>>> you in which step the consistency checking fails.
>>>>>>> You can look for the text "CGPMGPO::IsAclConsistent()" in the
>>>>>>> logs generated.
>>>>>>>
>>>>>>> If you need more information, please let us know.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Matthieu.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> cifs-protocol mailing list
>>>>> [email protected]
>>>>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
