[Samba] SID history secondary group set bloat

Tue Jun 8 15:00:17 UTC 2021

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
-- 
Thanks,
Michael