[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
Rowland penny
rpenny at samba.org
Sun Jan 10 16:32:23 UTC 2016
On 08/01/16 19:30, Partha Sarathi wrote:
> adding samba list
>
> On Fri, Jan 8, 2016 at 10:22 AM, Partha Sarathi <parthasarathi.bl at gmail.com>
> wrote:
>
>> Hi,
>>
>>
>> We have a customer who facing security issues after changing RID idmap
>> backend to AUTORID.
>>
>>
>> The History of the issue looks as below,
>>
>> 1) When samba configured with RID idmap backend customer requested to
>> change few permissions, product support changed them thru setfacl to edit
>> the POSIX ACLS directly rather than adding thru smbcacls/samba-tool ntacl.
>>
>> 2) Later samba configured with AUTORID with base range as the RID idmap
>> range.
>>
>> 3) Now when customer try to access the share they get "access denied " and
>> the get_nt_acl_internal() gives the underlying file system SD with
>> legacy_uid_sid conversion. those sid does not match the user sids.
>>
>> Attached the debug level 10 log for more information on this issue.
>>
>>
>> Note:
>>
>> The idmap range for RID:
>>
>> idmap config <DOMAIN> : range = 10000000-109999999
>>
>> The idmap range for AUTORID:
>>
>> idmap config *: backend = autorid
>>
>> idmap config *: range = 10000000-2020000000
>>
>> idmap config *: rangesize = 100000000
>>
>>
>> Since the the old UIDs are unable to get convert with autorid we see
>> failure like as below,
>>
>> Primary group is 0 and contains 0 supplementary groups
>> [2016/01/04 15:08:21.481290, 4, pid=10718, effective(0, 0), real(0, 0),
>> class=passdb] ../source3/passdb/pdb_interface.c:1383(pdb_default_uid_to_sid)
>> pdb_default_uid_to_sid: host has no idea of uid 10000512
>> [2016/01/04 15:08:21.481310, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/sec_ctx.c:424(pop_sec_ctx)
>> pop_sec_ctx (110007232, 110000513) - sec_ctx_stack_ndx = 0
>> [2016/01/04 15:08:21.481325, 10, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)]
>> ../source3/passdb/lookup_sid.c:1045(legacy_uid_to_sid)
>> LEGACY: uid 10000512 -> sid S-1-22-1-10000512
>> [2016/01/04 15:08:21.481344, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/sec_ctx.c:216(push_sec_ctx)
>> push_sec_ctx(110007232, 110000513) : sec_ctx_stack_ndx = 1
>> [2016/01/04 15:08:21.481359, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/uid.c:485(push_conn_ctx)
>> push_conn_ctx(2539132470) : conn_ctx_stack_ndx = 0
>> [2016/01/04 15:08:21.481370, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/sec_ctx.c:316(set_sec_ctx)
>> setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
>> [2016/01/04 15:08:21.481380, 5, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)]
>> ../libcli/security/security_token.c:53(security_token_debug)
>> Security token: (NULL)
>> [2016/01/04 15:08:21.481389, 5, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)]
>> ../source3/auth/token_util.c:629(debug_unix_user_token)
>> UNIX token of user 0
>> Primary group is 0 and contains 0 supplementary groups
>> [2016/01/04 15:08:21.481436, 4, pid=10718, effective(0, 0), real(0, 0),
>> class=passdb] ../source3/passdb/pdb_interface.c:1383(pdb_default_uid_to_sid)
>> pdb_default_uid_to_sid: host has no idea of uid 10004905
>> [2016/01/04 15:08:21.481456, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/sec_ctx.c:424(pop_sec_ctx)
>> pop_sec_ctx (110007232, 110000513) - sec_ctx_stack_ndx = 0
>> [2016/01/04 15:08:21.481467, 10, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)]
>> ../source3/passdb/lookup_sid.c:1045(legacy_uid_to_sid)
>> LEGACY: uid 10004905 -> sid S-1-22-1-10004905
>> [2016/01/04 15:08:21.481486, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/sec_ctx.c:216(push_sec_ctx)
>> push_sec_ctx(110007232, 110000513) : sec_ctx_stack_ndx = 1
>> [2016/01/04 15:08:21.481500, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/uid.c:485(push_conn_ctx)
>> push_conn_ctx(2539132470) : conn_ctx_stack_ndx = 0
>> [2016/01/04 15:08:21.481511, 4, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../source3/smbd/sec_ctx.c:316(set_sec_ctx)
>> setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
>> [2016/01/04 15:08:21.481521, 5, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)]
>> ../libcli/security/security_token.c:53(security_token_debug)
>> Security token: (NULL)
>> [2016/01/04 15:08:21.481530, 5, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)]
>> ../source3/auth/token_util.c:629(debug_unix_user_token)
>> UNIX token of user 0
>>
>> get_nt_acl_internal: blob hash does not match for file . - returning
>> file system SD mapping.
>> [2016/01/04 15:08:21.484342, 10, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0), class=vfs]
>> ../source3/modules/vfs_acl_common.c:554(get_nt_acl_internal)
>> get_nt_acl_internal: acl for blob hash for . is:
>> [2016/01/04 15:08:21.484352, 1, pid=10718, effective(110007232,
>> 110000513), real(110007232, 0)] ../librpc/ndr/ndr.c:296(ndr_print_debug)
>> pdesc_next: struct security_descriptor
>> revision : SECURITY_DESCRIPTOR_REVISION_1 (1)
>> type : 0x9004 (36868)
>> 0: 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
>> 0: SEC_DESC_DACL_AUTO_INHERITED
>> 0: SEC_DESC_SACL_AUTO_INHERITED
>> 1: 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-22-1-65534
>> group_sid : *
>> group_sid : S-1-22-2-65534
>> sacl : NULL
>> dacl : *
>> dacl: struct security_acl
>> revision : SECURITY_ACL_REVISION_NT4 (2)
>> size : 0x017c (380)
>> num_aces : 0x00000010 (16)
>> aces: ARRAY(16)
>> aces: struct security_ace
>> type :
>> SEC_ACE_TYPE_ACCESS_ALLOWED (0)
>> flags : 0x03 (3)
>> 1: SEC_ACE_FLAG_OBJECT_INHERIT
>> 1: SEC_ACE_FLAG_CONTAINER_INHERIT
>> 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
>> 0: SEC_ACE_FLAG_INHERIT_ONLY
>> 0: SEC_ACE_FLAG_INHERITED_ACE
>> 0x03: SEC_ACE_FLAG_VALID_INHERIT (3)
>> 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
>>
>>
>> TO workaround this issue we went back to RID based idmap backend and now
>> for some users are not able to login itself and they get the below error.
>>
>> [2016/01/07 11:39:44.475597, 2, pid=5202]
>> ../source3/param/loadparm.c:3582(do_section)
>>
>> Processing section "[technologyplanning]"
>>
>> [2016/01/07 11:39:44.475960, 1, pid=5202]
>> ../source3/auth/token_util.c:430(add_local_groups)
>>
>> * SID S-1-5-21-3082371790-1274690562-2878062458-5771 ->
>> getpwuid(10005771) failed*
>>
>> [2016/01/07 11:39:44.475993, 1, pid=5202]
>> ../source3/auth/auth_generic.c:119(auth3_generate_session_info_pac)
>>
>> Failed to map kerberos pac to server info (NT_STATUS_UNSUCCESSFUL)
>>
>>
>>
>> Please let me know how we can fix these kind of uid and gid mismatch
>> issues. Customer is not willing to reply ACLs form his side.
>>
>> --
>> Thanks & Regards
>> -Partha
>>
>
>
This could have a lot to do with the fact that idmap_rid & idmap_autorid
calculate the uids differently i.e if you have RID '2025000', autorid
would calculate this as '1102500000' , rid would calculate this as
'12025000'
Rowland
More information about the samba
mailing list