[Samba] Fwd: Re: Fwd: Re: Kerberos and NTLMv2 authentication
eguigne at pasteur-cayenne.fr
Tue Jun 18 13:35:30 UTC 2019
On my system, nssswitch is like this :
passwd: files sss
shadow: files sss
group: files sss
So I assumed that it works with SSSD, I do not notice any issue with Samba.
My share is accessible, permissions acls are working.
The only thing I noticed is maybe NTLMv2 is always used by default with
/[2019/06/18 09:51:44.542476, 3]
// Auth: [SMB2,(null)] user [MYDOMAIN]\[usertest] at [mar., 18 juin
2019 09:51:44.542436 -03] with [*NTLMv2*] status [NT_STATUS_OK]
workstation [WORKSTATIONTEST] remote host [ipv4:x.x.x.x:53352] became
local host [ipv4:x.x.x.x:445]/
I changed to :
passwd: files *winbind *
group: files *winbind *
N.B. : According to
"/Do not add the //|winbind|//entry to the NSS //|shadow|//database.
This can cause the //|wbinfo|//utility fail./"
Is that still true ?
But now, I cannot connect to the share at all with winbind instead of
sss in nsswitch.conf
I log, I get :
*/[2019/06/18 09:51:44.511561, 1]
/**/ getaddrinfo: temporary failure in name resolution/*
However, I well join my linux station to MYDOMAIN with "realm join" command
# realm list
I checked /etc/resolv.conf, for me everything is correct ; the DNS IPs
are the IPs of the domain controllers on where DNS services are running.
I do not want to annoy anymore with my problem of a mixed configuration
SSSD / Winbindd ; but I would like to understand why this is working
only with SSSD and not with winbindd.
Maybe because I first join my linux station to the domain with SSSD ?
And then rejoined it to the domain with winbindd ?
Le 17/06/2019 à 16:26, Rowland penny via samba a écrit :
> 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
>> 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 domain member.
>> 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
>> 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