Partha Sarathi
2016-Jan-08 19:30 UTC
[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
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 >-- Thanks & Regards -Partha
Rowland penny
2016-Jan-10 16:32 UTC
[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
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
Partha Sarathi
2016-Jan-10 17:05 UTC
[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
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
Reasonably Related Threads
- Security permissions issues after changing idmap backend from RID to AUTORID
- Security permissions issues after changing idmap backend from RID to AUTORID
- Security permissions issues after changing idmap backend from RID to AUTORID
- Security permissions issues after changing idmap backend from RID to AUTORID
- Security permissions issues after changing idmap backend from RID to AUTORID