[Samba] Fwd: Re: Fwd: Re: Kerberos and NTLMv2 authentication

Tue Jun 18 13:35:30 UTC 2019

Hello,

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 
Samba.
/[2019/06/18 09:51:44.542476,  3] 
../auth/auth_log.c:760(log_authentication_event_human_readable)//
//  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 
[MYDOMAIN]\[usertest] [S-1-5-21-88155730-3905377117-2757874379-2078]. 
local host [ipv4:x.x.x.x:445]/

I changed to :

passwd:     files *winbind *
shadow:     files
group:      files *winbind *

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] 
../source3/lib/util.c:1699(name_to_fqdn)/**/
/**/  getaddrinfo: temporary failure in name resolution/*

However, I well join my linux station to MYDOMAIN with "realm join" command

and

# realm list
mydomain.local
   type: kerberos
   realm-name: MYDOMAIN.LOCAL
   domain-name: mydomain.local
   configured: kerberos-member
   server-software: active-directory
   client-software: winbind
   required-package: oddjob-mkhomedir
   required-package: oddjob
   required-package: samba-winbind-clients
   required-package: samba-winbind
   required-package: samba-common-tools
   login-formats: MYDOMAIN\%U
   login-policy: allow-any-login
mydomain.local
   type: kerberos
   realm-name: MYDOMAIN.LOCAL
   domain-name: mydomain.local
   configured: kerberos-member
   server-software: active-directory
   client-software: sssd
   required-package: oddjob
   required-package: oddjob-mkhomedir
   required-package: sssd
   required-package: adcli
   required-package: samba-common-tools
   login-formats: %U
   login-policy: allow-realm-logins

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 ?

Best Regards,

Edouard

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."
>>
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers 
>>
>>
>> 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."
>>
>> and
>>
>> "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 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 
>> (DC)."
>>
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers 
>>
>>
>>
>> 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.
>
> Rowland
>
>
>