Samba 4 insufficientAccessRights when modifying Configuration

[Nadezhda Ivanova]

Hi Brian,
We will need to take a look at the access check dumps. To do that, you need
to run Samba with log level 10. Add the machine account to the Domain Admin
groups, and repeat the installation. The log file will be enormous, but
search for something like:
Object
CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti
has no write property access
Access on
CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti
denied

After that there should be a dump of the security token, which looks
something like this:
Security context:     : struct security_token
        user_sid                 : *
            user_sid                 :
S-1-5-21-2851635801-3495335766-3134857892-1014
        group_sid                : *
            group_sid                :
S-1-5-21-2851635801-3495335766-3134857892-513
        num_sids                 : 0x00000006 (6)
        sids: ARRAY(6)
            sids                     : *
                sids                     :
S-1-5-21-2851635801-3495335766-3134857892-1014
            sids                     : *
                sids                     :
S-1-5-21-2851635801-3495335766-3134857892-513
            sids                     : *
                sids                     : S-1-1-0
            sids                     : *
                sids                     : S-1-5-2
            sids                     : *
                sids                     : S-1-5-11
            sids                     : *
                sids                     : S-1-5-32-545
        privilege_mask           : 0x0000000000000000 (0)

and after that is a dump of the security descriptor for the object. It can
be very big, starts with something like:
Security descriptor:     : struct security_descriptor
        revision                 : SECURITY_DESCRIPTOR_REVISION_1 (1)
        type                     : 0x8c14 (35860)
               0: SEC_DESC_OWNER_DEFAULTED
               0: SEC_DESC_GROUP_DEFAULTED
               1: SEC_DESC_DACL_PRESENT
               0: SEC_DESC_DACL_DEFAULTED
               1: SEC_DESC_SACL_PRESENT
               0: SEC_DESC_SACL_DEFAULTED
               0: SEC_DESC_DACL_TRUSTED
               0: SEC_DESC_SERVER_SECURITY
               0: SEC_DESC_DACL_AUTO_INHERIT_REQ
               0: SEC_DESC_SACL_AUTO_INHERIT_REQ
               1: SEC_DESC_DACL_AUTO_INHERITED
               1: SEC_DESC_SACL_AUTO_INHERITED
               0: SEC_DESC_DACL_PROTECTED
               0: SEC_DESC_SACL_PROTECTED
               0: SEC_DESC_RM_CONTROL_VALID
               1: SEC_DESC_SELF_RELATIVE


And goes on with the list of all ACEs in sacl and dacl. We will need all
that to figure out why the access checks have failed, could you send it?

Regards,
Nadya


On Wed, Aug 1, 2012 at 5:01 PM, Brian C. Huffman <
bhuffman at etinternational.com> wrote:

>  Yep - In fact, I removed the machine account from Domain Admins, tried
> again, and did a diff between the two modify responses.  Kerberos info is
> different and the timestamps are different, but everything else is the same.
>
> Brian
>
>
> On 08/01/2012 09:51 AM, Nadezhda Ivanova wrote:
>
> Is it the same error on the same operation?
>
> On Wed, Aug 1, 2012 at 4:49 PM, Brian C. Huffman <
> bhuffman at etinternational.com> wrote:
>
>> Matthieu,
>>
>> I used the MMC "Active Directory Users and Computers" to make the change
>> you suggested.  Unfortunately I still get the insufficientAccessRights.  So
>> now I'm not sure what's going on because your idea made sense and sounded
>> very promising.
>>
>> Brian
>>
>>
>>
>>
>> On 07/31/2012 11:52 PM, Matthieu Patou wrote:
>>
>>> On 07/31/2012 07:18 AM, Brian C. Huffman wrote:
>>>
>>>> Unfortunately I can run it as Administrator but it appears that
>>>> programatically it still tries to install as the machine account.  I did
>>>> some research and it turns out that the vendor intends you to run it on the
>>>> AD server itself (which won't be possible for Samba).
>>>>
>>>>  I suspect they expect you to run it on one of the DC, in this case the
>>> computer account is member of the domain controllers that have a lot of
>>> rights !
>>>
>>>  However while trying to work around this, I found a difference between
>>>> Samba and a Windows 2008 AD server.  With the Win2k8 AD server, I'm able to
>>>> add the machine account, with inherited write permissions to
>>>> CN=DisplaySpecifiers,CN=Configuration and then the installer succeeds.
>>>>  When I try to do the same with Samba, it doesn't give me any warnings, but
>>>> it silently refuses to add the permissions to the descendants of
>>>> DisplaySpecifiers.  Is this known / intended behavior?
>>>>
>>>>  As nadya said we now this "issue" the way to do it for you is to add
>>> the machine account via ADSI or ldbedit to the domain admins group, it
>>> should do the job. Once the installation is finished, remove it from this
>>> group.
>>>
>>> Matthieu.
>>>
>>>
>>>
>>
>
>