thr3ads.net - samba - [Samba] Security permissions issues after changing idmap backend from RID to AUTORID [Jan 2016]

If this information is useful, please help other people find it:
Share via:

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

head link

[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
> -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

Michael Adam

2016-Jan-11 01:16 UTC

head link

[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>

Maybe Matching Threads

Search for more maybe matching threads

samba - Jan 2016 - Security permissions issues after changing idmap backend from RID to AUTORID

[Samba] Security permissions issues after changing idmap backend from RID to AUTORID

[Samba] Security permissions issues after changing idmap backend from RID to AUTORID

[Samba] Security permissions issues after changing idmap backend from RID to AUTORID

Maybe Matching Threads