Security permissions issues after changing idmap backend from RID to AUTORID
Partha Sarathi
parthasarathi.bl at gmail.com
Mon Jan 11 01:13:03 UTC 2016
Thanks Richard for replying.
I agree that cached information causing these kind of issues. But if I
clear cache and start samba with RID, users are able to authenticate but
they are unable to access shares as their permissions are modified in POSIX
ACLs with AUTO_RID range.
The wbinfo shows as below,
wbinfo --user-info=hudsond
hudsond:*:10005771:110000513::None:None
wbinfo --uid-info=10005771
failed to call wbcGetpwuid: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for uid 10005771
So I am not sure other than reapplying ACLs from windows what other fix can
solve this issue.
Regards,
--Partha
On Sun, Jan 10, 2016 at 4:24 PM, Richard Sharpe <realrichardsharpe at gmail.com
> wrote:
> On Fri, Jan 8, 2016 at 10:22 AM, Partha Sarathi
> <parthasarathi.bl at gmail.com> wrote:
> > Hi,
>
> Looks like your customer is in a world of pain.
>
> The key seems to be why is it unable to convert the PAC to UIDs/GIDs.
>
> In particular, why does it fail to convert
>
> * SID S-1-5-21-3082371790-1274690562-2878062458-5771 -> getpwuid(10005771)
>
> Perhaps there is some cached info left over from before that got
> screwed up when you went from RID to AUTORID and back.
>
> What does wbinfo show for that SID and UID.
>
> > 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
>
>
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
>
--
Thanks & Regards
-Partha
More information about the samba-technical
mailing list