[Samba] Samba 4.4, sssd, adcli; windows hosts cannot authenticate

[Rowland Penny]

On Sun, 28 May 2017 15:27:53 -0700
Steve Dainard <sdainard at spd1.com> wrote:


> 
> Right, the host is joined to the domain, via adcli, rather than net.

Yes, but by your own admission, it isn't an AD domain.

> 
> In context, makes sure people understand I've used adcli, rather than
> using the net command and must continue to do so, so that I can
> automate joining samba servers to the domain.

So, it just automates the join.

> 
> >
> > From what you have posted the default realm is
> > 'AD.LOCALDOMAIN.COM' but your clients are in the dns domain
> > 'dhcp.localdomain.com', I am no kerberos expert, but this wouldn't
> > work with a Samba AD DC.
> 
> Right, the server is configured as a member server, not a domain
> controller. 

Perhaps I should have said 'against' instead of 'with'

> I'm thinking NTLM may not work with encrypted passwords 

Samba's default is 'encrypt passwords = Yes'
There is however another problem, windows is doing all it can to not
use ntlm anymore.

> >
> > It sounds like you could replace the salt machine with a Samba AD DC
> > and then you wouldn't have all the problems you are having, but I
> > understand that you want to use salt. The only problem I can see,
> > you have set up smb.conf to connect to an AD DC.
> 
> Salt is only for configuration management, it doesn't matter too much
> in this context. As mentioned, I'm joining the samba server as a
> member of the domain, not using it as a domain controller, and using
> it as a DC is not an option.

I never said use it as a DC, I said it is set up to expect an AD DC.
  
> Whichever user a bad user is being mapped to, I believe this is at the
> root of the problem with the Windows client. I think Kerberos is
> working for the initial auth/handshake, but somehow user id  doesn't
> carry through to match actual permissions on the share. But that this
> does work for a Linux client machine/user is what is confounding.

I personally think your problem is probably being caused by:

A) the Unix Domain member thinking it is in AD
B) the mismatch of DNS and kerberos domains.

Rowland