Samba 4 insufficientAccessRights when modifying Configuration
Brian C. Huffman
bhuffman at etinternational.com
Thu Aug 9 14:32:42 MDT 2012
Nadya,
Should I open a bug on this? I've definitely added the machine account
to the Domain Admins group.
If not, is there anything else I can do to test what might be wrong?
Thanks,
Brian
On 08/01/2012 03:13 PM, Nadezhda Ivanova wrote:
> From the security token it is seen that the user is not a member of
> Domain admins or enterprise admins. All we have is:
> sids :
> S-1-5-21-2824053618-3522172672-2706769870-1104 - I assume this is the
> machine account sid
> sids :
> S-1-5-21-2824053618-3522172672-2706769870-515 - Domain Computers
> sids : S-1-1-0 - Everyone
> sids : S-1-5-2 - Network
> sids : S-1-5-11 - Authenticated Users
>
> For some reason the account has not become a member of Domain Admins.
>
>
>
> On Wed, Aug 1, 2012 at 9:56 PM, Brian C. Huffman
> <bhuffman at etinternational.com <mailto:bhuffman at etinternational.com>>
> wrote:
>
> Here you go:
> [2012/08/01 14:35:39, 10, pid=15547, effective(0, 0), real(0, 0)]
> ../source4/dsdb/common/dsdb_access.c:47(dsdb_acl_debug)
> Access on
> CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti
> deniedSecurity context: : struct security_token
> num_sids : 0x00000005 (5)
> sids: ARRAY(5)
> sids :
> S-1-5-21-2824053618-3522172672-2706769870-1104
> sids :
> S-1-5-21-2824053618-3522172672-2706769870-515
> sids : S-1-1-0
> sids : S-1-5-2
> sids : S-1-5-11
> privilege_mask : 0x0000000000000000 (0)
> 0: SEC_PRIV_MACHINE_ACCOUNT_BIT
> 0: SEC_PRIV_PRINT_OPERATOR_BIT
> 0: SEC_PRIV_ADD_USERS_BIT
> 0: SEC_PRIV_DISK_OPERATOR_BIT
> 0: SEC_PRIV_REMOTE_SHUTDOWN_BIT
> 0: SEC_PRIV_BACKUP_BIT
> 0: SEC_PRIV_RESTORE_BIT
> 0: SEC_PRIV_TAKE_OWNERSHIP_BIT
> 0: SEC_PRIV_INCREASE_QUOTA_BIT
> 0: SEC_PRIV_SECURITY_BIT
> 0: SEC_PRIV_LOAD_DRIVER_BIT
> 0: SEC_PRIV_SYSTEM_PROFILE_BIT
> 0: SEC_PRIV_SYSTEMTIME_BIT
> 0: SEC_PRIV_PROFILE_SINGLE_PROCESS_BIT
> 0: SEC_PRIV_INCREASE_BASE_PRIORITY_BIT
> 0: SEC_PRIV_CREATE_PAGEFILE_BIT
> 0: SEC_PRIV_SHUTDOWN_BIT
> 0: SEC_PRIV_DEBUG_BIT
> 0: SEC_PRIV_SYSTEM_ENVIRONMENT_BIT
> 0: SEC_PRIV_CHANGE_NOTIFY_BIT
> 0: SEC_PRIV_UNDOCK_BIT
> 0: SEC_PRIV_ENABLE_DELEGATION_BIT
> 0: SEC_PRIV_MANAGE_VOLUME_BIT
> 0: SEC_PRIV_IMPERSONATE_BIT
> 0: SEC_PRIV_CREATE_GLOBAL_BIT
> rights_mask : 0x00000000 (0)
> 0: LSA_POLICY_MODE_INTERACTIVE
> 0: LSA_POLICY_MODE_NETWORK
> 0: LSA_POLICY_MODE_BATCH
> 0: LSA_POLICY_MODE_SERVICE
> 0: LSA_POLICY_MODE_PROXY
> 0: LSA_POLICY_MODE_DENY_INTERACTIVE
> 0: LSA_POLICY_MODE_DENY_NETWORK
> 0: LSA_POLICY_MODE_DENY_BATCH
> 0: LSA_POLICY_MODE_DENY_SERVICE
> 0: LSA_POLICY_MODE_REMOTE_INTERACTIVE
> 0: LSA_POLICY_MODE_DENY_REMOTE_INTERACTIVE
> 0x00: LSA_POLICY_MODE_ALL (0)
> 0x00: LSA_POLICY_MODE_ALL_NT4 (0)
>
> [2012/08/01 14:35:39, 10, pid=15547, effective(0, 0), real(0, 0)]
> ../source4/dsdb/common/dsdb_access.c:55(dsdb_acl_debug)
>
> Security descriptor: : struct security_descriptor
> revision :
> SECURITY_DESCRIPTOR_REVISION_1 (1)
> type : 0x8405 (33797)
>
> 1: SEC_DESC_OWNER_DEFAULTED
> 0: SEC_DESC_GROUP_DEFAULTED
> 1: SEC_DESC_DACL_PRESENT
> 0: SEC_DESC_DACL_DEFAULTED
> 0: 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
> 0: 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
> owner_sid : *
> owner_sid :
> S-1-5-21-2824053618-3522172672-2706769870-519
> group_sid : *
> group_sid :
> S-1-5-21-2824053618-3522172672-2706769870-513
> sacl : NULL
> dacl : *
> dacl: struct security_acl
> revision :
> SECURITY_ACL_REVISION_ADS (4)
> size : 0x009c (156)
> num_aces : 0x00000005 (5)
> aces: ARRAY(5)
> aces: struct security_ace
> type :
> SEC_ACE_TYPE_ACCESS_ALLOWED (0)
> flags : 0x00 (0)
> 0: SEC_ACE_FLAG_OBJECT_INHERIT
> 0: SEC_ACE_FLAG_CONTAINER_INHERIT
> 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
> 0: SEC_ACE_FLAG_INHERIT_ONLY
> 0: SEC_ACE_FLAG_INHERITED_ACE
> 0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
> 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
> 0: SEC_ACE_FLAG_FAILED_ACCESS
> size : 0x0024 (36)
> access_mask : 0x000f01ff
> (983551)
> object : union
> security_ace_object_ctr(case 0)
> trustee :
> S-1-5-21-2824053618-3522172672-2706769870-512
> aces: struct security_ace
> type :
> SEC_ACE_TYPE_ACCESS_ALLOWED (0)
> flags : 0x00 (0)
> 0: SEC_ACE_FLAG_OBJECT_INHERIT
> 0: SEC_ACE_FLAG_CONTAINER_INHERIT
> 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
> 0: SEC_ACE_FLAG_INHERIT_ONLY
> 0: SEC_ACE_FLAG_INHERITED_ACE
> 0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
> 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
> 0: SEC_ACE_FLAG_FAILED_ACCESS
> size : 0x0014 (20)
> access_mask : 0x000f01ff
> (983551)
> object : union
> security_ace_object_ctr(case 0)
> trustee : S-1-5-18
> aces: struct security_ace
> type :
> SEC_ACE_TYPE_ACCESS_ALLOWED (0)
> flags : 0x00 (0)
> 0: SEC_ACE_FLAG_OBJECT_INHERIT
> 0: SEC_ACE_FLAG_CONTAINER_INHERIT
> 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
> 0: SEC_ACE_FLAG_INHERIT_ONLY
> 0: SEC_ACE_FLAG_INHERITED_ACE
> 0x00: SEC_ACE_FLAG_VALID_INHERIT (0)
> 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
> 0: SEC_ACE_FLAG_FAILED_ACCESS
> size : 0x0014 (20)
> access_mask : 0x00020094
> (131220)
> object : union
> security_ace_object_ctr(case 0)
> trustee : S-1-5-11
> aces: struct security_ace
> type :
> SEC_ACE_TYPE_ACCESS_ALLOWED (0)
> flags : 0x12 (18)
> 0: SEC_ACE_FLAG_OBJECT_INHERIT
> 1: SEC_ACE_FLAG_CONTAINER_INHERIT
> 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
> 0: SEC_ACE_FLAG_INHERIT_ONLY
> 1: SEC_ACE_FLAG_INHERITED_ACE
> 0x02: SEC_ACE_FLAG_VALID_INHERIT (2)
> 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
> 0: SEC_ACE_FLAG_FAILED_ACCESS
> size : 0x0024 (36)
> access_mask : 0x000f01ff
> (983551)
> object : union
> security_ace_object_ctr(case 0)
> trustee :
> S-1-5-21-2824053618-3522172672-2706769870-519
> aces: struct security_ace
> type :
> SEC_ACE_TYPE_ACCESS_ALLOWED (0)
> flags : 0x12 (18)
> 0: SEC_ACE_FLAG_OBJECT_INHERIT
> 1: SEC_ACE_FLAG_CONTAINER_INHERIT
> 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
> 0: SEC_ACE_FLAG_INHERIT_ONLY
> 1: SEC_ACE_FLAG_INHERITED_ACE
> 0x02: SEC_ACE_FLAG_VALID_INHERIT (2)
> 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
> 0: SEC_ACE_FLAG_FAILED_ACCESS
> size : 0x0024 (36)
> access_mask : 0x000f01bd
> (983485)
> object : union
> security_ace_object_ctr(case 0)
> trustee :
> S-1-5-21-2824053618-3522172672-2706769870-512
>
> [2012/08/01 14:35:39, 5, pid=15547, effective(0, 0), real(0, 0)]
> ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug)
> ldb: cancel ldb transaction (nesting: 0)
>
> Let me know if you need anything additional.
>
> Thanks!
> Brian
>
>
> On 08/01/2012 02:02 PM, Nadezhda Ivanova wrote:
>> 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
>> <mailto: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
>>> <mailto: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.
>>>
>>>
>>>
>>>
>>
>>
>
>
More information about the samba-technical
mailing list