[Samba] SID history secondary group set bloat
Weiser, Michael
michael.weiser at atos.net
Wed Jun 9 13:35:04 UTC 2021
Hello Rowland,
sorry, again to the list - rocking the groupware here. :/
> Oh yes it does, before Samba 4.8.0 the 'smbd' daemon could contact AD
> directly, bypassing any other method. From Samba 4.8.0 with 'security =
> ADS' in smb.conf , then you must run winbind because 'smbd' can no
> longer contact AD directly.
I am running winbind.
> This also means you cannot run sssd with
> Samba, because sssd has its own version of the winbind libs. To ensure
I understand that sssd could at some point be used as a drop-in replacement for winbind using a replacement libwbclient. I have never seen/used that in practice and the effort seems dead to me. I am taking care not to install those "conflicting" libs:
root at debian:~# apt-cache search libwbclient-sssd
libwbclient-sssd - SSSD libwbclient implementation
libwbclient-sssd-dev - SSSD libwbclient implementation -- development files
root at debian:~# dpkg -l libwbclient-sssd
dpkg-query: no packages found matching libwbclient-sssd
>From your similar discussion with Jeremy back in May[1] (and what I found in one of the production setups I have the current SID history issue with) I have also learned that there is an idmap_sss module for winbind. Since it's a module for winbind it will only work when running winbind and is explicitly meant to give winbind access to existing ID retrieval capabilities of an already configured and running sssd. However, this setup is now no longer recommended for new deployments at least by Redhat[2]. While package dependencies of sssd pull it in on Debian I'm not using that module either:
root at debian:~# dpkg -S /usr/lib/x86_64-linux-gnu/samba/idmap/sss.so
sssd-common: /usr/lib/x86_64-linux-gnu/samba/idmap/sss.so
root at debian:~# grep sss /etc/samba/smb.conf
root at debian:~# grep -r sss /var/log/samba/
/var/log/samba/log.smbd: smbd_smb2_request_done_ex: mid [1] idx[1] status[NT_STATUS_OK] body[8] dyn[yes:186] at ../../source3/smbd/smb2_sesssetup.c:183
[...]
root at debian:~# grep nss /etc/samba/smb.conf
idmap config EXAMPLE : backend = nss
root at debian:~# grep -r nss /var/log/samba/
/var/log/samba/log.winbindd-idmap: Successfully added idmap backend 'nss'
[...]
[1] https://lists.samba.org/archive/samba/2021-May/235888.html
[2] https://access.redhat.com/articles/4355391
> that Samba works correctly, you should remove sssd and use 'winbind' in
> /etc/nsswitch.conf, also 'idmap_nss' was really meant to be used with
> earlier versions of Samba, where a workgroup user could be mapped to a
> local Unix users, with AD it is recommended to use one of the winbind
> backends ('ad', 'rid', 'autorid') instead. By using one of these
> backends, the AD users become Unix users.
Could you maybe give an example or point me to a discussion what breakage idmap_nss suffers from? I'm having trouble understanding the reason for the deprecation. sssd also makes AD users become Unix users and idmap_nss generically gives winbind access to that information.
What would from your point of view need to happen to make idmap_nss a first-class idmap citizen for AD-joined samba file servers?
While the recommendation of using nss_winbind may be good practice for green-field deployments and pure samba storage appliances, it severely limits options for existing deployments where there may be billions of existing files owned by IDs resolved via NSS against some LDAP (not even necessarily an AD) using e.g. nslcd or sssd that can not easily be migrated to one of the winbind idmap modules you list.
I've done quite a number of AD migration projects where UNIX/Linux IDs were migrated to AD and they're huge, sometimes multi-year efforts. And even then it was sometimes not possible to fit all constraints into one of the schemas supported by idmap_ad.
With nslcd/sssd and idmap_nss there's a lot more flexibility in configuring which LDAP attributes in AD (or any other LDAP) store which Linux user attributes in what format. idmap_ad doesn't have those options and reimplementing them there would be a huge effort in its own right. If efforts to have direct adapters to sssd have been given up on, it would be of great benefit to a number of clients if at least the idmap_nss approach kept working.
And, to reiterate, it really is working. The SID history issue which sparked this discussion seems not to be limited to idmap_nss and otherwise it works fine for the use-cases I'm dealing with.
Thanks,
Michael
________________________________________
From: samba <samba-bounces at lists.samba.org> on behalf of Rowland penny via samba <samba at lists.samba.org>
Sent: 09 June 2021 13:21
To: sambalist
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 09/06/2021 10:39, Weiser, Michael wrote:
> 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 agoichael
--
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
> [...]
>
> 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.
Oh yes it does, before Samba 4.8.0 the 'smbd' daemon could contact AD
directly, bypassing any other method. From Samba 4.8.0 with 'security =
ADS' in smb.conf , then you must run winbind because 'smbd' can no
longer contact AD directly. This also means you cannot run sssd with
Samba, because sssd has its own version of the winbind libs. To ensure
that Samba works correctly, you should remove sssd and use 'winbind' in
/etc/nsswitch.conf, also 'idmap_nss' was really meant to be used with
earlier versions of Samba, where a workgroup user could be mapped to a
local Unix users, with AD it is recommended to use one of the winbind
backends ('ad', 'rid', 'autorid') instead. By using one of these
backends, the AD users become Unix users.
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