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
Rowland penny
2016-Jan-10 17:58 UTC
[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
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 > -ParthaYou 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
Michael Adam
2016-Jan-11 01:16 UTC
[Samba] Security permissions issues after changing idmap backend from RID to AUTORID
On 2016-01-10 at 17:58 +0000, Rowland penny wrote:> On 10/01/16 17:05, Partha Sarathi wrote: > > > > > 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' > > > >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, > > > >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. > > 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,Indeed. Rowland is completely right. This is the your major problem. And it is really, really severe. The IDs from the old mappings are everywhere in the share file systems: Ownership and ACLs. Changing the mapping to a different mapping, this is what happens: - People lose access to their files since the permissions are for different IDs (that previously belonged to their name/sid). ==> Thie is the ACCESS DENIED you saw. - People may be granted access to files they should not have access to (files created by previous holders of their new ID). - If people create new files, they will be created by the new IDs, so a mix-up will start. You need to prevent that, so cut the network cable asap... So what can you do about it? - If you have not done it, take the server offline immediately, so that no further mix-up can happen. - Ideally, change your config back to the original "rid" config. As Rowland asked: Why was it changed in the first place?... - If that is not possible for some reason, you _might_ get away with cleaning your autorid database and pre-creating an appropriate range allocation for your main domain with the command 'net idmap set range'. (Provided the range size is the same and the autorid range includes the previous rid range as a fully aligned sub-range.) But beware that this is a very low-level tool and you should only run it while winbindd is not running. See the net(8) manpage. Cheers - Michael PS: Everybody: NEVER change the idmap configuration just like that on a production system! EVER! (Unless you want to lose (access to) your data.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20160111/73f8661e/signature.sig>
Possibly Parallel 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