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
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]: 100001I 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
Am 08.06.21 um 17:00 schrieb Weiser, Michael via samba:> 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?I don't know if this setup with the choice of sssd in nsswitch and idmapping with nss backend can be bent to will, but from a high level, SID history will work when using winbind in nsswitch and an idmap backend that supports id-type "both", like rid or autorid. Cheers! -slow -- Ralph Boehme, Samba Team https://samba.org/ Samba Developer, SerNet GmbH https://sernet.de/en/samba/ GPG-Fingerprint FAE2C6088A24252051C559E4AA1E9B7126399E46 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20210608/9886c376/OpenPGP_signature.sig>