[Samba] Nonfunctional linux/CIFS mounts after update (ADS / windows DC auth)

[Rowland penny]

On 27/04/16 21:16, Glomski, Patrick wrote:
> Both answered in my initial post; see below:
>
> On Wed, Apr 27, 2016 at 4:02 PM, Jeremy Allison <jra at samba.org> wrote:
>
>> On Wed, Apr 27, 2016 at 03:18:18PM -0400, Glomski, Patrick wrote:
>>> I have been running in loglevel 10 and looking at the logs, but as I said
>>> in my initial post the credentials function fine with nautilus. Appended
>> is
>>> a connection log snippet where samba walks through a cascade of
>>> authentication methods and finally fails.
>>>
>>> Earlier in the log, samba successfully determines which domain controller
>>> to talk to and pulls its information. However, just before the failure
>>> there is a line which I feel is the root cause of the problem.
>>>
>>>>    domain_client_validate: Domain password server not available.
>>>>
>>> Taken at face value (not the best idea as it seems to be walking through
>> a
>>> set of authentication methods), it indicates that somehow the information
>>> about the domain controller doing the authentication has been lost.
>>>
>>> The password is good: It works on Windows and it works with nautilus.
>> Samba
>>> says the password is bad when using cifs or smbclient. What gives?
>>>
>>> For the situational awareness of others affected by this issue, I hoped
>> it
>>> was sssd or the associated name service switch libraries, so I built and
>>> installed rpms for an older version of sssd. No dice.
>> What is your smb.conf.
>
>
> [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
>
>
>> Is winbindd running ? If so you might
>> want to look in the winbindd logs, as this is an NTLM auth
>> which should be passed to winbindd in the domain case.
>>
> We don't and have never run winbind on the system, so winbind is off.

Oh but you are, well sort of, sssd now includes a version of the winbind 
code, so your problem could very well be an sssd issue, I suggest you 
try the sssd-users mailing list to check.

Rowland