samba - Jun 2019 - Fwd: Re: Fwd: Re: Kerberos and NTLMv2 authentication

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 *

N.B. : According to 
https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
"/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] 
../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
>
>
>

On 18/06/2019 14:35, Edouard Guign? via samba wrote:
> 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 *
>
> N.B. : According to 
> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
> "/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] 
> ../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 ?
>
When you changed 'sss' to 'winbind', did you also reconfigure
smb.conf ?

Is winbind installed ?

Rowland

Winbind is installed and started :
/# yum list samba-winbind samba-winbind-clients pam_krb5
pam_krb5.x86_64 2.4.8-6.el7????????????????? @base
samba-winbind.x86_64 4.8.3-4.el7????????????????? @base
samba-winbind-clients.x86_64 4.8.3-4.el7????????????????? @base
# systemctl status winbind -l
? winbind.service - Samba Winbind Daemon
 ?? Loaded: loaded (/usr/lib/systemd/system/winbind.service; enabled; 
vendor preset: disabled)
 ?? Active: active (running) since mar. 2019-06-18 09:50:43 -03; 1h 
29min ago
 ???? Docs: man:winbindd(8)
 ?????????? man:samba(7)
 ?????????? man:smb.conf(5)
 ?Main PID: 5430 (winbindd)
 ?? Status: "winbindd: ready to serve connections..."
 ?? CGroup: /system.slice/winbind.service
 ?????????? ??5430 /usr/sbin/winbindd --foreground --no-process-group
 ?????????? ??5478 /usr/sbin/winbindd --foreground --no-process-group
 ?????????? ??5535 /usr/sbin/winbindd --foreground --no-process-group
 ?????????? ??5538 /usr/sbin/winbindd --foreground --no-process-group
 ?????????? ??5540 /usr/sbin/winbindd --foreground --no-process-group

juin 18 09:50:43 myserver systemd[1]: Starting Samba Winbind Daemon...
juin 18 09:50:43 myserver winbindd[5430]: [2019/06/18 09:50:43.238610,? 
0] ../source3/winbindd/winbindd_cache.c:3160(initialize_winbindd_cache)
juin 18 09:50:43 myserver winbindd[5430]: initialize_winbindd_cache: 
clearing cache and re-creating with version number 2
juin 18 09:50:43 myserver systemd[1]: Started Samba Winbind Daemon.
juin 18 09:50:43 myserver winbindd[5430]: [2019/06/18 09:50:43.255256,? 
0] ../lib/util/become_daemon.c:138(daemon_ready)
juin 18 09:50:43 myserver winbindd[5430]:?? daemon_ready: STATUS=daemon 
'winbindd' finished starting up and ready to serve connections/

I did not changed smb.cnf :

[global]
 ??????? security = ads
 ??????? realm = MYDOMAIN.LOCAL
 ??????? workgroup = MYDOMAIN
 ??????? kerberos method = secrets and keytab
 ??????? server signing = mandatory
 ??????? client signing = mandatory

 ??????? hosts allow = 127. 10.X.X.
 ??????? hosts deny = 10.X.X.

 ??????? log level = 1 auth_audit:3
 ??????? local master = no
 ??????? domain master = no
 ??????? preferred master = no

 ??????? use sendfile = true

 ??????? load printers = no
 ??????? cups options = raw
 ??????? printcap name = /dev/null

 ? ? ?? disable spoolss = yes

 ??????? vfs objects = acl_xattr
 ??????? map acl inherit = yes
 ??????? store dos attributes = yes

 ??? idmap config * : backend = tdb

 ??? idmap config * : range = 15000-99999

 ??? ??? winbind nss info = rfc2307
 ??? ??? idmap config MYDOMAIN : backend = ad
 ??? ??? idmap config MYDOMAIN : schema_mode = rfc2307

 ??? ??? idmap config MYDOMAIN : range = 10000-14999

 ??? ??? idmap config MYDOMAIN : unix_nss_info = yes

 ??? ??? idmap config MYDOMAIN : unix_primary_group = yes

 ??? client min protocol = SMB2

 ??? username map = /etc/samba/user.map

[groups]
 ? comment = mycomment
 ? path = /var/datashared
 ? public = no
 ? writable = yes

 ? valid users = @"utilisateurs du domaine at MYDOMAIN.LOCAL"

 ? vfs objects = acl_xattr streams_xattr

[homes]
 ??????? comment = Home Directories
 ??????? read only = No
 ??????? create mask = 0700
 ??????? directory mask = 0700
 ??????? valid users = @"utilisateurs du domaine at MYDOMAIN.LOCAL"
 ??????? path = /home
 ??????? hide files = /~*.tmp/profile/desktop.ini/~$*/
 ??????? browseable = no
 ??????? public = no
 ??????? guest ok = no

[printers]
 ??????? comment = All Printers
 ??????? path = /var/tmp
 ??????? printable = Yes
 ??????? create mask = 0600
 ??????? browseable = No

[print$]
 ??????? comment = Printer Drivers
 ??????? path = /var/lib/samba/drivers
 ??????? write list = root
 ??????? create mask = 0664
 ??????? directory mask = 0775



Le 18/06/2019 ? 11:06, Rowland penny via samba a ?crit?:
> On 18/06/2019 14:35, Edouard Guign? via samba wrote:
>> 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 *
>>
>> N.B. : According to 
>> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
>> "/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] 
>> ../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 ?
>>
> When you changed 'sss' to 'winbind', did you also
reconfigure smb.conf ?
>
> Is winbind installed ?
>
> Rowland
>
>
>

On 6/18/19 8:35 AM, Edouard Guign? via samba wrote:
> 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 ?
> 
AFAIK, once you're joined to the domain, you're joined to the domain; it
doesn't matter how you got there.

The issues I've run into is getting the Kerberos ticket and machine 
password to update automatically.

On 18/06/2019 16:01, Goetz, Patrick G via samba wrote:
> On 6/18/19 8:35 AM, Edouard Guign? via samba wrote:
>> 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 ?
>>
> AFAIK, once you're joined to the domain, you're joined to the
domain; it
> doesn't matter how you got there.
>
> The issues I've run into is getting the Kerberos ticket and machine
> password to update automatically.
>
>
>
winbind refresh tickets = yes

Rowland