[Samba] Fwd: Re: Fwd: Re: Kerberos and NTLMv2 authentication
rpenny at samba.org
Mon Jun 17 19:26:39 UTC 2019
On 17/06/2019 20:05, Goetz, Patrick G via samba wrote:
> On 6/17/19 12:37 PM, Edouard Guigné via samba wrote:
>> On my linux box (centos 7), I set Samba + Winbind against AD.
>> But I also set SSSD against AD for an other purpose (sftp access).
>> I am wondering if there is no risk to disable sftpd/sssd if I add
>> winbind in /etc/nsswitch.conf
>> Can Winbind and SSSD be installed on the same system if they are not
>> used for the same purpose ?
> I'm wondering this myself. Regarding nsswitch.conf, the options are
> searched in order. So
> passwd: compat systemd sss winbind
> shadow: compat sss windbind
> would presumably look in the local /etc/passwd|shadow files first for
> authentication, then check sssd, and finally winbind. The question is
> will a Samba mount fail trying to use sssd?
Possibly it could fail.
> You could try putting
> winbind before sssd, or in theory winbind should be able to handle ssh
> authentication? Can someone confirm this?
It does, at least it always has for me ;-)
> I'm still confused by the RHEL documentation on this. Rowland is
> correct, the RHEL 8 documentation states this:
> "Red Hat only supports running Samba as a server with the winbindd
> service to provide domain users and groups to the local system. Due to
> certain limitations, such as missing Windows access control list (ACL)
> support and NT LAN Manager (NTLM) fallback, SSSD is not supported."
> What's confusing is that the RHEL 7 documentation says:
> "Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this
> functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer
> need to run Winbind and SSSD in parallel to access SMB shares. For
> example, accessing the Access Control Lists (ACLs) no longer requires
> Winbind on SSSD clients."
> "4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares
> For most SSSD clients, using SSSD is recommended:"
> and most worrisome, in my use case:
> "In environments with direct Active Directory integration where the
> clients use SSSD for general Active Directory user mappings, using
> Winbind for the SMB ID mapping instead of SSSD can result in
> inconsistent mapping."
I think there they were talking about using winbind on one client and
sssd on another and yes, you would get different numeric ID's in that case.
> What changed between versions 7 and 8 of RHEL/Cent OS? Is it just the
> upgrade from Samba 4.7.x to 4.8.x?
Yes, smbd used to be able to connect to AD without winbindd, but from
Samba 4.8.0, this was removed and winbind now needs to be run on a Unix
> What's especially weird is that RHEL
> does not support the use of Samba as an AD domain controller:
> "Red Hat does not support running Samba as an AD domain controller (DC)."
> They want you to use idM, which is closely associated with sssd, which
> begs the question "are they assuming no one is going to want to serve
> files from a linux box to Windows systems? At least in my environment,
> that's a very poor assumption indeed.
I thought something similar myself, but when you consider that their
target audience is business and they can sort of dictate/recommend what
to use and what they will support.
> Question: How feasible would it be to have a version of smbd that just
> works with sssd. I understand a big feature of Samba 4 is providing a
> standalone AD domain controller, but for environments that already have
> AD, kind of all you really need is file services, and it would be very
> convenient to be able to install a version of smbd that just works with
> sssd out of the box.
Don't think this is going to happen (but what do I know ?), I could sort
of understand dropping 'nmbd' but 'smbd' & 'winbindd' will give you just
the same as using sssd with Samba, with only one config file. Can I ask
you what you use sssd for ? is it just for authentication, or something
else as well ?
What you also have to remember is that sssd is not a Samba product and
we have no control over its development.
More information about the samba