SELinux attributes in Samba domain

Alexander Bokovoy ab at samba.org
Tue Sep 15 15:01:02 UTC 2020


On ti, 15 syys 2020, Rowland penny via samba-technical wrote:
> On 15/09/2020 15:13, Alexander Bokovoy wrote:
> > On ti, 15 syys 2020, Mikhail Novosyolov via samba-technical wrote:
> > > 
> > > 15 сентября 2020 г. 14:50:52 GMT+03:00, Rowland penny via samba-technical <samba-technical at lists.samba.org> пишет:
> > > > On 15/09/2020 12:08, Mikhail Novosyolov wrote:
> > > > > 15 сентября 2020 г. 10:10:32 GMT+03:00, Rowland penny via
> > > > samba-technical <samba-technical at lists.samba.org> пишет:
> > > > > > Your problem will come with sssd, it isn't supported by Samba
> > > > (because
> > > > > > we do not produce it and no little about it) and even Red-Hat no
> > > > longer
> > > > > > supports it use with Samba.
> > > > > > 
> > > > > What is the problem to use sssd as a client to enroll into Samba AD
> > > > domain?
> > > > 
> > > > Before Samba 4.8.0 , the smbd deamon could contact AD directly, this
> > > > meant you could use sssd with Samba, instead of using winbind. From
> > > > Samba 4.8.0, if 'security = ADS' is set in smb.conf, smbd must contact
> > > > winbind, it can no longer contact AD directly. You cannot install sssd
> > > > and winbind together, they both have their own versions of the winbind
> > > > libs.
> > > Yeah, I know that sssd has its own libwbclient.so.0, but did not study
> > > details. I still can't understand the initial problem. If sssd and
> > > wbclient conflict on the client side, samba's winbind may be turned
> > > off, right? What does prevent from using sssd as a client for samba
> > > domains?
> > libwbclient from SSSD is deprecated and should have been removed
> > (already or in upcoming releases). It should not affect any operation as
> > its use is not needed. For cooperative setup where both winbindd and
> > SSSD work together on a client, idmap_sss is what is needed in Samba
> > configuration.
> > 
> > There is no problem in running SSSD and winbindd on a client side; the
> > catch is what use case we are dealing with. SSSD does not support
> > pass-through authentication ([MS-NRPC] sec. 3.2), so it will not be able
> > to authenticate users from domains unreachable by the client through
> > Kerberos trust path link towards their domain controllers, but for all
> > other situations SSSD should just work fine.  Technically, it is
> > possible to use a direct LDAP bind account from that user domain to make
> > it possible for SSSD to talk to that DC (it doesn't need to be a machine
> > account, really), so even with this case it is possible to have a
> > combined setup.
> > 
> > Note that in this case winbindd would not be able to pick up any POSIX
> > attributes too because it wouldn't be able to reach the user's domain
> > global catalog or LDAP instance on that DC either -- using LSA
> > functionality it is not possible to query anything beyond basic NT token
> > details anyway.
> 
> Thanks for backing up what I am saying, if you use sssd with Samba it isn't
> as good as using winbind, so do not bother.
> 
> Before anyone accuses me of hating sssd, I don't, I just do not see the
> point of using it with Samba, winbind does more. I used to use sssd until I
> realised that I only needed to setup one conf file to get the same data.

winbind does not support smartcard authentication and certificate
mapping, it does not support multi-factor authentication either. As
discussed in this thread, SELinux context enforcements delivery is
another feature that is not existing in pam_windbind. Same with sudo
rules. These (and many others) features of SSSD are important enough to
a wide variety of users to use SSSD instead of going with other stacks
(which do not include winbind either).

I love that we have favorite topics to argue about but a single use case
cannot define alone what you should be requiring all other users to do.
If we can get improvements on par in various open source components, we
are at better state than just rejecting a need for those improvements.
After all, Mikhail is asking what to do to contribute the support for
a centralized SELinux context delivery, not asking us to implement it.

-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list