samba - Apr 2016 - Nonfunctional linux/CIFS mounts after update (ADS / windows DC auth)

Greetings,

We use samba to share files to windows and linux machines and are in the
same boat as several others recently posting to the list. When badlock
patches came out, we updated our CentOS7 samba server (everything from
samba to sssd to krb5 to nss was updated) and immediately had problems with
both client types not connecting to the windows shares.

Windows machine connections were solved by using the realm
(workgroup.com\username)
to log in instead of the workgroup (workgroup\username). Although it's not
clear to me as to why I need '.com' to authenticate all of a sudden, it
functions and isn't a critical concern for this production server.

Linux machines were mounting via 'mount -t cifs -o
user=workgroup/username'. This mount no longer functions and it appears
(setting server log level to 10) that the authentication on the server is
failing where it used to succeed. 'smbclient' also fails. In a weird
twist
that may prove relevant, clients can use the nautilus 'connect to
server'
function to connect successfully and the share works fine. However, we need
a linux mount in order to run our applications from the share. I've tried
mounting using 'workgroup.com/username' analogous to the
'solution' for
Windows as well as specifying the domain= and workgroup= options; no dice.

The appended configuration (workgroup, realm, and netbios name sanitized)
has been in production for 5 years through several samba versions on
several operating systems.
We don't and have never run winbind on the system, so winbind is off. I
rejoined the machine to the domain (got a ticket successfully) and I can
retrieve users and groups via 'getent' (sssd seems to function fine).
Samba
finds and seems to talk to the windows domain controller correctly in the
verbose samba connection logs. If anyone has an idea as to where to look
next, I'd love some input.

Thanks for any assistance,
Patrick

> [global]
> workgroup = WORKGROUP
> server string = Linux Server
> netbios name = SRVNAME
> log level = 1
> security = ads
> dedicated keytab file = /etc/krb5.keytab
> kerberos method = system keytab
> realm = WORKGROUP.COM
> passdb backend = tdbsam
> socket options = TCP_NODELAY IPTOS_LOWDELAY
> client NTLMv2 auth = yes
>
> oplocks = False
> level2oplocks = False
> posix locking = no
>
> log file = /var/log/samba/log.%m
> max log size = 5000
> include = /etc/samba/rhs-samba.conf
>
> [test]
>  path = /home/test
>  inherit permissions = yes
>  inherit acls = yes
>  public = yes
>  only guest = no
>  writable = yes
>  printable = no
>  browseable = yes
>  strict locking = no
>

On Tue, Apr 26, 2016 at 12:06:39PM -0400, Glomski, Patrick
wrote:
> Greetings,
> 
> We use samba to share files to windows and linux machines and are in the
> same boat as several others recently posting to the list. When badlock
> patches came out, we updated our CentOS7 samba server (everything from
> samba to sssd to krb5 to nss was updated) and immediately had problems with
> both client types not connecting to the windows shares.
> 
> Windows machine connections were solved by using the realm
> (workgroup.com\username)
> to log in instead of the workgroup (workgroup\username). Although it's
not
> clear to me as to why I need '.com' to authenticate all of a
sudden, it
> functions and isn't a critical concern for this production server.
> 
> Linux machines were mounting via 'mount -t cifs -o
> user=workgroup/username'. This mount no longer functions and it appears
> (setting server log level to 10) that the authentication on the server is
> failing where it used to succeed. 'smbclient' also fails. 
Get a wireshark trace and post what error is returned please.

Failure for me is always:

SMB PACKET: SMBsesssetupX (REPLY)
> SMB Command   =  0x73
> Error class   =  0x6D
> Error code    =  49152 (0xc000)
> Flags1        =  0x80
> Flags2        =  0x3
> Tree ID       =  0 (0x0)
> Proc ID       =  12056 (0x2f18)
> UID           =  29165 (0x71ed)
> MID           =  3 (0x3)
> Word Count    =  0 (0x0)
> NTError = STATUS_LOGON_FAILURE
> smb_bcc=0
>
Credentials are correct; it works through nautilus' smb://...

Let me know what else would help to diagnose. I can also privately share
verbose samba or other logs.

Thanks,
Patrick


On Tue, Apr 26, 2016 at 3:59 PM, Jeremy Allison <jra at samba.org> wrote:
> On Tue, Apr 26, 2016 at 12:06:39PM -0400, Glomski, Patrick wrote:
> > Greetings,
> >
> > We use samba to share files to windows and linux machines and are in
the
> > same boat as several others recently posting to the list. When badlock
> > patches came out, we updated our CentOS7 samba server (everything from
> > samba to sssd to krb5 to nss was updated) and immediately had problems
> with
> > both client types not connecting to the windows shares.
> >
> > Windows machine connections were solved by using the realm
> > (workgroup.com\username)
> > to log in instead of the workgroup (workgroup\username). Although
it's
> not
> > clear to me as to why I need '.com' to authenticate all of a
sudden, it
> > functions and isn't a critical concern for this production server.
> >
> > Linux machines were mounting via 'mount -t cifs -o
> > user=workgroup/username'. This mount no longer functions and it
appears
> > (setting server log level to 10) that the authentication on the server
is
> > failing where it used to succeed. 'smbclient' also fails.
>
> Get a wireshark trace and post what error is returned please.
>