[Samba] SID history secondary group set bloat
Rowland penny
rpenny at samba.org
Tue Jun 8 15:30:02 UTC 2021
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:: AQUAAAAAAAUVAAAAHmTJYHp3VcioWs4BBxoBAA==
> 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
More information about the samba
mailing list