[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
Partha Sarathi
parthasarathi.bl at gmail.com
Sun Jan 10 17:05:25 UTC 2016
Thanks for the reply. Now we end-up with mix uid/gid from both ranges in
cache TDBs. Few user logins are denied with below error in smbd.log,
*[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**
wbinfo --user-info=mariond
mariond:*:10015138:110000513:Marion, Deborah:None:None
wbinfo --uid-info=10015138
mariond:*:10015138:110000513:Marion, Deborah:None:None
If you notice above mappings, i.e a RID based UID is mapped to AUOT_RID
based GID.
Is there way to cleanup these mismatch uid/gid information in TDBs(like
winbind_cache.tdb or gencahe.tdb) or remove all TDBs start afresh.
Regards,
--Partha
On Sun, Jan 10, 2016 at 8:32 AM, Rowland penny <rpenny at samba.org> wrote:
> 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
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
--
Thanks & Regards
-Partha
More information about the samba
mailing list