SELinux attributes in Samba domain

[Alexander Bokovoy]

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.


> >
> >If you want to extend the schema to store selinux data, then this
> >should 
> >be possible (you just need the correct .ldif), but you would then need 
> >
> >a tool to extract them from AD.
> >
> In case of using pam_winbind, will it be sth like making an ldap query
> (using ldspsearch? or which tool will be better?) in PAM stack after
> pam_winbind, authenticating via kerberos and making a query for the
> current user name? 

No, this is not really a correct approach, in my opinion. If you really
want to expand winbindd to handle more attributes than what it has now
and allow consumers (e.g. pam_winbind) to have access to them,
you need to:

 - add retrieval of those LDAP objects/attributes to winbind modules

 - add an interface to wbclient API to be able to retrieve these
   additional user properties, regardless where they come from

 - implement logic in pam_winbind to support retrieval of additional
   user properties

 - add server-side support in Samba AD DC

 - add management of these attributes to samba-tool

-- 
/ Alexander Bokovoy