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

[Steve Dainard]

On Sun, May 28, 2017 at 1:38 AM, Rowland Penny via samba
<samba at lists.samba.org> wrote:
> On Sat, 27 May 2017 21:45:29 -0700
> Steve Dainard via samba <samba at lists.samba.org> wrote:
>
>> I'm running samba 4.4.4 on el7. I'm attempting to provide a share
>> auth by Kerberos or for non-kerberos hosts auth by password on Linux
>> or Windows (7)
>> clients.
>>
>> We have uid/gid/group memberships in AD and typically configure
>> Linux hosts with a kerberos/sssd/ldap configuration which uses
>> attributes from AD, but are not joined to domain.
>
> You have 'security = ADS' in smb.conf and from 'man smb.conf'
>
> SECURITY = ADS
>
> In this mode, Samba will act as a domain member in an ADS realm. To
> operate in this mode, the machine running Samba will need to have
> Kerberos installed and configured and Samba will need to be joined
> to the ADS realm using the net utility.
>

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

>
>>
>> I need to be able to automate the domain join with salt stack, so I'm
>> stuck using adcli to join the machine as it has a plain-text password
>> option, I then push sssd.conf, /etc/krb5.conf, and /etc/samba/smb.conf
>> to the samba host.
>
> Never heard of 'salt' until now and I don't really understand what it
> brings to the party ?

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.

>
> 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.
Also this doesn't seem to be a 'kerberos' issue, as my Linux clients
who auth via kerberos are able to properly authenticate on a protected
share without password prompts, and I see a cifs kerberos ticket on my
Linux client. The Linux clients also have fqdn's in the same domain as
the samba server, not the ad domain. So it appears it might be Windows
implementation that has an issue with clients having a different
domain name than the servers. That doesn't explain user/password
authentication not working on the Windows client, I'm definitely
missing something on this side, I'm thinking NTLM may not work with
encrypted passwords although I thought this didn't apply to newer
versions of samba. This seems related
https://social.technet.microsoft.com/Forums/en-US/8249ad4c-69aa-41ba-8863-8ecd7a7a4d27/samba-share-password-refused?forum=win10itpronetworking
I'll give it a run when I'm back in the office.

>
> 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.

>
>
>> When I attempt to connect from a domain joined Windows client I get
>> prompted for credentials, and domain credentials do not work. It seems
>> like the id of the user isn't passed through or looked up correctly
>> after Kerberos auth, and the user is labelled as a guest user. Guest
>> users are mapped to bad user in samba config. Here's a bit of logging
>> when the Windows client tries to access a
>> share: https://pastebin.com/pbEqj9ZR
>
> Actually unknown users (i.e. Bad User) are mapped to the Unix user
> 'nobody', they probably wouldn't be if you were using an AD DC with
> the windows clients joined to the domain.

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.

>
> The other problem you have here is, sssd has nothing to do with Samba,
> it is not Samba package, you may get better help from the sssd-users
> mailing list, mainly because, if you are using sssd, it is this that
> is doing your authentication.

Yes, I've sent this mail to both lists.

>
> Rowland
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba