Hello slow,
Thanks for your answer!
> 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,
As discussed with Rowland, sssd is a red herring here. This happens with local
users as well. The issue seems to be that idmap_nss and (see at the end) (at
least) also idmap_autorid or even id mapping in general do not cope well with
SID history.
IMO presence of SID history would need to be taken into account when routing
mapping requests to the idmap config domains/backends.
> SID history will work when using winbind in nsswitch and an idmap
> backend that supports id-type "both", like rid or autorid.
I've trivially adjusted my config like so (and switched to a fresh Debian
testing system as discussed with Rowland):
root at debian:~# 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 = autorid
idmap config * : backend = tdb
idmap config * : range = 100000-199999
[test]
path = /srv/test
read only = no
And switched to nss_winbind:
root at debian:~# grep ^passwd\\\|^group /etc/nsswitch.conf
passwd: files winbind systemd
group: files winbind systemd
And removed any local users and old caches/tdbs so I don't get bogus output:
root at debian:~# grep ^secret /etc/passwd /etc/group
root at debian:/var/cache/samba# find /var/lib/samba /run/samba /var/cache/samba
-type f | grep -v secrets.tdb | xargs rm -f
root at debian:/var/cache/samba# find /var/lib/samba /run/samba /var/cache/samba
-type f
/var/lib/samba/private/secrets.tdb
This now gets all IDs via idmap_tdb:
root at debian:/var/cache/samba# id example\\secretuser
uid=100000(EXAMPLE\secretuser) gid=100000(EXAMPLE\domain users)
groups=100000(EXAMPLE\domain
users),100001(EXAMPLE\secret),100002(EXAMPLE\secret),100003(EXAMPLE\secret),100004(EXAMPLE\cae)
Is idmap_autorid only supported as default backend? This would nicely sidestep
my issue because, of course, the SID history SIDs could then also be found
there.
I had tried something along those lines in a different context but it didn't
work:
idmap config * : range = 200000-1999999999
idmap config * : backend = nss
idmap config BUILTIN : backend = tdb
idmap config BUILTIN : range = 100000-199999
This would simplify a number of my use-cases greatly (at the expense of having
to make sure AD-side that there's no duplicate sAMAccountNames which is a
common external requirement anyway).
What would be entailed to make this work?
But even when making autorid the default backend:
root at debian:/var/cache/samba# cat /etc/samba/smb.conf
[global]
workgroup = EXAMPLE
realm = EXAMPLE.ORG
security = ads
kerberos method = secrets and keytab
debug level = 6
idmap config * : range = 200000-1999999999
idmap config * : backend = autorid
[test]
path = /srv/test
read only = no
... and clearing caches again, obvs:
root at debian:/var/cache/samba# systemctl stop smbd
root at debian:/var/cache/samba# systemctl stop winbind
root at debian:/var/cache/samba# find /var/lib/samba /run/samba /var/cache/samba
-type f | grep -v secrets.tdb | xargs rm -f
root at debian:/var/cache/samba# find /var/lib/samba /run/samba /var/cache/samba
-type f
/var/lib/samba/private/secrets.tdb
root at debian:/var/cache/samba# systemctl start winbind
I still get a bloated secondary group list:
root at debian:/var/cache/samba# id EXAMPLE\\secretuser
uid=301142(EXAMPLE\secretuser) gid=300513(EXAMPLE\domain users)
groups=300513(EXAMPLE\domain
users),301142(EXAMPLE\secretuser),472199(EXAMPLE\secret),572198(EXAMPLE\secret),301141(EXAMPLE\secret),301132(EXAMPLE\cae)
root at debian:/var/cache/samba# getent group EXAMPLE\\secret
EXAMPLE\secret:x:301141:
root at debian:/var/cache/samba# getent group 472199
EXAMPLE\secret:x:472199:
root at debian:/var/cache/samba# getent group 572198
EXAMPLE\secret:x:572198:
root at debian:/var/cache/samba# getent group 301141
EXAMPLE\secret:x:301141:
autorid apparently also treats SID history as SIDs from separate, existing
domains and assigns separate gids accordingly:
root at debian:/var/cache/samba# tdbdump /var/lib/samba/autorid.tdb
[...]
{
key(40) = "S-1-5-21-1623811102-3361044346-30300840\00"
data(4) = "\02\00\00\00"
}
[...]
{
key(40) = "S-1-5-21-2623811102-3361044346-30300840\00"
data(4) = "\03\00\00\00"
}
[...]
{
key(42) = "S-1-5-21-4131831116-1822871472-1861548575\00"
data(4) = "\01\00\00\00"
}
[...]
log.smbd:
[2021/06/09 11:34:27.402131, 5, pid=1944, effective(0, 0), real(0, 0)]
../../libcli/security/security_token.c:56(security_token_debug)
Security token SIDs (22):
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-301142
SID[ 12]: S-1-22-2-300513
SID[ 13]: S-1-22-2-301142
SID[ 14]: S-1-22-2-301132
SID[ 15]: S-1-22-2-301141
SID[ 16]: S-1-22-2-572198
SID[ 17]: S-1-22-2-472199
SID[ 18]: S-1-22-2-299999
SID[ 19]: S-1-22-2-299990
SID[ 20]: S-1-22-2-299982
SID[ 21]: S-1-22-2-200001
Privileges (0x 0):
Rights (0x 0):
[2021/06/09 11:34:27.402174, 5, pid=1944, effective(0, 0), real(0, 0)]
../../source3/auth/token_util.c:873(debug_unix_user_token)
UNIX token of user 301142
Primary group is 300513 and contains 10 supplementary groups
Group[ 0]: 301142
Group[ 1]: 300513
Group[ 2]: 301132
Group[ 3]: 301141
Group[ 4]: 572198
Group[ 5]: 472199
Group[ 6]: 299999
Group[ 7]: 299990
Group[ 8]: 299982
Group[ 9]: 200001
I can't believe I'm the first running into this. What am I doing wrong?
Thanks!
Michael
________________________________________
From: Ralph Boehme <slow at samba.org>
Sent: 08 June 2021 21:31
To: Weiser, Michael; samba at lists.samba.org
Cc: Laubender, Guido
Subject: Re: [Samba] SID history secondary group set bloat
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