[Samba] SID history secondary group set bloat
Weiser, Michael
michael.weiser at atos.net
Wed Jun 9 09:39:58 UTC 2021
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.
Thanks,
--
Michael Weiser
Senior Solutions Architect
T +49 30 2007 697 22
science + computing ag
Am Studio 16
D-12489 Berlin
https://atos.net/de/deutschland/sc
________________________________________
From: samba <samba-bounces at lists.samba.org> on behalf of Rowland penny via samba <samba at lists.samba.org>
Sent: 08 June 2021 17:30
To: samba at lists.samba.org
Subject: Re: [Samba] SID history secondary group set bloat
Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.
On 08/06/2021 16:00, Weiser, Michael via samba wrote:
> Hi,
>
> I am facing a problem where SIDs from SID history are not mapped through the domain-specific ID mapping configuration and fall back to the default backend tdb. This leads to a bloated UNIX secondary group set in samba sessions which becomes problematic e.g. when accessing NFSv3 mounts which have a limit of 16 secondary groups. With enough SID history in enough groups, other limits may be exceeded, including the fallback backend ID range itself.
>
> Is this known/expected behaviour?
> Can it be prevented by any config option?
>
> winbind:ignore domains does not work since the SIDs are not strictly returned from another domain, so I don't even have a domain name to put there.
>
> I have come up with a workaround of pre-filling the idmap tdb with mappings for SID history SIDs all pointing to the same gid, reducing the bloat to a single gid. Will this work reliably and is it advisable?
>
> I am reluctant to have the AD guys delete the SID history since I suspect I'll from then on be questioned on every access problem anywhere.
>
> I have reduced the issue to the following reproducer setup in a testing environment:
>
> - AD domain EXAMPLE / example.org is run by a single Windows Server 2016 DC and is root domain of its own standalone forest. It doesn't have and never had any trust to any other domain.
>
> - file server is Fedora 33 samba-4.13.9-0.fc33.x86_64. (The issue was observed in production on CentOS 7.9 with samba-4.10.16-13.el7_9.x86_64.)
>
> - user secretuser is member of AD group secret which has a SID history:
>
> [root at fedora33 ~]# wbinfo -n secretuser
> S-1-5-21-4131831116-1822871472-1861548575-1142 SID_USER (1)
> [root at fedora33 ~]# wbinfo --user-domgroups=S-1-5-21-4131831116-1822871472-1861548575-1142
> S-1-5-21-4131831116-1822871472-1861548575-1142
> S-1-5-21-4131831116-1822871472-1861548575-513
> S-1-5-21-4131831116-1822871472-1861548575-1132
> S-1-5-21-4131831116-1822871472-1861548575-1141
> S-1-5-21-2623811102-3361044346-30300840-72198
> S-1-5-21-1623811102-3361044346-30300840-72199
> [root at fedora33 ~]# wbinfo -s S-1-5-21-4131831116-1822871472-1861548575-1141
> EXAMPLE\secret 2
> [root at fedora33 ~]# wbinfo -s S-1-5-21-2623811102-3361044346-30300840-72198
> EXAMPLE\secret 2
> [root at fedora33 ~]# wbinfo -s S-1-5-21-1623811102-3361044346-30300840-72199
> EXAMPLE\secret 2
>
> [root at fedora33 ~]# ldapsearch -h dc -b dc=example,dc=org sidhistory=* dn samaccountname objectsid sidhistory
> [...]
> # secret, Users, EXAMPLE.ORG
> dn: CN=secret,CN=Users,DC=EXAMPLE,DC=ORG
> objectSid:: AQUAAAAAAAUVAAAATL1G9rDPpmwf+vRudQQAAA==
> sAMAccountName: secret
> sIDHistory:: AQUAAAAAAAroot 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 systemdUVAAAAHmTJYHp3VcioWs4BBxoBAA==
> sIDHistory:: AQUAAAAAAAUVAAAAHi5knHp3VcioWs4BBhoBAA==
>
> [root at fedora33 ~]# python3 -mvenv foo
> [root at fedora33 ~]# foo/bin/pip install ldap3
> [root at fedora33 ~]# foo/bin/python -c "import ldap3; import base64; print(ldap3.protocol.formatters.formatters.format_sid(base64.b64decode('AQUAAAAAAAUVAAAATL1G9rDPpmwf+vRudQQAAA==')))"
> S-1-5-21-4131831116-1822871472-1861548575-1141
> [root at fedora33 ~]# foo/bin/python -c "import ldap3; import base64; print(ldap3.protocol.formatters.formatters.format_sid(base64.b64decode('AQUAAAAAAAUVAAAAHmTJYHp3VcioWs4BBxoBAA==')))"
> S-1-5-21-1623811102-3361044346-30300840-72199
> [root at fedora33 ~]# foo/bin/python -c "import ldap3; import base64; print(ldap3.protocol.formatters.formatters.format_sid(base64.b64decode('AQUAAAAAAAUVAAAAHi5knHp3VcioWs4BBhoBAA==')))"
> S-1-5-21-2623811102-3361044346-30300840-72198
>
> - as a shortcut, the SID history was created using DSInternals[1] in the testing environment.
> [1] https://github.com/MichaelGrafnetter/DSInternals/blob/master/Documentation/PowerShell/Add-ADDBSidHistory.md
>
> - Linux users are provided by sssd through NSS with id provider ad and programmatic generation of IDs (ldap_id_mapping = true)
>
> [root at fedora33 ~]# grep ^passwd\\\|^group /etc/nsswitch.conf
> passwd: sss files systemd
> group: sss files systemd
>
> [root at fedora33 ~]# cat /etc/sssd/sssd.conf
> [sssd]
> domains = example.org
> services = nss, pam
> config_file_version = 2
>
> [nss]
> filter_groups = root
> filter_users = root
>
> [pam]
>
> [domain/example.org]
> id_provider = ad
> ad_maximum_machine_account_password_age = 0
>
> [root at fedora33 ~]# id secretuser
> uid=1618201142(secretuser) gid=1618200513(domain users) groups=1618200513(domain users),1618201132(cae),1618201141(secret)
>
> - samba is joined as member and uses backend nss for id mapping:
>
> [root at fedora33 ~]# net ads testjoin
> Join is OK
>
> [root at fedora33 ~]# cat /etc/samba/smb.conf
> [global]
> workgroup = EXAMPLE
> realm = EXAMPLE.ORG
> security = ads
>
> kerberos method = secrets and keytab
>
> debug level = 6
>
> idmap config EXAMPLE : range = 200000-1999999999
> idmap config EXAMPLE : backend = nss
> idmap config * : backend = tdb
> idmap config * : range = 100000-199999
>
> [test]
> path = /srv/test
> read only = no
>
> (The issue was observed in production with id mapping backend sss, accessing sssd directly.)
>
> - When accessing the test share as secretuser, the SID history SIDs of group "secret" appear in the security token, likely extracted from the PAC of the Kerberos ticket. As they don't belong to domain EXAMPLE, they get mapped through the fallback backend to gids 100006 and 100007 and added to the UNIX token in addition to the actual gid 1618201141 of Linux group secret provided by sssd through the NSS:
>
> [root at fedora33 ~]# smbclient -k //fedora33/test -c "exit"
>
> log.smbd:
> [2021/06/08 16:10:50.478779, 4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)
> setting sec ctx (1618201142, 1618200513) - sec_ctx_stack_ndx = 0
> [2021/06/08 16:10:50.478813, 5] ../../libcli/security/security_token.c:56(security_token_debug)
> Security token SIDs (21):
> 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-1618201142
> SID[ 12]: S-1-22-2-1618200513
> SID[ 13]: S-1-22-2-1618201132
> SID[ 14]: S-1-22-2-1618201141
> SID[ 15]: S-1-22-2-100007
> SID[ 16]: S-1-22-2-100006
> SID[ 17]: S-1-22-2-100003
> SID[ 18]: S-1-22-2-100004
> SID[ 19]: S-1-22-2-100005
> SID[ 20]: S-1-22-2-100001
> Privileges (0x 0):
> Rights (0x 0):
> [2021/06/08 16:10:50.478855, 5] ../../source3/auth/token_util.c:873(debug_unix_user_token)
> UNIX token of user 1618201142
> Primary group is 1618200513 and contains 9 supplementary groups
> Group[ 0]: 1618200513
> Group[ 1]: 1618201132
> Group[ 2]: 1618201141
> Group[ 3]: 100007
> Group[ 4]: 100006
> Group[ 5]: 100003
> Group[ 6]: 100004
> Group[ 7]: 100005
> Group[ 8]: 100001
>
> [root at fedora33 ~]# tdbdump /var/lib/samba/winbindd_idmap.tdb
> [...]
> {
> key(11) = "GID 100007\00"
> data(46) = "S-1-5-21-2623811102-3361044346-30300840-72198\00"
> }
> [...]
> {
> key(46) = "S-1-5-21-2623811102-3361044346-30300840-72198\00"
> data(11) = "GID 100007\00"
> }
> [...]
> {
> key(11) = "GID 100006\00"
> data(46) = "S-1-5-21-1623811102-3361044346-30300840-72199\00"
> }
> [...]
> {
> key(46) = "S-1-5-21-1623811102-3361044346-30300840-72199\00"
> data(11) = "GID 100006\00"
> }
>
> - "poisoning" winbind_idmap.tdb with mappings pointing to the same gid reduces the bloat in the group set:
>
> [root at fedora33 ~]# tdbtool /var/lib/samba/winbindd_idmap.tdb
> tdb> delete S-1-5-21-1623811102-3361044346-30300840-72199\00
> tdb> delete GID\20100006\00
> tdb> store S-1-5-21-1623811102-3361044346-30300840-72199\00 GID\20100007\00
> tdb>
> [root at fedora33 ~]# net cache flush
> [root at fedora33 ~]# smbclient -k //fedora33/test -c "exit"
>
> log.smbd:
> [2021/06/08 16:36:28.946220, 4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)
> setting sec ctx (1618201142, 1618200513) - sec_ctx_stack_ndx = 0
> [2021/06/08 16:36:28.946226, 5] ../../libcli/security/security_token.c:56(security_token_debug)
> Security token SIDs (20):
> 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-1618201142
> SID[ 12]: S-1-22-2-1618200513
> SID[ 13]: S-1-22-2-1618201132
> SID[ 14]: S-1-22-2-1618201141
> SID[ 15]: S-1-22-2-100007
> SID[ 16]: S-1-22-2-100003
> SID[ 17]: S-1-22-2-100004
> SID[ 18]: S-1-22-2-100005
> SID[ 19]: S-1-22-2-100001
> Privileges (0x 0):
> Rights (0x 0):
> [2021/06/08 16:36:28.946257, 5] ../../source3/auth/token_util.c:873(debug_unix_user_token)
> UNIX token of user 1618201142
> Primary group is 1618200513 and contains 8 supplementary groups
> Group[ 0]: 1618200513
> Group[ 1]: 1618201132
> Group[ 2]: 1618201141
> Group[ 3]: 100007 <-------- no 100008 any more
> Group[ 4]: 100003
> Group[ 5]: 100004
> Group[ 6]: 100005
> Group[ 7]: 100001
I suggest you ask Fedora, you are not running Samba in a supported way.
You should be running Samba with winbind and without sssd.
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.
Rowland
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
More information about the samba
mailing list