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

[Partha Sarathi Besgarahalli Lakshmaiah]

Thanks Michael,

Please see the inline answers.

> On Jan 10, 2016, at 5:16 PM, Michael Adam <obnox at samba.org> wrote:
> 
> 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:

The Change was required to support the "Trusted Domain” where RID backend  can not support it.
> 
> - 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.
> 
Yeah this is true  when we by mistake modifies POSIX acls directly then get_nt_acl_internal try to construct the SD by deriving SIDs for every UID on the POSIX list. other wise it will never get into to that path. 

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


root at partha:/var/lib/samba# net -V
Version 4.1.17-Debian

root at partha:/var/lib/samba# net idmap --help
Usage:
net idmap dump
  Dump the current ID mappings
net idmap restore
  Restore entries from stdin
net idmap setmap
  Not implemented yet
net idmap delete <ID>
  Delete ID mapping
net idmap secret <DOMAIN> <secret>
  Set secret for specified domain
net idmap check
  Check id mappings

root at partha:/var/lib/samba# net idmap setmap 
Not implemented yet
> 
> 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.)

Probably I try to remove the affected (4) users from the cache tdb using 'net cache get’ and net cache del’ and see if that works for customer.

Thanks again for suggesting workaround and possible solution.

Regards,
—Partha