[Samba] SID history secondary group set bloat

[Rowland penny]

On 09/06/2021 10:39, Weiser, Michael wrote:
> Hello Rowland,
>
> Thanks for your answer!
>
>> I suggest you ask Fedora,
> Fedora was just a testing system I had ready which provided me with a somewhat recent samba package. I can reproduce the issue with current Debian testing samba 4.13.5+dfsg-2 as well. From its determinism so far, I'd expect it to persist if I compiled samba HEAD.
>
>>   you are not running Samba in a supported way.
>> You should be running Samba with winbind and without sssd.
> I am running the winbind service for ID mapping to work at all. sssd has no bearing on the issue. I can reproduce the issue with local users as well:
>
> root at debian:~# systemctl status winbind
> ● winbind.service - Samba Winbind Daemon
>       Loaded: loaded (/lib/systemd/system/winbind.service; enabled; vendor preset: enabled)
>       Active: active (running) since Wed 2021-06-09 10:26:59 CEST; 15min ago
> [...]
>
> root at debian:~# id secretuser
> uid=1001(secretuser) gid=1001(secretuser) groups=1001(secretuser),1002(secret),1003(cae)
>
> root at debian:~# grep ^passwd\\\|^group /etc/nsswitch.conf
> passwd:         files systemd
> group:          files systemd
>
> root at debian:~# grep ^secret /etc/passwd /etc/group
> /etc/passwd:secretuser:x:1001:1001::/home/secretuser:/bin/sh
> /etc/group:secretuser:x:1001:
> /etc/group:secret:x:1002:secretuser
>
> root at debian:~# smbclient -k //debian/test -c exit
>
> log.smbd:
> [2021/06/09 10:28:07.973482,  5] ../../libcli/security/security_token.c:56(security_token_debug)
>    Security token SIDs (19):
>      SID[  0]: S-1-5-21-4131831116-1822871472-1861548575-1142
>      SID[  1]: S-1-5-21-4131831116-1822871472-1861548575-513
>      SID[  2]: S-1-5-21-4131831116-1822871472-1861548575-1132
>      SID[  3]: S-1-5-21-4131831116-1822871472-1861548575-1141
>      SID[  4]: S-1-5-21-2623811102-3361044346-30300840-72198
>      SID[  5]: S-1-5-21-1623811102-3361044346-30300840-72199
>      SID[  6]: S-1-18-1
>      SID[  7]: S-1-1-0
>      SID[  8]: S-1-5-2
>      SID[  9]: S-1-5-11
>      SID[ 10]: S-1-5-32-545
>      SID[ 11]: S-1-22-1-1001
>      SID[ 12]: S-1-22-2-1001
>      SID[ 13]: S-1-22-2-100006
>      SID[ 14]: S-1-22-2-100007
>      SID[ 15]: S-1-22-2-100003
>      SID[ 16]: S-1-22-2-100004
>      SID[ 17]: S-1-22-2-100008
>      SID[ 18]: S-1-22-2-100001
>     Privileges (0x               0):
>     Rights (0x               0):
> [2021/06/09 10:28:07.973524,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)
>    UNIX token of user 1001
>    Primary group is 1001 and contains 6 supplementary groups
>    Group[  0]: 100006
>    Group[  1]: 100007
>    Group[  2]: 100003
>    Group[  3]: 100004
>    Group[  4]: 100008
>    Group[  5]: 100001
>
> root at debian:~# tdbdump /var/lib/samba/winbindd_idmap.tdb
> {
> key(11) = "GID 100007\00"
> data(46) = "S-1-5-21-1623811102-3361044346-30300840-72199\00"
> }
> [...]
> {
> key(46) = "S-1-5-21-2623811102-3361044346-30300840-72198\00"
> data(11) = "GID 100006\00"
> }
> [...]
> {
> key(11) = "GID 100006\00"
> data(46) = "S-1-5-21-2623811102-3361044346-30300840-72198\00"
> }
> [...]
> {
> key(46) = "S-1-5-21-1623811102-3361044346-30300840-72199\00"
> data(11) = "GID 100007\00"
> }
>
>> Samba does not produce sssd, so knows very little about it and if you
>> just require authentication, then you probably do not need to use Samba,
>> it is only when you use shares that you need Samba.
> I do want to share files on the Linux filesystem, so I do need to run smbd. But I also have existing Linux users with existing IDs and files owned by them I want to export. Using nss_winbind is therefore not always an option if I want to avoid changing ownerships of existing files. idmap_nss is the answer to that and works very well apart from the SID history issue. Surely, using idmap_nss is supported for such use-cases, otherwise what's the point of having it?
>
> Authentication to the Linux system is a separate issue and does not impact the problem at hand.


Oh yes it does, before Samba 4.8.0 the 'smbd' daemon could contact AD 
directly, bypassing any other method. From Samba 4.8.0 with 'security = 
ADS' in smb.conf , then you must run winbind because 'smbd' can no 
longer contact AD directly. This also means you cannot run sssd with 
Samba, because sssd has its own version of the winbind libs. To ensure 
that Samba works correctly, you should remove sssd and use 'winbind' in 
/etc/nsswitch.conf, also 'idmap_nss' was really meant to be used with 
earlier versions of Samba, where a workgroup user could be mapped to a 
local Unix users, with AD it is recommended to use one of the winbind 
backends ('ad', 'rid', 'autorid') instead. By using one of these 
backends, the AD users become Unix users.

Rowland