[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
Rowland penny
rpenny at samba.org
Sun Jan 10 17:58:44 UTC 2016
On 10/01/16 17:05, Partha Sarathi wrote:
> 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
> <mailto: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 <mailto: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 <tel:%282539132470>) :
> 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 <tel:%282539132470>) :
> 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
You could try running 'net cache flush', but that isn't your only
problem, files saved before you changed will belong to the ID created by
the rid backend and files created after the change will belong to the ID
created by autorid, what ever made you change the idmap backend on a
running production system ?
Rowland
More information about the samba
mailing list