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